[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Guido van Rossum added the comment: I'm glad you've rediscovered pgen2! I'm in favor of unifying the tokenizers and of updating and moving pgen2 (though I don't have time to do the work). I'm not sure if it's technically possible to give tokenize.py the ability to tokenize

[issue33315] Allow queue.Queue to be used in type annotations

Guido van Rossum added the comment: [Raymond] > I don't think it makes sense to let typing considerations > start to spill into the rest of the standard library. > Either add support to typing or not. We can't possibly add every stdlib class that's generic to typing.py -- it

[issue25478] Consider adding a normalize() method to collections.Counter()

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +6275 stage: -> patch review ___ Python tracker ___

[issue33315] Allow queue.Queue to be used in type annotations

Guido van Rossum added the comment: Disagree strongly. More later. On Sun, Apr 22, 2018, 18:41 Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > > Another solution may be to add a simple

[issue33315] Allow queue.Queue to be used in type annotations

Raymond Hettinger added the comment: > Another solution may be to add a simple `__class_getitem__` to `Queue` > that will just return `cls` I don't think it makes sense to let typing considerations start to spill into the rest of the standard library. Either add

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Change by Łukasz Langa : -- pull_requests: -6270 ___ Python tracker ___ ___

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Change by Łukasz Langa : -- keywords: -patch ___ Python tracker ___ ___ Python-bugs-list

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Łukasz Langa added the comment: See BPO-8 for an implementation of Step 1. -- stage: patch review -> ___ Python tracker ___

[issue16152] Trailing whitespace makes tokenize.generate_tokens pathological

Ned Batchelder added the comment: PR 6273 is mentioned, but I think 6573 is the correct number. -- ___ Python tracker ___

[issue33321] Add a Linux clang ubsan undefined behavior sanitizer buildbot

Change by kmoultr...@gmail.com : -- versions: +Python 2.7 ___ Python tracker ___ ___

[issue33338] [lib2to3] Synchronize token.py and tokenize.py with the standard library

Change by Łukasz Langa : -- pull_requests: +6274 ___ Python tracker ___ ___

[issue2495] tokenize doesn't handle __future__.unicode_literals correctly

Change by Łukasz Langa : -- pull_requests: +6271 ___ Python tracker ___ ___ Python-bugs-list

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Change by Łukasz Langa : -- keywords: +patch pull_requests: +6270 stage: -> patch review ___ Python tracker ___

[issue14990] detect_encoding should fail with SyntaxError on invalid encoding

Change by Łukasz Langa : -- pull_requests: +6272 ___ Python tracker ___ ___

[issue33338] [lib2to3] Synchronize token.py and tokenize.py with the standard library

Change by Łukasz Langa : -- keywords: +patch pull_requests: +6269 stage: -> patch review ___ Python tracker ___

[issue16152] Trailing whitespace makes tokenize.generate_tokens pathological

Change by Łukasz Langa : -- pull_requests: +6273 ___ Python tracker ___ ___

[issue33338] [lib2to3] Synchronize token.py and tokenize.py with the standard library

New submission from Łukasz Langa : lib2to3's token.py and tokenize.py were initially copies of the respective files from the standard library. They were copied to allow Python 3 to read Python 2's grammar. Since 2006, lib2to3 grew to be widely used as a Concrete Syntax Tree,

[issue33338] [lib2to3] Synchronize token.py and tokenize.py with the standard library

Łukasz Langa added the comment: ### Diff between files The unified diff between tokenize implementations is here: https://gist.github.com/ambv/679018041d85dd1a7497e6d89c45fb86 It clocks at 275 lines but that's because it gives context. The actual diff is 175 lines long. To

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

