[issue29335] Python 2.7 subprocess module does not check WIFSTOPPED on SIGCHLD

Zach Riggle added the comment: To further clarify the report: When the attached proof-of-concept is executed, a RuntimeException is raised, which has a comment "Should never happen". The issue isn't due to SIGCHLD, but rather following a waitpid() call. The code attempts to suss the exit

Re: PEP 393 vs UTF-8 Everywhere

On Sunday 22 January 2017 06:58, Tim Chase wrote: > Right. It gets even weirder (edge-case'ier) when dealing with > combining characters: > > s = "man\N{COMBINING TILDE}ana" for i, c in enumerate(s): print("%i: %s" % (i, c)) > ... > 0: m > 1: a > 2: n > 3:˜ > 4: a > 5: n > 6: a

[issue29290] argparse breaks long lines on NO-BREAK SPACE

Xiang Zhang added the comment: Thanks Serhiy. BTW, #16623 is about 2.7 and the cause is wrap doesn't handle unicode non-breaking spaces right. So it's not the same thing as here. -- resolution: -> fixed stage: commit review -> resolved status: open -> closed

[issue29290] argparse breaks long lines on NO-BREAK SPACE

Roundup Robot added the comment: New changeset 98cde683b9c6 by Xiang Zhang in branch '3.5': Issue #29290: argparse help messages won't wrap at non-breaking spaces. https://hg.python.org/cpython/rev/98cde683b9c6 New changeset 1754722ec296 by Xiang Zhang in branch '3.6': Issue #29290: Merge 3.5.

[issue29099] sqlite3 timestamp converter cannot handle timezone

Xiang Zhang added the comment: > I'm even worse at that. :-( LoL. Okay I'll do that. :-) -- ___ Python tracker ___

[issue29099] sqlite3 timestamp converter cannot handle timezone

Serhiy Storchaka added the comment: I'm even worse at that. :-( -- ___ Python tracker ___ ___

[issue29290] argparse breaks long lines on NO-BREAK SPACE

Serhiy Storchaka added the comment: LGTM. You perhaps need to change your email provider Xiang. It fails too often. -- assignee: -> xiang.zhang stage: patch review -> commit review ___ Python tracker

[issue29099] sqlite3 timestamp converter cannot handle timezone

Xiang Zhang added the comment: > Maybe discuss this on Python-Dev? It's fine. Could you compose a mail instead of me? I am not good at that. :-( -- ___ Python tracker

[issue29341] Missing accepting path-like object in docstrings of os module functions

Changes by Serhiy Storchaka : -- assignee: -> docs@python components: +Documentation keywords: +easy nosy: +docs@python ___ Python tracker

[issue29099] sqlite3 timestamp converter cannot handle timezone

Serhiy Storchaka added the comment: Added few minor comments on Rietveld. Technically the patch LGTM. But the behavior change of the timestamp converter for input without timezone offset perhaps needs wider discussion. We have several options: 0. Current behavior. Silently drop the timezone

[issue29341] Missing accepting path-like object in docstrings of os module functions

Changes by Xiang Zhang : -- stage: -> needs patch ___ Python tracker ___ ___

[issue29341] Missing accepting path-like object in docstrings of os module functions

New submission from Xiang Zhang: PathLike objects are added in 3.6 and they are mentioned in the documentation. But in some os module functions' docstrings, acceptable types of path parameter are mentioned and they are not altered to mention path-like object. For example: chown(path, uid,

[issue28663] Higher virtual memory usage on recent Linux versions

INADA Naoki added the comment: @ProgVal, could you try following? I doubt that this difference just shows rlimit behavior, not memory usage. --- $ cat rlimit_difference_linux_versions.py import sys import queue import multiprocessing from urllib.request import Request, urlopen import resource

[issue29092] Sync os.stat's doc and doc string

Roundup Robot added the comment: New changeset 1f30e114cbc8 by Xiang Zhang in branch '3.5': Issue #29092: Sync os.stat's doc and docstring on path type. https://hg.python.org/cpython/rev/1f30e114cbc8 New changeset 409ffea5cccf by Xiang Zhang in branch '3.6': Issue #29092: Sync os.stat's doc and

[issue29092] Sync os.stat's doc and doc string

