Batuhan Taskaya added the comment:
My source: https://www.ibm.com/support/pages/aix-support-lifecycle-information
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Does AIX 5.3 officially supported by IBM? As far as I can locate, it is
deprecated long time ago.
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19494
pull_request: https://github.com/python/cpython/pull/20193
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19493
pull_request: https://github.com/python/cpython/pull/20192
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19492
pull_request: https://github.com/python/cpython/pull/20191
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
components: +Interpreter Core
type: -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
$ python3.8
Python 3.8.0+ (heads/3.8:b9e5547f58, Nov 28 2019, 19:18:03)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +19459
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20156
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40662>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Batuhan Taskaya :
>>> from __future__ import annotations
>>> a: Type[int, str]
>>> b: Type[(int, str, *types)]
>>> __annotations__
{'a': 'Type[int, str]', 'b': 'Type[int, str, *types]'}
>>> ast.parse(__annotations__["b"
Change by Batuhan Taskaya :
--
pull_requests: +19455
pull_request: https://github.com/python/cpython/pull/20152
___
Python tracker
<https://bugs.python.org/issue38
Batuhan Taskaya added the comment:
@RobHammann it should be resolved now, please feel free to re-open issue if you
get into trouble (I manually tested on solaris)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Batuhan Taskaya :
--
pull_requests: +19439
pull_request: https://github.com/python/cpython/pull/20134
___
Python tracker
<https://bugs.python.org/issue38
Change by Batuhan Taskaya :
--
pull_requests: +19438
pull_request: https://github.com/python/cpython/pull/20133
___
Python tracker
<https://bugs.python.org/issue38
Batuhan Taskaya added the comment:
> "Availability: Windows, Linux, Unix systems supporting
> CLOCK_THREAD_CPUTIME_ID." covers AIX.
That was my thought too, thanks again!
--
___
Python tracker
<https://bugs.py
Batuhan Taskaya added the comment:
Should we mention about AIX support in availability section @vstinner?
https://docs.python.org/3/library/time.html#time.thread_time
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
current:
>>> import time
>>> import time
>>> time.get_clock_info('thread_time')
namespace(adjustable=False,
implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True,
resolution=0.01)
>>> time.thread_ti
Batuhan Taskaya added the comment:
See issue 39562
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40604>
___
___
Python-bugs-list mailin
Change by Batuhan Taskaya :
--
pull_requests: +19354
pull_request: https://github.com/python/cpython/pull/20045
___
Python tracker
<https://bugs.python.org/issue39
Batuhan Taskaya added the comment:
@rhettinger can you clarify how does this arguments act on argv? Should they be
hidden like the first argument, or should they remain visible as a passing
argument?
$ python -c 'import sys;print(sys.argv)'
['-c']
$ python -c
New submission from Batuhan Taskaya :
>>> dbm.open("/tmp/x.db", "n").close()
>>> from pathlib import Path
>>> tmp = Path("/tmp")
>>> dbm.open(tmp / "x.db", "n").close()
Traceback (most recent call last):
Fi
Batuhan Taskaya added the comment:
Any news about this? Should we revert the commit for 3.9?
--
___
Python tracker
<https://bugs.python.org/issue40244>
___
___
Batuhan Taskaya added the comment:
Thank you all for your reviews for styling, also I have to thank
https://github.com/CyberSaxosTiGER for his external reviews on the color scheme.
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Next is using asdl_int_seq for all simple sum types, and not for only cmpop.
Looks like it is hardcoded to use it, and I plan to refactor this in a way that
might save some time in python implementation of classes (also it will solve
this bug
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40546>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
I've updated the PR with bold_dark_blue.png changes.
--
___
Python tracker
<https://bugs.python.org/issue40517>
___
___
Pytho
Batuhan Taskaya added the comment:
I've updated PR 17715 in order to point out exact field that error happened.
Also it now only shows type
>>> import ast
>>> expr_without_lineno_but_ok =
>>> ast.Expression(body=ast.BinOp(left=ast.Num(n=2), right=as
Batuhan Taskaya added the comment:
I've found a bold dark blue, which I guess suits both your and @terry.reedy
recommendations. How does bold_dark_blue.png looks?
--
Added file: https://bugs.python.org/file49138/bold_dark_blue.png
___
Python
Batuhan Taskaya added the comment:
> I tried both a laptop and desktop and slightly prefer unbolded. How about a
> darker blue?
Sorry but I have no control over styles. They are pre-defined, I only change
the token type and pygments handles the rest of it. I dont know if such a
Batuhan Taskaya added the comment:
Attaching 2 different styles python_bold.png (module is bold) and
asdl_no_style.png (module has no style)
--
Added file: https://bugs.python.org/file49135/python_bold.png
___
Python tracker
<ht
Change by Batuhan Taskaya :
Added file: https://bugs.python.org/file49136/asdl_no_style.png
___
Python tracker
<https://bugs.python.org/issue40517>
___
___
Python-bug
Batuhan Taskaya added the comment:
(by the way, I did not push this change. I'll push it when you think it is
ready)
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Unfortunately there aren't many `bold` type tokens I can use, so I had to
change color of module . If you wish I can make both class names and
`Python` bold, or keep it in this way.
--
Added file: https://bugs.python.org/file49134/asdl2.png
Change by Batuhan Taskaya :
--
pull_requests: +19283
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19968
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
pull_requests: +19282
pull_request: https://github.com/python/cpython/pull/19967
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Hey Raymond, can you give me your feedback on asdl.png (the screenshot of new
theme)?
--
Added file: https://bugs.python.org/file49133/asdl.png
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
A real world example would be tools like `unimport`, that try to remove a
certain part of import by looking start/end column offsets. Before (lib2to3),
it was using tokens to manipulate source, and what I can tell is that having
position information
Batuhan Taskaya added the comment:
Oh, I confuse with it identifier. IMHO replacing identifier with Constant would
infer position in some cases.
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
> I was also thinking about getting rid of "string" nodes and just use Constant
> for those. Having the strings raw make the AST inconsistent because nodes
> that are 'strings' do not have line numbers and other metadata, making
Batuhan Taskaya added the comment:
Currently working on implementing some items from this TODO
https://github.com/eliben/asdl_parser/blob/master/TODO
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
> You just read my thoughts. That's what I was going to do tonight. ;)
:) Awesome. Well I'll plan to continue this; @pablogsal and I was discussing
the idea of extracting _ast.AST subclasses to python level (which would save a
lot of time for new additi
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +19268
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19952
___
Python tracker
<https://bugs.python.org/issu
New submission from Batuhan Taskaya :
- Better error messages with punctuation
- Py_UNREACHABLE() for unreachable states
- Removal of several 'unused' and 'undocumented (in Zephyr ASDL spec) built-in
types.
--
components: Interpreter Core
messages: 368235
nosy: BTaskaya
priority
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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 you didn't
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 trig
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
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
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
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
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
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
Change by Batuhan Taskaya :
--
dependencies: +Default values for AST Nodes
___
Python tracker
<https://bugs.python.org/issue40483>
___
___
Python-bugs-list mailin
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 d
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40438>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issue40344>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Batuhan Taskaya :
--
keywords: -patch
___
Python tracker
<https://bugs.python.org/issue40344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
pull_requests: -19105
___
Python tracker
<https://bugs.python.org/issue40344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
pull_requests: +19104
pull_request: https://github.com/python/cpython/pull/19782
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19105
pull_request: https://github.com/python/cpython/pull/19782
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Sorry for the noise, wrong issue (thought 344, but actually was 334)
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: -19103
___
Python tracker
<https://bugs.python.org/issue40344>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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.
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). B
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
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
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
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
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
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40360>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
pull_requests: +18961
pull_request: https://github.com/python/cpython/pull/19636
___
Python tracker
<https://bugs.python.org/issue38
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/issue40
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
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
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue37006>
___
___
Python-bug
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40335>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<
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
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue38605>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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"
Change by Batuhan Taskaya :
--
pull_requests: +18873
pull_request: https://github.com/python/cpython/pull/19523
___
Python tracker
<https://bugs.python.org/issue39
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
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
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 modu
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
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);
<<<<
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 triaging
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
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscribe:
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]: /opt/IBM/xlc/16.1.0
Batuhan Taskaya added the comment:
Adding issue 39981 as a dependency.
--
dependencies: +Default values for AST Nodes
___
Python tracker
<https://bugs.python.org/issue36
Change by Batuhan Taskaya :
--
pull_requests: +18789
pull_request: https://github.com/python/cpython/pull/19435
___
Python tracker
<https://bugs.python.org/issue39
Change by Batuhan Taskaya :
--
pull_requests: +18788
pull_request: https://github.com/python/cpython/pull/19434
___
Python tracker
<https://bugs.python.org/issue39
Change by Batuhan Taskaya :
--
pull_requests: +18781
pull_request: https://github.com/python/cpython/pull/19423
___
Python tracker
<https://bugs.python.org/issue39
Change by Batuhan Taskaya :
--
pull_requests: +18778
pull_request: https://github.com/python/cpython/pull/19418
___
Python tracker
<https://bugs.python.org/issue39
401 - 500 of 656 matches
Mail list logo