New submission from Łukasz Langa : Python includes a set of batteries that enable parsing of Python code. This includes its own AST (provided in the standard library under the `ast` module), as well as a pure Python tokenizer (provided in the standard library under `tokenize`

[issue991266] Cookie.py does not correctly quote Morsels

Berker Peksag added the comment: New changeset 9fc998d761591f2741d8e94f5b3009c56ae83882 by Berker Peksag (Miss Islington (bot)) in branch '3.7': bpo-991266: Fix quoting of Comment attribute of SimpleCookie (GH-6555)

[issue991266] Cookie.py does not correctly quote Morsels

Berker Peksag added the comment: New changeset 8a6f4b4bba950fb8eead1b176c58202d773f2f70 by Berker Peksag (Miss Islington (bot)) in branch '3.6': bpo-991266: Fix quoting of Comment attribute of SimpleCookie (GH-6555)

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Brett Cannon added the comment: @Nick: We've had this discussion before about specs being a "receipt" of import versus not and the last time we agreed on not. :) That's why we raise a warning if __package__ doesn't match __spec__.parent:

[issue991266] Cookie.py does not correctly quote Morsels

Change by miss-islington : -- pull_requests: +6268 ___ Python tracker ___

[issue991266] Cookie.py does not correctly quote Morsels

Change by miss-islington : -- pull_requests: +6267 ___ Python tracker ___

[issue991266] Cookie.py does not correctly quote Morsels

Berker Peksag added the comment: New changeset d5a2377c3d70e4143bcbee4a765b3434e21f683a by Berker Peksag in branch 'master': bpo-991266: Fix quoting of Comment attribute of SimpleCookie (GH-6555)

[issue33325] Optimize sequences of constants in the compiler

Mark Shannon added the comment: There seems to be an implicit assumption here that fewer bytecodes is better. But that isn't always the case. Do you have evidence that the sequence 0 LOAD_CONST 5 ((('a', 'b', 'c'), 3, 2, 1)) 2 UNPACK_SEQUENCE 4 is

[issue18153] python imaplib - error 'unexpected repsonse'

Change by Matej Cepl : -- nosy: +mcepl ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33336] [imaplib] MOVE is a legal command

Change by Matej Cepl : -- keywords: +patch pull_requests: +6266 stage: -> patch review ___ Python tracker ___

[issue33336] [imaplib] MOVE is a legal command

New submission from Matej Cepl : When running box = IMAP4_SSL(host) box.login(user, pass) msgs = somehowget_uids_of_messsages_to_move() box.uid('MOVE', msgs, 'target') I get an error "Unknown IMAP4 UID command: MOVE". The problem is that imaplib contains a list

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Change by Chris Bradbury : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: not a bug -> status: closed -> open ___ Python tracker

[issue31457] LoggerAdapter objects cannot be nested

Łukasz Langa added the comment: New changeset 26c289dd76ed07dbf37494bfa483c525f6828bd9 by Łukasz Langa (Miss Islington (bot)) in branch '3.6': bpo-31457: Don't omit inner ``process()`` calls with nested LogAdapters (GH-4044) (#6568)

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Change by Chris Bradbury : -- resolution: -> not a bug ___ Python tracker ___ ___

[issue31457] LoggerAdapter objects cannot be nested

Change by miss-islington : -- pull_requests: +6265 ___ Python tracker ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Chris Bradbury added the comment: I'll make the documentation changes instead, not overly surprised to hear this is intentional. -- stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Łukasz Langa added the comment: See line 379 in configparser.py. BasicInterpolation is also assumed to work for values from the default section. This is why the default section exists in the first place. More importantly, as you're pointing out, even though this is an

[issue33251] ConfigParser.items returns items present in vars

Łukasz Langa added the comment: > What *actually* was changed in 3.2? In terms of this issue, nothing. That piece of documentation was put without proper testing, based purely on a comment that somebody put on issue12036. My mistake. --

[issue33251] ConfigParser.items returns items present in vars

Change by Chris Bradbury : -- pull_requests: +6264 ___ Python tracker ___ ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Change by Chris Bradbury : -- pull_requests: +6263 ___ Python tracker ___ ___

[issue33015] Fix function cast warning in thread_pthread.h

Change by Ned Deily : -- nosy: +benjamin.peterson ___ Python tracker ___ ___

[issue33335] turtle.onkey doesn't pass key information when key is None

New submission from J E : I use the turtle module to teach Python to university students. The turtle.onkey function allows a program to register a callback function to handle a keyboard when the turtle window has a focus. For example, this call will result in myfun()

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: One option would be to create a list of possible defined signals and check if the signal is on the list. For realtime signals, it just a matter to check if SIGRTMIN <= signal <= SIGRTMAX. The glibc defined signals can be checked at

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Change by Paul Ganssle : -- versions: +Python 3.8 ___ Python tracker ___ ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Chris Bradbury added the comment: The fix for the actual issue is quite trivial (and should fix bpo-33251 at the same time). However `ExtendedInterpolation::_interpolate_some` relies on the options from the default section always being returned. Not only does this make

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

Serhiy Storchaka added the comment: Fill free to create a pull request. It may need tests and documentation though. -- ___ Python tracker

[issue33280] Update link to Tcl/Tk 8.6 man pages in tkinter.rst