Changes by Xiang Zhang : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue15997] NotImplemented needs to be documented

Changes by Martin Panter : -- dependencies: +Clarify the behavior of __eq__() returning NotImplemented ___ Python tracker ___

[issue28785] Clarify the behavior of __eq__() returning NotImplemented

Changes by Martin Panter : -- title: Clarify the behavior of NotImplemented -> Clarify the behavior of __eq__() returning NotImplemented ___ Python tracker

[issue29099] sqlite3 timestamp converter cannot handle timezone

Xiang Zhang added the comment: Ping for review for timestamptz-3.patch. -- ___ Python tracker ___ ___

[issue29290] argparse breaks long lines on NO-BREAK SPACE

Xiang Zhang added the comment: v2 addresses the comments. I didn't receive the review notification mail so just saw them today. :-( -- stage: -> patch review Added file: http://bugs.python.org/file46376/argparse-help-non-breaking-spaces-2.patch

[issue29182] Remove the warning in urllib docs that it doesn't do certificate validate by default.

Senthil Kumaran added the comment: @Martin, that's a sound advice. I agree to it. I'll change it to a note (instead of warning) which mentions about certificate verification since 2.7.9. -- ___ Python tracker

Re: PEP 393 vs UTF-8 Everywhere

On Sun, 22 Jan 2017 07:21 am, Pete Forman wrote: > Marko Rauhamaa writes: > >>> py> low = '\uDC37' >> >> That should raise a SyntaxError exception. > > Quite. My point was that with older Python on a narrow build (Windows > and Mac) you need to understand that you are using

[issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module

Martin Panter added the comment: Patch looks good to me. BTW in Issue 27409 I proposed a patch listing more of these. -- nosy: +martin.panter ___ Python tracker

[issue1732367] Document the constants in the socket module

Changes by Martin Panter : -- dependencies: +Document socket.SOL_SOCKET ___ Python tracker ___

Re: PEP 393 vs UTF-8 Everywhere

On Sun, 22 Jan 2017 06:52 am, Marko Rauhamaa wrote: > Pete Forman : > >> Surrogates only exist in UTF-16. They are expressly forbidden in UTF-8 >> and UTF-32. > > Also, they don't exist as Unicode code points. Python shouldn't allow > surrogate characters in strings.

[issue29311] Argument Clinic: convert dict methods

Martin Panter added the comment: Patch looks good, apart from one little thing (see review) -- ___ Python tracker ___

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

Martin Panter added the comment: Will keep this in mind, but my time is rather limited, so I may not get to it (and I wouldn’t want to discourage other people from working on it) -- ___ Python tracker

Re: PEP 393 vs UTF-8 Everywhere

On 2017-01-22 01:44, Steve D'Aprano wrote: > On Sat, 21 Jan 2017 11:45 pm, Tim Chase wrote: > > > but I'm hard-pressed to come up with any use case where direct > > indexing into a (non-byte)string makes sense unless you've already > > processed/searched up to that point and can use a recorded

Re: PEP 393 vs UTF-8 Everywhere

On 2017-01-21 10:50, Pete Forman wrote: > Thanks for a very thorough reply, most useful. I'm going to pick you up > on the above, though. > > Surrogates only exist in UTF-16. They are expressly forbidden in UTF-8 > and UTF-32. The rules for UTF-8 were tightened up in Unicode 4 and RFC > 3629

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

Steve Dower added the comment: How? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29182] Remove the warning in urllib docs that it doesn't do certificate validate by default.

Martin Panter added the comment: The warning for urllib2.urlopen() was removed in revision 1882157b298a. However, a couple other warnings were converted to “Changed in version 2.7.9” in revision fb83916c3ea1, which seems safer to me. Removing documentation almost seems like a step backwards.

Re: How to create a socket.socket() object from a socket fd?

Newsgroups: gmane.comp.python.general From: Grant Edwards Subject: Re: How to create a socket.socket() object from a socket fd? References:

[issue29340] SSL destructor segfaults in python3.6 threads when an unverified-cert connection is closed

Nick Sweeting added the comment: Actually I suspected it was OpenSSL first, I filed the report on their github issues, then went on a fun little wild goose chase that ended in the CPython issue tracker. :) https://github.com/openssl/openssl/issues/2260 Thanks for helping debug this so

