[issue33133] Don't return implicit optional types by get_type_hints

Ivan Levkivskyi added the comment: OK, let us then keep this issue as a remainder that we need to update the runtime behaviour when the static one changes. -- ___ Python tracker <https://bugs.python.org/issue33

[issue1704621] interpreter crash when multiplying large lists

Ivan Zakharyaschev added the comment: Hi! This is broken for tuples (but not for lists, as in the example here) in 2.7.14 for me. Should we reopen this issue and fix it better? [builder@localhost ~]$ python Python 2.7.14 (default, Nov 7 2017, 17:07:17) [GCC 6.3.1 20170118 (ALT 6.3.1-alt2

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: New changeset 834940375ae88bc95794226dd8eff1f25fba1cf9 by Ivan Levkivskyi in branch 'master': bpo-32873: Treat type variables and special typing forms as immutable by copy and pickle (GH-6216) https://github.com/python/cpyt

[issue32873] Pickling of typing types

Change by Ivan Levkivskyi : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33153] interpreter crash when multiplying large tuples

Ivan Zakharyaschev added the comment: I meant the old issue https://bugs.python.org/issue1704621 . -- ___ Python tracker <https://bugs.python.org/issue33

[issue33153] interpreter crash when multiplying large tuples

New submission from Ivan Zakharyaschev : The issue https://bugs.python.org/msg314475 has arisen for tuples (but not for lists, as in the example there) in 2.7.14 for me. How should we fix it in a better way? This bug is not reproducible in python 3.5.4. [builder@localhost ~]$ python Python

[issue1704621] interpreter crash when multiplying large lists

Ivan Zakharyaschev added the comment: New issue filed: https://bugs.python.org/issue33153 -- ___ Python tracker <https://bugs.python.org/issue1704621> ___ ___

[issue33153] interpreter crash when multiplying large tuples

Ivan Zakharyaschev added the comment: The traceback: [builder@localhost ~]$ python -c 'x = ("a", "b") * 2**20; x *= 2**20' Segmentation fault (core dumped) [builder@localhost ~]$ gdb python core.23284 GNU gdb (GDB) 7.9-alt4 (ALT) Copyright (C) 2015 Free Software

[issue33153] interpreter crash when multiplying large tuples

Ivan Zakharyaschev added the comment: It was run in i586 chroot on x86_64. -- ___ Python tracker <https://bugs.python.org/issue33153> ___ ___ Python-bugs-list m

[issue33186] Memory corruption with urllib.parse

Change by Ivan Zakharyaschev : -- nosy: +imz ___ Python tracker <https://bugs.python.org/issue33186> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33186] Memory corruption with urllib.parse

Ivan Zakharyaschev added the comment: I've tested this on a e2k machine (e2k is a VLIW/EPIC architecture, similar to ia64), where python3 3.5 has been compiled with a completely different proprietary compiler, and got the same bad result. python3-3.5.1-alt7.3 (This has also been tested

[issue33186] Memory corruption with urllib.parse

Ivan Zakharyaschev added the comment: The bad results are also reproducible with: # dpkg -l python3.2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name

[issue33186] Memory corruption with urllib.parse

Ivan Zakharyaschev added the comment: > a list contains elements that have never been appended Why do we think that it's true? 1. The described result can be valid if there are "doubly quoted" strings in the input list. 2. Also, there could be a bug in unquote() which d

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Ivan Levkivskyi added the comment: This is not a bug but an explicit design decision. Generic classes are _static_ typing concept and therefore are not supposed to work freely with _dynamic_ class creation. During discussion of PEP 560 it was decided that there should be at least one way to

[issue33186] Memory corruption with urllib.parse

Ivan Zakharyaschev added the comment: > 1. The described result can be valid if there are "doubly quoted" strings in > the input list. To check this I've modified your testcase.py: diff --git a/testcase.py b/testcase.py index b597205..fefcef2 100755 --- a/testcase

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

Ivan Levkivskyi added the comment: This is not a bug, but a misunderstanding: * First, ABCMeta doesn't have `__prepare__`, it is just `type.__prepare__` * Second, the third argument to `types.new_class` is called `kwds` for a reason. It is not a namespace like in `type` but the s

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

Ivan Levkivskyi added the comment: https://devguide.python.org/ will help you. -- ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bug

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Ivan Levkivskyi added the comment: > If we're going to call new_class in make_dataclass, then we should change the > signature of make_dataclass to have the new_class parameters. Why? I think we should care about what API/signature is reasonable/typical for dataclasses use c

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +6035 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Py

[issue33186] Memory corruption with urllib.parse

Ivan Zakharyaschev added the comment: Actually, Alexey shared this problem with me orally first, and then asked to have a look at his report, and I felt that just describing the technical details about what is going on is not enough, and suggested to include a brief sentence which would

[issue32162] typing.Generic breaks __init_subclass__

Ivan Levkivskyi added the comment: Thanks Will! I think this is actually a different (although very similar issue). It looks like it is easy to fix. Could you please open a separate issue (and mention it here)? Also could you please provide a typical example when this breaks so that I can

[issue33207] typing.Generic does not correctly call super().__init_subclass__

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +6066 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33207> ___ ___ Py

[issue33207] typing.Generic does not correctly call super().__init_subclass__

Change by Ivan Levkivskyi : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: Apparently there is another type with a similar problem -- DefaultDict. Will fix this now. -- ___ Python tracker <https://bugs.python.org/issue32

[issue32873] Pickling of typing types

Change by Ivan Levkivskyi : -- pull_requests: +6088 ___ Python tracker <https://bugs.python.org/issue32873> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: New changeset 2a363d2930e29ec6d8a774973ed5a4965f881f5f by Ivan Levkivskyi in branch 'master': bpo-32873: Remove a name hack for generic aliases in typing module (GH-6376) https://github.com/python/cpython/commit/2a363d2930e29ec6d8a774973ed5a4

[issue33211] lineno and col_offset are wrong on function definitions with decorators

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Change by Ivan Levkivskyi : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33211] lineno and col_offset are wrong on function definitions with decorators