Andrés Delfino added the comment: I have updated the PR: * Now we mention that python -m tkinter shows the installed Tcl/Tk version so users can read the right man pages. * Only mention the link to documentation page (sadly, there doesn't seem to exist an "Archived man

[issue33334] Add support of NOP and EXTENDED_ARG in stack_effect()

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +6262 stage: -> patch review ___ Python tracker ___

[issue33334] Add support of NOP and EXTENDED_ARG in stack_effect()

New submission from Serhiy Storchaka : Currently dis.stack_effect() doesn't support opcodes NOP and EXTENDED_ARG. NOP is never emitted by the standard compiler (it is temporary added in the peephole optimizer, but later it is removed). EXTENDED_ARG is a special

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

Matthias Kievernagel added the comment: I have a patched Python 3.5.3 running mostly following the comments by O.C. If no one else is active on this I can try to prepare something for submission. -- ___ Python tracker

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Barry A. Warsaw added the comment: Not that I've thought this through in much detail, but what if we start out by proxying those module attributes to the spec via PEP 562 hooks? We can do that in 3.8, issue (silent?) deprecation warnings, and then do a full deprecation

[issue33331] Clean modules in the reversed order

Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

Cheryl Sabella added the comment: Adding to what Serhiy said about the askcolor() return value is an issue that also affects input: >>> cc.askcolor('red') ((255, 0, 0), '#ff') >>> cc.askcolor((255, 0, 0)) ((255, 0, 0), '#ff') >>> cc.askcolor((65535, 0, 0))

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- assignee: -> pitrou ___ Python tracker ___ ___

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: > Why not export and use the canonical way of > sigemptyset/sigfillset/sigaddset/sigdelset/sigismember instead of pushing for > more potential non-conformant code? I agree this is the proper fix and that's what I plan to do in Python 3.8.

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: Also keep in mind that POSIX [1] specifies that sigaddset *may* fail with EINVAL for not support signals, so a conforming implementation may not fail on sigaddset and still remove the internal signal in a sigprocmask (uclibc for

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: Why not export and use the canonical way of sigemptyset/sigfillset/sigaddset/sigdelset/sigismember instead of pushing for more potential non-conformant code? For glibc sigfillset will correctly fill all the signal set structure while

[issue33329] sigaddset() can fail on some signal numbers

Miro Hrončok added the comment: This indeed makes the tests pass again: # python3.7 -m test.regrtest test_multiprocessing_fork test_multiprocessing_forkserver test_multiprocessing_spawn Run tests sequentially 0:00:00 load avg: 1.02 [1/3] test_multiprocessing_fork

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Miro, can you give the following patch a try? diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c index 7916160..ca76a20 100644 --- a/Modules/signalmodule.c +++ b/Modules/signalmodule.c @@ -819,7 +819,6 @@ iterable_to_sigset(PyObject

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: > We could do that, but I'd rather something not multiprocessing-specific ... and also not Linux-specific. -- ___ Python tracker

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: We could do that, but I'd rather something not multiprocessing-specific. I think we have to ignore the return value of sigaddset() until issue2 allows us to be smarter. -- ___ Python tracker

[issue33329] sigaddset() can fail on some signal numbers

Miro Hrončok added the comment: Should the fix be to exclude 32 and 33 from multiprocessing.resource_sharer:_serve? if hasattr(signal, 'pthread_sigmask'): signal.pthread_sigmask(signal.SIG_BLOCK, range(1, signal.NSIG)) --

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Setting as release blocker as it impacts functionality of the multiprocessing module. -- nosy: +ned.deily priority: critical -> release blocker ___ Python tracker

[issue33329] sigaddset() can fail on some signal numbers

Miro Hrončok added the comment: Python 2 testsuite runs fine. -- ___ Python tracker ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Change by Serhiy Storchaka : -- components: +Library (Lib) nosy: +lukasz.langa ___ Python tracker ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

Change by Chris Bradbury : -- keywords: +patch pull_requests: +6261 stage: -> patch review ___ Python tracker ___

[issue33333] ConfigParser.items returns items present in `DEFAULTSECT` when section argument given.

New submission from Chris Bradbury : According to `ConfigParser.items` docs: > When section is not given, return a list of section_name, section_proxy > pairs, including DEFAULTSECT. > Otherwise, return a list of name, value pairs for the options in the given > section.

[issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings

Serhiy Storchaka added the comment: I concur with Éric. Standard input and output are text streams in Python 3. The user can control their encoding by setting locale or PYTHONIOENCODING. I think this issue can be closed now unless somebody want to backport the fix

[issue33332] Expose valid signal set (sigfillset())

New submission from Antoine Pitrou : See issue33329: it would be nice to expose a signal module function to get the set of user-actionable signals. Hopefully sigfillset() does that. -- messages: 315606 nosy: pitrou priority: normal severity: normal stage: needs patch

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Running the whole test suite sounds fine. -- ___ Python tracker ___

[issue25205] setattr accepts invalid identifiers

Change by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue24024] str.__doc__ needs an update

Change by Serhiy Storchaka : -- resolution: -> rejected stage: needs patch -> resolved status: pending -> closed ___ Python tracker

[issue33329] sigaddset() can fail on some signal numbers

Miro Hrončok added the comment: I cannot find a corresponding test in 2.7. Running the entire build (incl. tests) to see what happens. Is there a command or a couple I could try instead? I'm afraid I don't understand how does that test work (I seems a bit complicated)

[issue33331] Clean modules in the reversed order

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +6260 stage: -> patch review ___ Python tracker ___

[issue33331] Clean modules in the reversed order

New submission from Serhiy Storchaka : Since dict is ordered, modules in sys.modules are ordered for the time of importing. Currently they are cleaned in PyImport_Cleanup() in the direct order -- from imported first to imported later. I wonder if cleaning them in

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Miro, could you check whether 2.7 is affected too? -- ___ Python tracker ___

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- priority: normal -> critical stage: -> needs patch title: test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range -> sigaddset() can fail on some signal numbers type: -> behavior versions: +Python

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Antoine Pitrou added the comment: Ok, this is due to: https://sourceware.org/bugzilla/show_bug.cgi?id=22391 Short explanation here: https://unix.stackexchange.com/a/155846 -- ___ Python tracker

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Miro Hrončok added the comment: glibc-2.27.9000-13.fc29 ... all ok glibc-2.27.9000-14.fc29 ... 32, 33 fail glibc-2.27.9000-15.fc29 (latest built) ... 32, 33 fail 13 to 14 is this in upstream commits: d39c0a459ef32a41daac4840859bf304d931adab to

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Miro Hrončok added the comment: dnf install https://kojipkgs.fedoraproject.org/packages/glibc/2.27.9000/7.fc29/x86_64/glibc-headers-2.27.9000-7.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org/packages/glibc/2.27.9000/7.fc29/x86_64/glibc-devel-2.27.9000-7.fc29.x86_64.rpm

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Miro Hrončok added the comment: "dnf install gcc" upgrades glibc, yes. OK, I'll dig into it a bit more, see why and where this change happened. Thanks for hints. -- ___ Python tracker

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Miro Hrončok added the comment: glibc-2.27.9000-14.fc29: NSIG = 65 sigaddset(32) returned -1, errno =22 sigaddset(33) returned -1, errno =22 -- ___ Python tracker

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Antoine Pitrou added the comment: I was able to compile the program above after the system upgrade using your Docker image, and the following stands out: sigaddset(31) returned 0, errno = 0 sigaddset(32) returned -1, errno = 22 sigaddset(33) returned -1, errno = 22

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Miro Hrončok added the comment: I'll try. In the meantime, I've checked and it's glibc update that makes the difference: glibc-2.27.9000-7.fc29 -> glibc-2.27.9000-14.fc29 I'll see what was changed there and whether is was intentional, or bug in Fedora. --

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

Antoine Pitrou added the comment: Perhaps you can compile and run this C program, before and after the system changes, and post the output: #include #include #include int main(int argc, char** argv) { sigset_t set; int i, ret; printf("NSIG = %d\n", NSIG);

[issue33315] Allow queue.Queue to be used in type annotations

Ivan Levkivskyi added the comment: I think this issue appeared previously on typing tracker. The current recommendation is to escape problematic annotations with quotes: q: 'Queue[int]' I don't think it will be added to typing, because following this way typing will

[issue33330] Better error handling in PyImport_Cleanup()

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +6259 stage: -> patch review ___ Python tracker ___

[issue33330] Better error handling in PyImport_Cleanup()

New submission from Serhiy Storchaka : The proposed PR adds missed checks for errors and PyErr_Clear() calls in PyImport_Cleanup(). It may be worth to use PyErr_WriteUnraisable() in place of PyErr_Clear() (newly added and existing) in most cases. But this can add

[issue31463] test_multiprocessing_fork hangs test_subprocess

Miro Hrončok added the comment: > Could you report the signal number issue separately? Thank you! https://bugs.python.org/issue33329 Resetting the Versions back. -- versions: -Python 3.4, Python 3.5, Python 3.6 ___ Python

[issue33329] test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal number 32 out of range

New submission from Miro Hrončok : Originally reported in https://bugs.python.org/issue31463 This started to bother us in Fedora rawhide for various Python versions, so chances are something changed on the system level. # python3.7 -m test.regrtest test_multiprocessing_fork

[issue33328] pdb error when stepping through generator

Rick Teachey added the comment: I am on Anaconda 4.5.1 on Windows 10 (Python 3.6.5). I have confirmed that I DO get the error on another machine with the same version installed, so the lack of an error seems specific to my current machine. I do not know what could be