[issue29340] SSL destructor segfaults in python3.6 threads when an unverified-cert connection is closed

Christian Heimes added the comment: I can't reproduce the crash with OpenSSL 1.1.0 and LibreSSL 2.5.0. You might have found a bug in OpenSSL. -- ___ Python tracker

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

STINNER Victor added the comment: Can't we just update the cache when the function changes the encoding? -- ___ Python tracker ___

[issue29340] SSL destructor segfaults in python3.6 threads when an unverified-cert connection is closed

Christian Heimes added the comment: SSL_CTX_free: if (a->rbuf_freelist) ssl_buf_freelist_free(a->rbuf_freelist); (gdb) p list $1 = (SSL3_BUF_FREELIST *) 0x7fffe8003b50 (gdb) p *list $2 = {chunklen = 33096, len = 1, head = 0x7fffe8031c00} (gdb) p *list->head $3 = {next =

Re: How to create a socket.socket() object from a socket fd?

On 2017-01-21, Christian Heimes wrote: > You might be interested in my small module > https://pypi.python.org/pypi/socketfromfd/ . I just releases a new > version with a fix for Python 2. Thanks for the hint! :) > > The module correctly detects address family, socket type

[issue29340] SSL destructor segfaults in python3.6 threads when an unverified-cert connection is closed

Christian Heimes added the comment: I can reproduce the crash under Linux with OpenSSL 1.0.2j and Python 2.7, 3.5 and 3.6. Python 2.7 doesn't crash every time, 1 out of 5 times maybe. #0 ssl_buf_freelist_free (list=0x7fffe8003b50) at ssl_lib.c:2094 #1 0x7fffef3d68d7 in SSL_CTX_free

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Here is another example of how broken and dangerous fileno argument is. getpeername() is neither a valid IPv4 tuple nor a valid IPv6 tuple. It's all messed up: >>> import socket >>> s = socket.create_connection(('www.python.org', 443)) >>> s >>>

[issue29340] SSL destructor segfaults in python3.6 threads when an unverified-cert connection is closed

New submission from Nick Sweeting: I mistakenly thought this bug was a pyOpenSSL bug, so I reported it there (https://github.com/pyca/pyopenssl/issues/588), but it looks like this is actually a bug in CPython. See the link for a nicer formatted bug report with more details. Code to

Re: How to create a socket.socket() object from a socket fd?

On 2017-01-21, Chris Angelico wrote: > On Sun, Jan 22, 2017 at 9:41 AM, Grant Edwards > wrote: >> | __init__(self, family=2, type=1, proto=0, _sock=None) >> | >> >> Ah! There's a keyword argument that doesn't appear in the docs, so >> let's try

Re: How to create a socket.socket() object from a socket fd?

Grant Edwards wrote: > Given a Unix file discriptor for an open TCP socket, I can't figure > out how to create a python 2.7 socket object like those returned by > socket.socket() > > Based on the docs, one might think that socket.fromfd() would do that > (since the docs say that's what it does):

Re: How to create a socket.socket() object from a socket fd?

On 2017-01-21 23:41, Grant Edwards wrote: > On 2017-01-21, Grant Edwards wrote: > >> Given a Unix file discriptor for an open TCP socket, I can't figure >> out how to create a python 2.7 socket object like those returned by >> socket.socket() >> >> Based on the docs,

[issue29339] Interactive: Move to same indentation level as previous line

New submission from 12345 67890: Not sure if anyone has ever thought about this, but it would be nice if the interactive interpreter set the same indentation level as the previous line. Of course this isn't urgent, but what do others think? -- messages: 285970 nosy: 12345 67890

Re: How to create a socket.socket() object from a socket fd?

On Sun, Jan 22, 2017 at 9:41 AM, Grant Edwards wrote: > | __init__(self, family=2, type=1, proto=0, _sock=None) > | > > Ah! There's a keyword argument that doesn't appear in the docs, so > let's try that... That's marginally better than my monkeypatch-after-creation

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

Steve Dower added the comment: Thanks for checking that. I don't think it's worth retaining the cache on Windows in the face of the broken behaviour. Any real-world case where a lot of paths are being encoded or decoded is also likely to involve file-system access which will dwarf the

Re: How to create a socket.socket() object from a socket fd?

On 2017-01-21, Grant Edwards wrote: > Given a Unix file discriptor for an open TCP socket, I can't figure > out how to create a python 2.7 socket object like those returned by > socket.socket() > > Based on the docs, one might think that socket.fromfd() would do that >

Re: How to create a socket.socket() object from a socket fd?

On Sun, Jan 22, 2017 at 9:28 AM, Grant Edwards wrote: > Given a Unix file discriptor for an open TCP socket, I can't figure > out how to create a python 2.7 socket object like those returned by > socket.socket() I suspect you can't easily do it. In more recent Pythons,

How to create a socket.socket() object from a socket fd?

Given a Unix file discriptor for an open TCP socket, I can't figure out how to create a python 2.7 socket object like those returned by socket.socket() Based on the docs, one might think that socket.fromfd() would do that (since the docs say that's what it does): Quoting