Ivan Levkivskyi added the comment: > I was hoping to see if this was seen as a reasonable patch that might be > accepted. I didn't look carefully but superficially it looks reasonable, so it is worth trying. > Also, while I think it would be nice, I take it a patch for

[issue33257] Race conditions in Tkinter with non-threaded Tcl

New submission from Ivan Pozdeev : (Marked only 2.7 as affected but this would affect any branch if built with nonthreaded Tcl.) When running the attached TkinterCrash2-2.py repeatedly with 2.7.14 and 2.7 head, win7 x64, two kinds of errors pop up randomly: 1. Crashes and freezes. 2

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47530/TkinterCrash3-2-2.py ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bug

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : -- keywords: +patch pull_requests: +6139 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Py

[issue33255] json.dumps has different behaviour if encoding='utf-8' or encoding='utf8'

Ivan Pozdeev added the comment: Treating 'utf-8' and its aliases differently (when they specifically mean the Python's, rather than something else's, encoding) is definitely as issue. You shouldn't hardcode a list of aliases though; rather use existing facilities to

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: My best idea for a test as of now is to run the example ~20 times in a loop (or continuously for a comparable amount of time & threads) and catch and register any exceptions in all threads as per https://stackoverflow.com/questions/18349614/check-if-a-py

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: @terry.reedy Apparently, this bug has gone unnoticed for years (to be precise, since https://github.com/python/cpython/commit/b5bfb9f38c786c3330b2d52d93b664588c42283d in 2002), and there are all kinds of weird rumors circulating about whether tkinter is

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: Wait a second... I think I noticed another similar bug. In Tkapp_CallProc. Same case, Tkapp_CallArgs and Tkapp_CallDeallocArgs are called when not holding both locks. The attached example doesn't use Python event handlers, so it didn't manifest it

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: Attached reproducing example for event handlers. If launching more than one EventThread, it abort()'s immediately. -- Added file: https://bugs.python.org/file47535/TkinterHanders.py ___ Python tracker &

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47536/TkinterHanders.py ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bugs-list m

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Removed file: https://bugs.python.org/file47535/TkinterHanders.py ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bug

[issue33316] PyThread_release_lock always fails

New submission from Ivan Pozdeev : In win7 x64 debug mode with thread_debug=1, every PyThread_release_lock() is accompanied with a message on stderr: Could not PyThread_release_lock() error: 0 -- components: Interpreter Core, Windows messages: 315497 nosy: Ivan.Pozdeev, paul.moore

[issue33316] PyThread_release_lock always fails

Change by Ivan Pozdeev : -- keywords: +patch pull_requests: +6237 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33316> ___ ___ Py

[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 gro

[issue33316] PyThread_release_lock always fails

Ivan Pozdeev added the comment: In all PyMUTEX_* and most PyCOND_* functions, all the underlying APIs are void. So there's no point for the functions to return anything other than as convention. A comment at the start of condvar.h says: "APIs generally return 0 on success and n

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: Finally dug up the reason but unsure how to fix it. Here's the trace. The format is `$TID: $FUNCTION [some of the args]' 0x1A34: Tkapp_Call(_object *, _object *) 0x1A34: PythonCmd(void *, Tcl_Interp *, int, const char * *) 0x0230f430 0x00

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > Look like the only way is to rearrange Tcl stack frames so that the right one > is on top. Scratch that. Tkinter allows to execute entire scripts where the order of the frames is important. -- ___ Python t

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47561/TkinterHanders3.py ___ Python tracker <https://bugs.python.org/issue33257> ___ ___ Python-bug

[issue33412] Tkinter hangs if using multiple threads and event handlers

New submission from Ivan Pozdeev : With threaded Tkinter, TkinterHanders3.py from https://bugs.python.org/issue33257 (attached) hangs. Tracing with thread_debug and a modified trace.py (to show TIDs, attached) shows that worker threads are waiting for the Tcl lock while the main thread that

[issue33412] Tkinter hangs if using multiple threads and event handlers

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47563/trace.zip ___ Python tracker <https://bugs.python.org/issue33412> ___ ___ Python-bugs-list mailin

[issue33412] Tkinter hangs if using multiple threads and event handlers

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47564/trace.py ___ Python tracker <https://bugs.python.org/issue33412> ___ ___ Python-bugs-list mailin

[issue33412] Tkinter hangs if using multiple threads and event handlers

Ivan Pozdeev added the comment: > worker threads are waiting for the Tcl lock Pardon. They are waiting for Tkapp_ThreadSend()s into the main thread to return. The effect is still the same. -- ___ Python tracker <https://bugs.python.org/issu

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: Here are the possible courses of action to fix this. All require design changes, thus can be shot down on a whim. So I'll ask for advice and approval at python-dev first, to be sure that my efforts won't be scrapped. First, some terminology I&#

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > So this issue doesn't occur when linked with a thread-aware Tcl/Tk, right? Maybe we should just make sure that's the only configuration we ensure? This would break compatibility, including some usage patterns (see the "Reuse the threade

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > I ran TkinterCrash3-2-2.py 15 times on 64-bit Win10, installed x64 3.6.5, > with tk 8.6.8, and experienced no crashes. I wrote in the initial message that this bug only happens with nonthreaded Tcl, regardless of Python version and Tcl version. I&#x

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > Ivan, as I also said there, it is not clear to me, given your subsequent > comments, what you consider to be the status of the PR. The PR fixes the problem exposed by TkinterCrash2-2.py and TkinterCrash3-2-2.py and only lacks an autotest (I asked f

[issue33412] Tkinter hangs if using multiple threads and event handlers

Ivan Pozdeev added the comment: > Do you have a suggestion for what to do short of dropping Tkinter support? Didn't really look into this. At first glance, from the trace log, the main thread seems to grab a lock at some initial point, and then tries to grab it again when running

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > An automated test would need to fail more consistently, without needing to > click. Running faster would also be good (and perhaps increase failure > rate). The the test would be that the file runs in subprocess without an > error (perhaps mu

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: > Is threaded tcl just a compile switch, as with CPython? Yes. In tcl.vcxproj, tk.vcxproj and tix.vcxproj, there are parameters named like TclOpts that are passed as OPTS arg to the lib's makefiles. For Tcl 8.5, you need to pass "threads&q

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: ... Finally, since https://bugs.python.org/issue30916, the 3.x Windows build uses a binary external and needs even more patching to build and link against a debug and/or custom Tcl/Tk (too long to describe, can give a patch

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi added the comment: Mariatta, > While I understand why it behaves the way it is now, but it seems wrong > behavior. Perhaps we should look into finding a solution. I am all in favour of dropping implicit function scope in comprehensions (mostly because of weirdnes

[issue33346] Syntax error with async generator inside dictionary comprehension

Ivan Levkivskyi added the comment: My guess this is a consequence of the implicit function scope in comprehensions, see https://bugs.python.org/issue3692 I would say a proper solution would be to drop the implicit function scope in favour of other mechanisms, but this will require some work

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi added the comment: See https://bugs.python.org/issue33346 for yet another example where implicit function scope complicates life. -- ___ Python tracker <https://bugs.python.org/issue3

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

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue7> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33416] Add endline and endcolumn to every AST node

New submission from Ivan Levkivskyi : Some Python tools (in particular I am interested in type checkers) will benefit from knowing where a given expression ends to indicate/highlight location of an error in the source code. Other tools and IDEs may have also some other benefits. Currently

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

Ivan Levkivskyi added the comment: > Could you please product a draft PR showing how that would work? It might not be accepted right away but it would be useful to have. It is not 100% clear to whom this was addressed. Anyway, Semyon, if you don't have time, then I can make a s

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47565/0001-Build-non-threaded-debug-Tcl.zip ___ Python tracker <https://bugs.python.org/issue33

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Change by Ivan Pozdeev : Added file: https://bugs.python.org/file47566/0001-build-2.7-with-threaded-Tcl.patch ___ Python tracker <https://bugs.python.org/issue33

[issue33420] __origin__ invariant broken

Ivan Levkivskyi added the comment: Yes, the comment needs to be updated, but as you said, no guaranties about undocumented dunder attribute. We tried to preserve as much of the API as possible in 3.7 after PEP 560, but something needs to be sacrificed (especially in the purely internal API

[issue33412] Tkinter hangs if using multiple threads and event handlers

Ivan Pozdeev added the comment: > Another possibility is for stop() to change conditions so that > 'self.target.event_generate(c)' fails with an exception Could you elaborate? Since there're no docs on event_generate(), I can't look up how to make it "fail with

[issue33412] Tkinter hangs if using multiple threads and event handlers

Ivan Pozdeev added the comment: Attached a fixed script. `Tk.after()` works from a worker thread, while `Tk.destroy()` doesn't. That's because Tkinter implements Tcl calls (_tkinter.c:Tkapp_Call) from another thread by posting an event to the interpreter's queue (Tcl_Thread

[issue33412] Tkinter hangs if using multiple threads and event handlers

Ivan Pozdeev added the comment: > Without thread support, event generation from multiple threads fails > immediately. This ticket is for threaded Tcl only, so this is off topic. In nonthreaded Tcl, this script crashes rather than freezes, for an entire ly different reason that I a

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

Change by Ivan Levkivskyi : -- assignee: -> levkivskyi ___ Python tracker <https://bugs.python.org/issue33315> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi added the comment: > Bug or not this is not going to change without a PEP, so I'm not sure it's a > good idea to keep this issue open. I agree this requires a PEP. I would like to keep this open as a place for pre-PEP discussions among those interested (and a

[issue32717] Document PEP 560

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +6419 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue32717] Document PEP 560

Ivan Levkivskyi added the comment: New changeset bd5f96581bf23f6d05fc106996428a8043b6b084 by Ivan Levkivskyi in branch 'master': bpo-32717: Document PEP 560 (GH-6726) https://github.com/python/cpython/commit/bd5f96581bf23f6d05fc106996428a

[issue32717] Document PEP 560

Change by Ivan Levkivskyi : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi : -- pull_requests: +6423 ___ Python tracker <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28556] typing.py upgrades

Ivan Levkivskyi added the comment: New changeset 43d12a6bd82bd09ac189069fe1eb40cdbc10a58c by Ivan Levkivskyi in branch 'master': bpo-28556: Minor fixes for typing module (GH-6732) https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40

[issue33420] [typing] __origin__ invariant broken

Ivan Levkivskyi added the comment: This is now fixed on master by https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc10a58c (the comment is updated). -- resolution: -> fixed stage: -> resolved status: open -&g

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi : -- pull_requests: +6445 ___ Python tracker <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi : -- pull_requests: +6446 ___ Python tracker <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33257] Race conditions in Tkinter with non-threaded Tcl

Ivan Pozdeev added the comment: The 1st PR is ready. I'll continue working on the 2nd one in this ticket, too, if there are no objections. -- ___ Python tracker <https://bugs.python.org/is

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33480] Improvement suggestions for urllib.parse.urlparser

Ivan Pozdeev added the comment: Such drastic changes of uncertain usefulness are best discussed at python-ideas first. What you're really asking for seems to be to parse all "levels" at the same time. Try to think of a use case that would make that help anything practical and

[issue33479] Document tkinter and threads

Ivan Pozdeev added the comment: I was composing a letter to python-dev with all I know of how tkinter works with regard to threads and Tcl, and the fixing plans so that we're all on the same page if you wish to participate. I'm no longer sure if it belongs in the mailing list so

[issue33491] mistype of method's name

New submission from Ivan Gushchin : This link https://docs.python.org/2/library/unittest.html#unittest.SkipTest names method from Capital letter. At the same time method name (according to help(unittest) ) is skipTest (starting lowercase). For those who reads documentation online this

[issue33421] Missing documentation for typing.AsyncContextManager

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue33421> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: New changeset f2290fb19a9b1a5fbeef0971016f72683e8cd1ad by Ivan Levkivskyi (Andrés Delfino) in branch 'master': bpo-32769: Write annotation entry for glossary (GH-6657) https://github.com/python/cpython/commit/f2290fb19a9b1a5fbeef0971016f72

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: Maybe we can consider backporting this to 3.7? Andrés, if you think it makes sense, you can cherry-pick the commit and open a PR against 3.7 branch. -- ___ Python tracker <https://bugs.python.org/issue32

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: Yes, all this also applies to 3.6. -- ___ Python tracker <https://bugs.python.org/issue32769> ___ ___ Python-bugs-list mailin

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: > ... but annotations are a slightly more general concept because they may be > used for other purposes than to indicate the type of a variable ... Yes, I agree. -- ___ Python tracker <https://bugs.p

[issue33479] Document tkinter and threads

Ivan Pozdeev added the comment: > This seems very complicated. The official line on threads for Tk has always > been to make all Tk calls from one thread, which is at least predictable and > comprehensible. Is there any reason for Tkinter to suggest anything different? Tcl/Tk doesn

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: What I think Guido might mean is that some type annotations are not strictly speaking type hints. For example, `dataclasses.InitVar`, is not really a type, it is just a way to indicate how constructor should be constructed. I could see similar potential

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi added the comment: Yes, local annotations are important and should be mentioned (maybe even with an example). -- ___ Python tracker <https://bugs.python.org/issue32

[issue33316] Windows: PyThread_release_lock always fails

Ivan Pozdeev added the comment: > So I would drop the pretense and make these fns void. Scratch that. In POSIX, they are #define'd as pthread fns which do return an error code. So, nothing more to do here. -- ___ Python tracker

[issue33479] Document tkinter and threads

Ivan Pozdeev added the comment: @markroseman replied to python-dev since those perspectives are off topic for this ticket. -- ___ Python tracker <https://bugs.python.org/issue33

[issue31623] Allow to build MSI installer from the official tarball

New submission from Ivan Pozdeev : Since the last version of 3.4 is only made available as a source tarball, it's imperative to be able to make a distributable package locally from it. Tools/msi/msi.py only works from an `hg' checkout. -- components: Build messages: 3

[issue31623] Allow to build MSI installer from the official tarball

Change by Ivan Pozdeev : -- keywords: +patch nosy: -r.david.murray Added file: https://bugs.python.org/file47176/0001-Support-making-MSI-installer-from-tarball.patch ___ Python tracker <https://bugs.python.org/issue31

[issue31623] Allow to build MSI installer from the official tarball

Change by Ivan Pozdeev : -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.org/issue31623> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31623] Allow to build MSI installer from the official tarball

Ivan Pozdeev added the comment: With this patch, I managed to make a working installer. There's nothing in PCBuild/readme.txt about making an installer, and this is the only relevant tool I found in the source. If there's another, feel free to close the ticket, and I'll create

[issue31623] Allow to build MSI installer from the official tarball

Ivan Pozdeev added the comment: > Assuming 3.4 is packagable using msi and hg is the only problem, I presume > you could use an hg-git adapter to get an hg checkout to build from. An official source tarball, by definition, should be able to be built from itself, and contain tools for th

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