[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: > I am understanding "crashing" as "segfaulting" "crashing" as in the test result but not segfaulting 0:00:00 load avg: 1.71 Run tests in parallel using 2 child processes 0:00:01 load avg: 1.70 [1/1/1] t

[issue40094] Add os.waitstatus_to_exitcode() function

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40094> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: isidentical@gcc-solaris11:~$ cpython/python Python 3.9.0a5+ (heads/master:98ff332, Apr 2 2020, 01:20:22) [GCC 5.5.0] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> im

[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: I tested with both PR 19312 and PR 19308 and I still have the same crash 0:00:00 load avg: 0.80 Run tests in parallel using 2 child processes 0:00:01 load avg: 0.79 [1/1/1] test_builtin crashed (Exit code -1

[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: isidentical@gcc-solaris11:~/cpython$ ./python -m test test_builtin -m test_input_no_stdout_fileno -F -j10 -v == CPython 3.9.0a5+ (heads/master:dc4e965, Apr 2 2020, 23:53:26) [GCC 5.5.0] == Solaris-2.11-sun4u-sparc-32bit big-endian == cwd: /export/home

[issue35455] Solaris thread_time doesn't work with current implementation

Batuhan Taskaya added the comment: This issue is still valid under other solaris/sunos versions. @kulikjak are you still interested in resolving this issue? -- nosy: +BTaskaya resolution: not a bug -> status: closed -> open versions: +Pyth

[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: Victor, PR 19314 works perfectly. -- ___ Python tracker <https://bugs.python.org/issue40140> ___ ___ Python-bugs-list mailin

[issue40140] test_builtin crashes when runned in parallel mode on solaris

Batuhan Taskaya added the comment: > There is no more Solaris buildbot. Solaris 11.4 will be likely the last > release: Oracle no longer supports Solaris. Well, if needed I can create one but looks like it is going be an obsoleted OS

[issue40165] Hide stderror from the user if command failes

New submission from Batuhan Taskaya : This is an optional test that would only run if stty size returns a valid output, but if errors I dont think it makes sense to just print that error inside of test logs, there is already a noticement for skipped test. -- components: Tests

[issue40165] Hide stderror from the user if command failes

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18690 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19325 ___ Python tracker <https://bugs.python.org/issu

[issue40176] unterminated string literal tokenization error messages could be better

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 1.0 -> 2.0 pull_requests: +18710 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19346 ___ Python tracker <https://bugs.python.org/i

[issue40176] unterminated string literal tokenization error messages could be better

Batuhan Taskaya added the comment: >>> message = "sadsa File "", line 1 message = "sadsa ^ SyntaxError: unterminated double quote -- ___ Python tracker <ht

[issue40180] isinstance(cls_with_metaclass, non_type) raises KeyError

Batuhan Taskaya added the comment: What would you expect in this case? Objects/abstract.c:2429 is where the isinstance code. If only returning False would be enough, something like this (untested) would be enough --- a/Objects/abstract.c +++ b/Objects/abstract.c @@ -2436,6 +2436,10

[issue40184] Compiler warnings under sparc64

New submission from Batuhan Taskaya : gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include

[issue40184] Compiler warnings under sparc64

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18731 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19369 ___ Python tracker <https://bugs.python.org/issu

[issue40186] test_notify_all hangs forever in sparc64

New submission from Batuhan Taskaya : isidentical@gcc202:~/cpython$ ./python -m test test_multiprocessing_fork -m test_notify_all -v == CPython 3.9.0a5+ (heads/bpo-40184:b2504dfd51, Apr 4 2020, 23:55:00) [GCC 9.3.0] == Linux-5.4.0-4-sparc64-smp-sparc64-with-glibc2.31 big-endian == cwd: /home

[issue40186] test_notify_all hangs forever in sparc64

Batuhan Taskaya added the comment: This behavior looks random, for 10 run it hangs 2 times. -- ___ Python tracker <https://bugs.python.org/issue40186> ___ ___

[issue36630] failure of test_colors_funcs in test_curses with ncurses 6.1

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue36630> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40190] Add support for _SC_AIX_REALMEM in posix.sysconf

New submission from Batuhan Taskaya : We already have support for linux alternatives of this (PHYS_PAGES * PAGESIZE), it would good to add AIX_REALMEM to sysconf for AIX. -- components: Library (Lib) messages: 365804 nosy: BTaskaya priority: normal severity: normal status: open title

[issue40190] Add support for _SC_AIX_REALMEM in posix.sysconf

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18742 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19380 ___ Python tracker <https://bugs.python.org/issu

[issue40188] Azure Pipelines jobs failing randomly with: Unable to connect to azure.archive.ubuntu.com

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 2.0 -> 3.0 pull_requests: +18743 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19380 ___ Python tracker <https://bugs.python.org/i

[issue40188] Azure Pipelines jobs failing randomly with: Unable to connect to azure.archive.ubuntu.com

Change by Batuhan Taskaya : -- keywords: -patch stage: patch review -> ___ Python tracker <https://bugs.python.org/issue40188> ___ ___ Python-bugs-list mai

[issue40192] time.thread_time isn't outputting in nanoseconds in AIX

New submission from Batuhan Taskaya : The resolution for thread_time is really low on AIX, but fortunately there is a way to get thread time in nanoseconds with thread_cputime. -bash-4.4$ ./python Python 3.9.0a5+ (heads/master:909f4a3, Apr 4 2020, 20:15:24) [C] on aix Type "help",

[issue40192] time.thread_time isn't outputting in nanoseconds in AIX

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18744 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19381 ___ Python tracker <https://bugs.python.org/issu

[issue40192] time.thread_time isn't outputting in nanoseconds in AIX

Change by Batuhan Taskaya : -- nosy: +belopolsky, p-ganssle ___ Python tracker <https://bugs.python.org/issue40192> ___ ___ Python-bugs-list mailing list Unsub

[issue40193] thread.get_native_id() support for solaris

New submission from Batuhan Taskaya : Solaris supports accessing the native id of thread via pthread_self() https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032i/index.html#tlib-89129 -- messages: 365808 nosy: BTaskaya priority: normal severity: normal status: open title

[issue40193] thread.get_native_id() support for solaris

Batuhan Taskaya added the comment: Looks like neither pthread_self nor thr_self gives the native id. Closing the issue... -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bug

[issue40200] count 0 crash

Batuhan Taskaya added the comment: Closing issue since it is not a bug, at least a bug of python itself. Feel free to post any questions to python-list mailing list. https://mail.python.org/mailman/listinfo/python-list -- nosy: +BTaskaya resolution: -> not a bug stage: -> re

[issue40207] Expose NCURSES_EXT_FUNCS under curses

New submission from Batuhan Taskaya : NCURSES_EXT_FUNCS defines the extension version number which is needed to determine if certain functions exist or not. -- components: Library (Lib) messages: 365866 nosy: BTaskaya priority: normal severity: normal status: open title: Expose

[issue40207] Expose NCURSES_EXT_FUNCS under curses

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18755 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19392 ___ Python tracker <https://bugs.python.org/issu

[issue40208] Remove deprecated SymbolTable.has_exec

New submission from Batuhan Taskaya : SymbolTable's has_exec method deprecated 14 years ago (2006) with 2def557aba1aaa42b638f9bf95624b7e6929191c, it can be safely removed since there is no user of it. -- components: Library (Lib) messages: 365874 nosy: BTaskaya priority: n

[issue40208] Remove deprecated SymbolTable.has_exec

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18758 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19396 ___ Python tracker <https://bugs.python.org/issu

[issue40211] Clarify preadv and pwritev is supported AIX 7.1 and newer.

New submission from Batuhan Taskaya : preadv and pwritev are supported on AIX 7.1 and newer, it would be good to clarify this in the documentation. -- assignee: docs@python components: Documentation messages: 365880 nosy: BTaskaya, docs@python, pablogsal priority: normal severity

[issue40211] Clarify preadv and pwritev is supported AIX 7.1 and newer.

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18762 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19401 ___ Python tracker <https://bugs.python.org/issu

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

Batuhan Taskaya added the comment: #define IS_COMPILER_FLAG_ENABLED(c, flag) printf("%s: %d\n", #flag, c->c_flags->cf_flags & flag) > If CO_FUTURE_DIVISION conflicts with PyCF_ALLOW_TOP_LEVEL_AWAIT, does not > CO_ITERABLE_COROUTINE conflict with PyCF_SOURCE_IS_UTF8

[issue40212] Re-enable posix_fallocate and posix_fadvise on AIX

New submission from Batuhan Taskaya : fallocate and fadvise was problematic in AIX because of a bug that presents at the time of 2014, which looks like resolved in 2016. I think we can safely re-enable those functions back. I've tested this patch on AIX 7.2 and it works, this patch will

[issue40212] Re-enable posix_fallocate and posix_fadvise on AIX

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18765 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19403 ___ Python tracker <https://bugs.python.org/issu

[issue40212] Re-enable posix_fallocate and posix_fadvise on AIX

Change by Batuhan Taskaya : -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue40212> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40216] Support --runstatedir in configure

New submission from Batuhan Taskaya : AC allows to set runstatedir but looks like python's configure is a bit outdated, it requires to be regenerated. -- components: Build messages: 365909 nosy: BTaskaya priority: normal severity: normal status: open title: Support --runstated

[issue40216] Support --runstatedir in configure

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18771 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19411 ___ Python tracker <https://bugs.python.org/issu

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Batuhan Taskaya added the comment: @gvanrossum is new types going to support generic alias protocol or this subset will be kept? Like typeshed uses os.DirEntry as a generic, but in reality it is not. (https://github.com/python/cpython/pull/17561) -- nosy: +BTaskaya

[issue39019] Missing class getitems in standard library classes

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39019> ___ ___ Pyth

[issue39019] Missing class getitems in standard library classes

Batuhan Taskaya added the comment: PEP 585 is landed, closing the issue (and linked PRs) -- ___ Python tracker <https://bugs.python.org/issue39019> ___ ___ Pytho

[issue39019] Missing class getitems in standard library classes

Batuhan Taskaya added the comment: > Hold on, os.DirEntry[str] still doesn't work. That is what I asked on the issue 39481. I couldn't find anything about its cover on PEP 585. -- ___ Python tracker <https://bugs.pytho

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18775 pull_request: https://github.com/python/cpython/pull/19415 ___ Python tracker <https://bugs.python.org/issue39

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18778 pull_request: https://github.com/python/cpython/pull/19418 ___ Python tracker <https://bugs.python.org/issue39

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18781 pull_request: https://github.com/python/cpython/pull/19423 ___ Python tracker <https://bugs.python.org/issue39

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18788 pull_request: https://github.com/python/cpython/pull/19434 ___ Python tracker <https://bugs.python.org/issue39

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

Change by Batuhan Taskaya : -- pull_requests: +18789 pull_request: https://github.com/python/cpython/pull/19435 ___ Python tracker <https://bugs.python.org/issue39

[issue36287] Make ast.dump() not output optional default fields

Batuhan Taskaya added the comment: Adding issue 39981 as a dependency. -- dependencies: +Default values for AST Nodes ___ Python tracker <https://bugs.python.org/issue36

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: I've just compiled python with (xlc 16.1.0, debug build) and can't experience that compile failure, can you give a specific spot that failure happens? -bash-4.4$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS' sysconfig[CC]:

[issue40267] Error message differs when an expression is in an fstring

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40267> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40176] unterminated string literal tokenization error messages could be better

Batuhan Taskaya added the comment: Fair point. I changed error messages to what you suggested >>> (300) * 6 + ca(e, 2 +"dsadsa) File "", line 1 (300) * 6 + ca(e, 2 +"dsadsa) ^ SyntaxError: unterminated string lit

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: Oh, looks like the problem is --without-computed-gotos, I just tried 2 times one is with --without-computed-gotos and one is not. I could successfully reproduce the problem with it. I'll continue tri

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: @Michael.Felt can you just insert some prints between these 3 to see what is going on (and re-compile) static void gen_dealloc(PyGenObject *gen) { PyObject *self = (PyObject *) gen; <<<< _PyObject_GC_UNTRACK(gen); <<<<

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: By the noticed something that looks kind of weird, not sure if it is intentional or not but shouldn't this be self instead of gen static void gen_dealloc(PyGenObject *gen) { PyObject *self = (PyObject *) gen; <<<< _PyObject_GC_UNTRACK(

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > With the print statements - it does not crash: I think this isn't directly relevant with prints but about re-compiling? (just guessing). Because I experienced when I compile python for the first time on a clean AIX environment, all extension

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > Also tried this: Thanks for it, that was just something that I slightly suspected but expected to see it crash. -- ___ Python tracker <https://bugs.python.org/issu

[issue39522] AST Unparser with unicode kinded constants

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18865 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19512 ___ Python tracker <https://bugs.python.org/issu

[issue39522] AST Unparser with unicode kinded constants

Change by Batuhan Taskaya : -- pull_requests: +18873 pull_request: https://github.com/python/cpython/pull/19523 ___ Python tracker <https://bugs.python.org/issue39

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > No. I do not think it is the real problem either. And I do not know compiler behavior well enough. Actually, considering the setting is still -O0 (aka no optimization) I am surprised it has any effect. if I understood correctly "no return" i

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue38605> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: Moving assertion from _PyObject_GC_TRACK to gen_dealloc (just before the _PyObject_GC_TRACK call) results with success () if (gen->gi_weakreflist != NULL) PyObject_ClearWeakRefs(self); - +_PyObject_ASSERT_FROM(s

[issue28002] ast.unparse can't roundtrip some f-strings

Batuhan Taskaya added the comment: > If that sounds good, I can submit a PR and inform the original author I can't say anything before seeing the approach but fixing the problem definitely sounds good. -- ___ Python tracker

[issue40334] PEP 617: new PEG-based parser

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40335] Regression in multiline SyntaxError offsets

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40335> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37006] Add top level await statement support for doctest

Change by Batuhan Taskaya : -- nosy: +BTaskaya versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue37006> ___ ___ Python-bug

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

Batuhan Taskaya added the comment: > Is there an update of this *release blocker* issue? Should we revert the > commit 9052f7a41b90f2d34011c8da68f9a4facebc8a97? I dont think we can gain much by reverting 9052f7a41b90f2d34011c8da68f9a4facebc8a97 because it doesn't introduce a new

[issue39562] Asynchronous comprehensions don't work in asyncio REPL

Batuhan Taskaya added the comment: GH 19230: (.venv) [ 6:17PM ] [ isidentical@threeheadedgiant:~ ] $ ./cpython/python z.py ** File "/home/isidentical/doctest.txt", line 4, in doctest.txt Failed example: await

[issue40355] The ast module fails to reject certain malformed nodes

Batuhan Taskaya added the comment: See https://bugs.python.org/msg360767 for ast.unparse's point of view regarding malformed nodes. -- nosy: +BTaskaya, pablogsal ___ Python tracker <https://bugs.python.org/is

[issue38870] Expose ast.unparse in the ast module

Change by Batuhan Taskaya : -- pull_requests: +18961 pull_request: https://github.com/python/cpython/pull/19636 ___ Python tracker <https://bugs.python.org/issue38

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40360> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40366] Start giving deprecation warnings for obsoleted flags in compile

New submission from Batuhan Taskaya : We can start deprecating usage of obsoleted flags in compile and slowly remove support for them. An example would be CO_NESTED. https://github.com/python/cpython/blob/master/Python/bltinmodule.c#L748 -- messages: 367046 nosy: BTaskaya priority

[issue40366] Start giving deprecation warnings for obsoleted flags in compile

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +18986 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19660 ___ Python tracker <https://bugs.python.org/issu

[issue40366] Start giving deprecation warnings for obsoleted flags in compile

Batuhan Taskaya added the comment: As suggestion of @vstinner, instead of deprecation we decided to remove support for these flags immediately. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40366] Remove support for obsolete flags in compile function

Change by Batuhan Taskaya : -- title: Start giving deprecation warnings for obsoleted flags in compile -> Remove support for obsolete flags in compile function ___ Python tracker <https://bugs.python.org/issu

[issue40378] ast.parse fails to trigger SyntaxWarning that normal execution does

Batuhan Taskaya added the comment: This is probably because that these warnings raised during code generation, rather then AST Validation / generation. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40

[issue40378] ast.parse fails to trigger SyntaxWarning that normal execution does

Batuhan Taskaya added the comment: > This does seem like a bug and prematurely closed, I'm a bit disappointed in > the current resolution I would love to see it moved as a new step in the execution pipeline that we cane extend easily and use externally (like PyAST_Validate).

[issue40430] ast.Slice is no longer a subclass of ast.slice

Batuhan Taskaya added the comment: This has been discussee and rejected (for certain reasonsons): https://github.com/python/cpython/pull/19056#discussion_r396087689 -- nosy: +BTaskaya, serhiy.storchaka ___ Python tracker <https://bugs.python.

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

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 4.0 -> 5.0 pull_requests: +19103 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19782 ___ Python tracker <https://bugs.python.org/i

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

Change by Batuhan Taskaya : -- pull_requests: -19103 ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Batuhan Taskaya added the comment: Sorry for the noise, wrong issue (thought 344, but actually was 334) -- ___ Python tracker <https://bugs.python.org/issue40

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

Change by Batuhan Taskaya : -- pull_requests: +19105 pull_request: https://github.com/python/cpython/pull/19782 ___ Python tracker <https://bugs.python.org/issue40

[issue40334] PEP 617: new PEG-based parser

Change by Batuhan Taskaya : -- pull_requests: +19104 pull_request: https://github.com/python/cpython/pull/19782 ___ Python tracker <https://bugs.python.org/issue40

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

Change by Batuhan Taskaya : -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ Python-bugs-list mailing list Unsubscrib

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

Change by Batuhan Taskaya : -- keywords: -patch ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ 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: -19105 ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40438> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Batuhan Taskaya added the comment: > This can be closed, but for completeness, the test you ran didn't verify that > the bug was fixed. This is because the hard coded compile flags I gave in my > example seem to have changed in Python 3.9 (is this documented?). Yes, this is

[issue40483] Implementing a verifier function to verify integrity of AST nodes

Change by Batuhan Taskaya : -- dependencies: +Default values for AST Nodes ___ Python tracker <https://bugs.python.org/issue40483> ___ ___ Python-bugs-list mailin

[issue40483] Implementing a verifier function to verify integrity of AST nodes

New submission from Batuhan Taskaya : This is actually a problem that is existing for a long time. A recent example would be the discussion in the GH-19868. Implementation - It should check existence of all fields (like ast.Constant() wont verified) - It should check types of all fields

[issue40484] Document existing compiler flags under ast

New submission from Batuhan Taskaya : PyCF_ALLOW_TOP_LEVEL_AWAIT, PyCF_TYPE_COMMENTS and PyCF_ONLY_AST should be documented just like CO_ flags under inspect module. -- assignee: docs@python components: Documentation messages: 367972 nosy: BTaskaya, docs@python priority: normal

[issue40484] Document existing compiler flags under ast

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19196 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19885 ___ Python tracker <https://bugs.python.org/issu

[issue39159] Ideas for making ast.literal_eval() usable

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19210 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19899 ___ Python tracker <https://bugs.python.org/issu

[issue40517] Syntax highlighting for ASDL

New submission from Batuhan Taskaya : ASDL is around here for a long time, and it was showed as raw text on documentation (under library/ast), IMHO it would be great to highlight it. -- assignee: docs@python components: Documentation messages: 368148 nosy: BTaskaya, docs@python

[issue40517] Syntax highlighting for ASDL

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19243 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19928 ___ Python tracker <https://bugs.python.org/issu

[issue37860] Add deploy preview for docs

Batuhan Taskaya added the comment: > Personally, I feel that it most largely benefits more significant > documentation changes that involve modification of existing markup or the > addition of new markup, rather than all documentation PRs. So a manually > added label to trigger

[issue40517] Syntax highlighting for ASDL

Batuhan Taskaya added the comment: Oh, sorry for that bad look :/ I just want it to look consistent, let me see what I can do further (I'll probably consult a friend of mine who understand this things). By the way, I could've just adjust the values over the existing code if

[issue40355] The ast module fails to reject certain malformed nodes

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

<    1   2   3   4   5   6   7   8   9   >