[issue29311] Argument Clinic: convert dict methods

Serhiy Storchaka added the comment: Proposed patch fixes/improves docstrings of dict and OrderedDict methods. -- nosy: +eric.snow, rhettinger stage: -> resolved Added file: http://bugs.python.org/file46374/dict-docstrings.patch ___ Python tracker

[issue28735] Mock is equal to ANY but MagicMock is not

Serhiy Storchaka added the comment: Thanks Berker. Maybe _Call.__eq__ also should return NotImplemented in some cases, but I don't have a demonstrating example. -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___

[issue28735] Mock is equal to ANY but MagicMock is not

Roundup Robot added the comment: New changeset 442eb26b1ca4 by Serhiy Storchaka in branch '3.5': Issue #28735: Fixed the comparison of mock.MagickMock with mock.ANY. https://hg.python.org/cpython/rev/442eb26b1ca4 New changeset 4a38781538f7 by Serhiy Storchaka in branch '3.6': Issue #28735:

[issue29331] Simplify argument parsing in sorted() and list.sort()

Serhiy Storchaka added the comment: Thanks Victor. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue29331] Simplify argument parsing in sorted() and list.sort()

Roundup Robot added the comment: New changeset 69bd5c497a82 by Serhiy Storchaka in branch 'default': Issue #29331: Simplified argument parsing in sorted() and list.sort(). https://hg.python.org/cpython/rev/69bd5c497a82 -- nosy: +python-dev ___ Python

Re: PEP 393 vs UTF-8 Everywhere

On Sat, Jan 21, 2017 at 8:21 PM, Pete Forman wrote: > Marko Rauhamaa writes: > >>> py> low = '\uDC37' >> >> That should raise a SyntaxError exception. > > Quite. My point was that with older Python on a narrow build (Windows > and Mac) you need to

Re: Adding colormaps?

Den 2017-01-21 skrev Gilmeh Serda : > On Wed, 18 Jan 2017 21:41:34 +, Martin Schöön wrote: > >> What I would like to do is to add the perceptually uniform sequential >> colormaps introduced in version 1.5.something. I would like to do this >> without

Re: PEP 393 vs UTF-8 Everywhere

Marko Rauhamaa writes: >> py> low = '\uDC37' > > That should raise a SyntaxError exception. Quite. My point was that with older Python on a narrow build (Windows and Mac) you need to understand that you are using UTF-16 rather than Unicode. On a wide build or Python 3.3+ then

Re: PEP 393 vs UTF-8 Everywhere

Pete Forman : > Surrogates only exist in UTF-16. They are expressly forbidden in UTF-8 > and UTF-32. Also, they don't exist as Unicode code points. Python shouldn't allow surrogate characters in strings. Thus the range of code points that are available for use as

Re: PEP 393 vs UTF-8 Everywhere

Chris Angelico writes: > On Sun, Jan 22, 2017 at 2:56 AM, Jussi Piitulainen wrote: >> Steve D'Aprano writes: >> >> [snip] >> >>> You could avoid that error by increasing the offset by the right >>> amount: >>> >>> stuff = text[offset + len("ф".encode('utf-8'):] >>> >>> which is awful. I believe

[issue29199] test_regrtest fails if PCBuild directory doesn't exist

Changes by ppperry : -- nosy: +ezio.melotti, michael.foord ___ Python tracker ___ ___

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

Serhiy Storchaka added the comment: Martin, you are the one who looked at these patches for last three years. Do you want to take this issue to you and update Vajrasky's patches? Now there is good performance argument for converting builtins to Argument Clinic. --

[issue29338] Output the text signature in the help of a class

Serhiy Storchaka added the comment: Proposed patch adds a text signature at the start of class description. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file46373/pydoc-class-signature.patch ___ Python tracker

[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex

Tom Krauss added the comment: I'm trying to add support for this in cffi, which uses ctypes... apparently this is now supported in libffi (https://github.com/libffi/libffi, v3.2 Nov 2014). It would be nice if this issue could be re-opened, or another one created for the same purpose.

Re: PEP 393 vs UTF-8 Everywhere

On Sun, Jan 22, 2017 at 2:56 AM, Jussi Piitulainen wrote: > Steve D'Aprano writes: > > [snip] > >> You could avoid that error by increasing the offset by the right >> amount: >> >> stuff = text[offset + len("ф".encode('utf-8'):] >> >> which is awful. I believe

[issue29326] Blank lines in ._pth file are not ignored

Steve Dower added the comment: The fix for this issue is needed in PC/getpathp.c as this is a special feature in path generation on Windows. I'm not aware of any such issue with .pth files - the underscore in ._pth is deliberate. -- ___ Python

Re: PEP 393 vs UTF-8 Everywhere

Steve D'Aprano writes: [snip] > You could avoid that error by increasing the offset by the right > amount: > > stuff = text[offset + len("ф".encode('utf-8'):] > > which is awful. I believe that's what Go and Julia expect you to do. Julia provides a method to get the next index. let text = "ἐπὶ

Re: PEP 393 vs UTF-8 Everywhere

Steve D'Aprano writes: > [...] > Another factor which I didn't see discussed anywhere is that Python > strings treat surrogates as normal code points. I believe that would > be troublesome for a UTF-8 implementation: > > py> '\uDC37'.encode('utf-8') > Traceback (most

Re: PEP 393 vs UTF-8 Everywhere

On Sat, 21 Jan 2017 11:45 pm, Tim Chase wrote: > but I'm hard-pressed to come up with any use case where direct > indexing into a (non-byte)string makes sense unless you've already > processed/searched up to that point and can use a recorded index > from that processing/search. Let's take a

Re: PEP 393 vs UTF-8 Everywhere

On Sat, 21 Jan 2017 09:35 am, Pete Forman wrote: > Can anyone point me at a rationale for PEP 393 being incorporated in > Python 3.3 over using UTF-8 as an internal string representation? I've read over the PEP, and the email discussion, and there is very little mention of UTF-8, and as far as I

[issue29282] Fused multiply-add: proposal to add math.fma()

Mark Dickinson added the comment: Also failures on Gentoo: here b is positive (possibly +inf), and c is finite, so we expect an infinite result. Instead, we're apparently getting a NaN. I don't have a good guess about what's causing this: the rest of the tests are passing, so it's unlikely

[issue29282] Fused multiply-add: proposal to add math.fma()

Roundup Robot added the comment: New changeset b5a5f13500b9 by Mark Dickinson in branch 'default': Issue #29282: Backed out changeset b33012ef1417 https://hg.python.org/cpython/rev/b5a5f13500b9 -- ___ Python tracker

[issue29282] Fused multiply-add: proposal to add math.fma()

Mark Dickinson added the comment: Failures on the Windows buildbot (http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/238/steps/test/logs/stdio) shown below. It looks as though Windows is emulating the FMA operation on this machine (and not doing a

Re: PEP 393 vs UTF-8 Everywhere

On 2017-01-21 11:58, Chris Angelico wrote: > So, how could you implement this function? The current > implementation maintains an index - an integer position through the > string. It repeatedly requests the next character as string[idx], > and can also slice the string (to check for keywords like

[issue29282] Fused multiply-add: proposal to add math.fma()

Serhiy Storchaka added the comment: Cross fingers... -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue29282] Fused multiply-add: proposal to add math.fma()

Roundup Robot added the comment: New changeset b33012ef1417 by Mark Dickinson in branch 'default': Issue #29282: add fused multiply-add function, math.fma. https://hg.python.org/cpython/rev/b33012ef1417 -- nosy: +python-dev ___ Python tracker

[issue29328] struct module should support variable-length strings

Serhiy Storchaka added the comment: If you want to add the support variable-size fields, this is incompatible with the struct module design. If you want to add the support of variable-length strings inside fixed-size fields (as with the 'p' format unit), I think this case is not enough

Problems with python3.6 on one system, but OK on another

I build python3.6 on two systems. On one system everything is OK: Python 3.6.0 (default, Jan 21 2017, 11:19:56) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. But on another I get: Could not find platform dependent libraries Consider setting

[issue29273] test___all__ alters utf8 locale setting

Xavier de Gaye added the comment: The rationale supporting this change is sound and the patch LGTM. -- nosy: +xdegaye ___ Python tracker ___

Re: Let ipython3 use the latest python3

On 21 January 2017 at 12:30, Cecil Westerhof wrote: > I built python3.6, but ipython3 is still using the old one (3.4.5). > How can I make ipython3 use 3.6? All packages you have installed are tied to a specific Python version. If you want to use IPython with Python 3.6, you

Let ipython3 use the latest python3

I built python3.6, but ipython3 is still using the old one (3.4.5). How can I make ipython3 use 3.6? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list

[issue29328] struct module should support variable-length strings

Mark Dickinson added the comment: A couple of questions that haven't been brought up yet: 1. Do you have any thoughts on how alignment should behave for '@'-style structs containing variable-length strings? I suspect the easiest solution may be simply to disallow that combination, and only

[issue29267] Cannot override some flags in CFLAGS from the command-line

Xavier de Gaye added the comment: Please try: make CFLAGS_NODIST=-std=gnu99 -- nosy: +xdegaye ___ Python tracker ___

[issue12067] Doc: remove errors about mixed-type comparisons.

Changes by Serhiy Storchaka : -- nosy: +r.david.murray ___ Python tracker ___

[issue28489] Fix comment in tokenizer.c

Serhiy Storchaka added the comment: No, I'm just saying that the list of combinations is not so large. Ryan's patch LGTM. -- ___ Python tracker ___

[issue29104] Left bracket remains in format string result when '\' preceeds it

Serhiy Storchaka added the comment: Ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12067] Doc: remove errors about mixed-type comparisons.

Martin Panter added the comment: Here is a port of the documentation to Python 2. Main differences: * Default rules for order comparisons are different * Not all kinds of objects inherit from object() * str(), unicode() compatibility * xrange() only seems to have default comparability * NAN,

[issue28489] Fix comment in tokenizer.c

Eric V. Smith added the comment: Right, that's basically what _all_string_prefixes() does: it starts with the 6 unique prefixes that are case- and order- independent ('b', 'r', 'u', 'f', 'br', 'fr'), and adds the cased and ordered versions. If you're saying that we should list those 8, and

[issue29338] Output the text signature in the help of a class

New submission from Serhiy Storchaka: Pydoc outputs the text signature for C functions. It defines parameters and default values and is a part of function description. Help on built-in function format in module builtins: format(value, format_spec='', /) Return

[issue28489] Fix comment in tokenizer.c

Serhiy Storchaka added the comment: There are just 8 legal combinations if ignore case: >>> import tokenize >>> sorted({x.lower() for x in tokenize._all_string_prefixes() if x}) ['b', 'br', 'f', 'fr', 'r', 'rb', 'rf', 'u'] -- nosy: +serhiy.storchaka

Re: PEP 393 vs UTF-8 Everywhere

Chris Angelico writes: > You can't do a look-ahead with a vanilla string iterator. That's > necessary for a lot of parsers. For JSON? For other parsers you usually have a tokenizer that reads characters with maybe 1 char of lookahead. > Yes, which gives a two-level indexing

[issue29336] merge tuples in module

Serhiy Storchaka added the comment: Following patch uses _PyCode_ConstantKey() as a key. This allows supporting integers, floats, bytes, etc. But I think we can go further and merge constants recursively. See also issue28813. -- nosy: +rhettinger Added file:

[issue29337] BytesWarning at compile time

Serhiy Storchaka added the comment: Proposed patch fixes the issue. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file46370/constant-key-bytes-warning.patch ___ Python tracker