Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)

On 29/05/24 06:49, Gilmeh Serda via Python-list wrote: Solved by using a different method. Hedonist for hire... no job too easy! This combination of sig-file and content seems sadly ironic. How about CONTRIBUTING to the community by explaining 'the solution' to people who may find a

Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)

On Tue, May 28, 2024 at 9:48 PM Gilmeh Serda via Python-list < python-list@python.org> wrote: > > Solved by using a different method. > > - - - And that was how? TIA -- https://mail.python.org/mailman/listinfo/python-list

Re: Weird Stuff (Markdown, syntax highlighting and Python)

On 5/26/2024 2:28 AM, Gilmeh Serda via Python-list wrote: The web claims (I think on all pages I've read about Markdown and Python) that this code should work, with some very minor variants on the topic: ```python import os with open(os.path.join('/home/user/apath', 'somefile')) as f:

Re: Weird Stuff (Markdown, syntax highlighting and Python)

With reference to another reply here, the "Weird stuff" came from reading the question, finding it unclear, and only later realising that whereas most people write Markdown-formatted documents for later processing, or perhaps docstrings in Markdown-format for collection by doc

Re: Weird Stuff (Markdown, syntax highlighting and Python)

On 2024-05-26, Gilmeh Serda via Python-list wrote: > The web claims (I think on all pages I've read about Markdown and Python) > that this code should work, with some very minor variants on the topic: > > ```python > > import os > > with open(os.path.join('/home/user/apath', 'somefile')) as f: >

Re: File write, weird behaviour

On 2/19/2023 6:10 PM, Mats Wichmann wrote: On 2/19/23 14:06, Dieter Maurer wrote: Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500: ... Example 2 (weird behaviour) file = open("D:\Programming\Python\working_with_files\cities.txt", 'r+') ## contains list cities # the following

Re: File write, weird behaviour

On 2/19/23 14:06, Dieter Maurer wrote: Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500: ... Example 2 (weird behaviour) file = open("D:\Programming\Python\working_with_files\cities.txt", 'r+') ## contains list cities # the following code DOES NOT add new record TO THE BEGINNING o

Re: File write, weird behaviour

Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500: > ... >Example 2 (weird behaviour) > >file = open("D:\Programming\Python\working_with_files\cities.txt", >'r+') ## contains list cities ># the following code DOES NOT add new record TO THE BEGINNING of the &

Re: File write, weird behaviour

On 2/19/2023 2:31 PM, Chris Angelico wrote: On Mon, 20 Feb 2023 at 06:24, Thomas Passin wrote: On 2/19/2023 1:53 PM, Chris Angelico wrote: On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov wrote: Example 1 (works as expected) file =

Re: File write, weird behaviour

On 2023-02-19 19:31, Chris Angelico wrote: On Mon, 20 Feb 2023 at 06:24, Thomas Passin wrote: On 2/19/2023 1:53 PM, Chris Angelico wrote: > On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov > wrote: >> >> Example 1 (works as expected) >> >> file =

Re: File write, weird behaviour

On Mon, 20 Feb 2023 at 06:24, Thomas Passin wrote: > > On 2/19/2023 1:53 PM, Chris Angelico wrote: > > On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov > > wrote: > >> > >> Example 1 (works as expected) > >> > >> file = open("D:\Programming\Python\working_with_files\cities.txt", > >> 'r+') ##

Re: File write, weird behaviour

On 2023-02-19 12:59:43 -0500, Thomas Passin wrote: > On 2/19/2023 11:57 AM, Axy via Python-list wrote: > > Looks like the data to be written is buffered, so actual write takes > > place after readlines(), when close() flushes buffers. > > > > See io package documentation, BufferedIOBase. > > > >

Re: File write, weird behaviour

On 2/19/2023 1:53 PM, Chris Angelico wrote: On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov wrote: Example 1 (works as expected) file = open("D:\Programming\Python\working_with_files\cities.txt", 'r+') ## contains list cities Side note: You happened to get lucky with P, w, and c, but for

Re: File write, weird behaviour

On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov wrote: > > Example 1 (works as expected) > > file = open("D:\Programming\Python\working_with_files\cities.txt", > 'r+') ## contains list cities Side note: You happened to get lucky with P, w, and c, but for the future, I recommend using forward

Re: File write, weird behaviour

alling f.close() might result in the arguments of f.write() not being completely written to the disk, even if the program exits successfully." I realize that in the example, close() was called ... but not immediately after the write(). Can't deny, such a behaviour looks utterly weird. Tr

Re: File write, weird behaviour

n") file.close() Example 2 (weird behaviour) file = open("D:\Programming\Python\working_with_files\cities.txt", 'r+') ## contains list cities # the following code DOES NOT add new record TO THE BEGINNING of the file IF FOLLOWED BY readline() and readlines()# Expected behaviou

Re: File write, weird behaviour

) after file.write() Or alternatively, file.seek() to the intended position when switching between reading and writing. (The C standard says you have to do this. I can't find it in the Python docs, but apparently Python behaves the same.) > On 19/02/2023 14:03, Azizbek Khamdamov wrote: > >

Re: File write, weird behaviour

Looks like the data to be written is buffered, so actual write takes place after readlines(), when close() flushes buffers. See io package documentation, BufferedIOBase. The solution is file.flush() after file.write() Can't deny, such a behaviour looks utterly weird. Try to avoid designing

File write, weird behaviour

Example 1 (works as expected) file = open("D:\Programming\Python\working_with_files\cities.txt", 'r+') ## contains list cities # the following code adds new record to the beginning of the file, expected behaviour file.write("new city\n") file.close() Example 2 (weird behavi

[issue210866] re group self-reference weird behavior (PR#2)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue500981] thread_nt.h weird prototype

Change by admin : -- github: None -> 35887 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue485252] weird HTML; typo

Change by admin : -- github: None -> 35586 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue463640] weird namespace phenomenon

Change by admin : -- github: None -> 35220 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue433854] Wrong sys.path in weird situation

Change by admin : -- github: None -> 34639 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue229280] Weird build directory on BSDI

Change by admin : -- github: None -> 33752 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210866] re group self-reference weird behavior (PR#2)

Change by admin : -- github: None -> 32864 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: Weird strace of #! python script

> On 14 Mar 2022, at 21:29, Dan Stromberg wrote: > > I expected to see an exec of /usr/bin/python2, but I don't. I just see an > exec of /tmp/t. I understand that the kernel handles the #! Line itself, which is why you do not see it in strace. Barry --

Re: Weird strace of #! python script

On Tue, 15 Mar 2022 at 08:28, Dan Stromberg wrote: > > Hi folks. > > First off, I know, python2 is ancient history. Porting to 3.x is on my > list of things to do (though I'm afraid it's not yet at the top of the > list), and the same thing happens with python3. > > So anyway, I'm strace'ing a

Weird strace of #! python script

Hi folks. First off, I know, python2 is ancient history. Porting to 3.x is on my list of things to do (though I'm afraid it's not yet at the top of the list), and the same thing happens with python3. So anyway, I'm strace'ing a #!/usr/bin/python2 script. I expected to see an exec of

[issue30570] issubclass segfaults on objects with weird __getattr__

Dennis Sweeney added the comment: Since this isn't quite related to the original issue, I opened bpo-45806 to discuss. -- ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

David Bolen added the comment: So I'm guessing something is just borderline under 3.9 on Windows. In some manual testing with a standalone build of 3.9 so far for me: -m test.test_pickle always succeeds (executed directly) -m test test_pickle always fails (executed via

[issue30570] issubclass segfaults on objects with weird __getattr__

David Bolen added the comment: I don't know if this is a buildbot, test or 3.9-specific issue but this commit appears to have introduced a permanent initial failure (but success on retry) in test_pickle on both Windows 10 3.9 builders. First failure for my builder at

[issue30570] issubclass segfaults on objects with weird __getattr__

Łukasz Langa added the comment: Thanks, Dennis! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Łukasz Langa added the comment: New changeset f701237db2611140e578cebbdfef91ae4714af4e by Łukasz Langa in branch '3.9': [3.9] bpo-30570: Fix segfault on buildbots caused by stack overflow from recursion in tests (GH-29258) (GH-29415)

[issue30570] issubclass segfaults on objects with weird __getattr__

miss-islington added the comment: New changeset 1f3ae5c1ca5a8e7696bad414c1de38e0f5f1e2c3 by Miss Islington (bot) in branch '3.10': bpo-30570: Fix segfault on buildbots caused by stack overflow from recursion in tests (GH-29258)

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by Łukasz Langa : -- pull_requests: +27667 pull_request: https://github.com/python/cpython/pull/29415 ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Łukasz Langa added the comment: New changeset 1e29dce1138a39e095ba47ab4c1e445fd08716e2 by Miss Islington (bot) in branch '3.9': bpo-30570: Use Py_EnterRecursiveCall() in issubclass() (GH-29048) (GH-29178) https://github.com/python/cpython/commit/1e29dce1138a39e095ba47ab4c1e445fd08716e2

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by miss-islington : -- pull_requests: +27666 pull_request: https://github.com/python/cpython/pull/29414 ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Pablo Galindo Salgado added the comment: New changeset d56375a0dd4cee162081b173310298a3d32af293 by Dennis Sweeney in branch 'main': bpo-30570: Fix segfault on buildbots caused by stack overflow from recursion in tests (GH-29258)

[issue30570] issubclass segfaults on objects with weird __getattr__

Dennis Sweeney added the comment: I think this broke some buildbots. https://buildbot.python.org/all/#/builders/256/builds/264 https://buildbot.python.org/all/#/builders/370/builds/263 I opened a PR to temporarily decrease the recursion limit so that the C stack doesn't overflow in these

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by Dennis Sweeney : -- pull_requests: +27522 pull_request: https://github.com/python/cpython/pull/29258 ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by miss-islington : -- pull_requests: +27451 pull_request: https://github.com/python/cpython/pull/29178 ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

miss-islington added the comment: New changeset f812fef2f8f12441ce559335645433c8124e7db5 by Miss Islington (bot) in branch '3.10': bpo-30570: Use Py_EnterRecursiveCall() in issubclass() (GH-29048) https://github.com/python/cpython/commit/f812fef2f8f12441ce559335645433c8124e7db5 --

[issue30570] issubclass segfaults on objects with weird __getattr__

Gregory P. Smith added the comment: New changeset 423fa1c1817abfa8c3d1bc308ddbbd8f28b69d68 by Dennis Sweeney in branch 'main': bpo-30570: Use Py_EnterRecursiveCall() in issubclass() (GH-29048) https://github.com/python/cpython/commit/423fa1c1817abfa8c3d1bc308ddbbd8f28b69d68 --

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by miss-islington : -- nosy: +miss-islington nosy_count: 10.0 -> 11.0 pull_requests: +27448 pull_request: https://github.com/python/cpython/pull/29175 ___ Python tracker

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by Dennis Sweeney : -- pull_requests: +27319 pull_request: https://github.com/python/cpython/pull/29048 ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Dennis Sweeney added the comment: Oh yeah -- Py_EnterRecursiveCall/Py_LeaveRecursiveCall in abstract_get_bases would be simpler. Also, the set approach also probably still c-stack overflows on class C: def __getattr__(self, attr): class A: pass class B: pass

[issue30570] issubclass segfaults on objects with weird __getattr__

Carl Friedrich Bolz-Tereick added the comment: PyPy raises a RecursionError here, which sounds like an ok outcome. So simply checking for the recursion would also be a way of fixing this... -- nosy: +Carl.Friedrich.Bolz ___ Python tracker

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by Gregory P. Smith : -- keywords: +patch pull_requests: +27291 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29017 ___ Python tracker

[issue30570] issubclass segfaults on objects with weird __getattr__

Gregory P. Smith added the comment: Python metaprogramming allows type-like things to be bases, not just things that pass PyType_Check(). so being that strict isn't going to work. The other classic way to prevent this is to track what you're recursing on to avoid a loop. i.e. Keeping a

[issue30570] issubclass segfaults on objects with weird __getattr__

Change by Gregory P. Smith : -- assignee: -> gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30570] issubclass segfaults on objects with weird __getattr__

Gregory P. Smith added the comment: This is a stack overflow in Objects/abstract.c because we infinitely recurse within abstract_issubclass(). We should probably do some validity checking on the bases tuple that abstract_get_bases returns (ideally within abstract_get_bases?). The tuple

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Pablo Galindo Salgado added the comment: New changeset 4ce55a2353e07962280181df40af0135aef1cf51 by Pablo Galindo Salgado in branch '3.10': [3.10] bpo-45408: Don't override previous tokenizer errors in the second parser pass (GH-28812). (GH-28813)

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Change by Pablo Galindo Salgado : -- pull_requests: +27132 pull_request: https://github.com/python/cpython/pull/28813 ___ Python tracker ___

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Pablo Galindo Salgado added the comment: New changeset 0219017df7ec41839fd0d56a3076b5f09c58d313 by Pablo Galindo Salgado in branch 'main': bpo-45408: Don't override previous tokenizer errors in the second parser pass (GH-28812)

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +27131 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28812 ___ Python tracker

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Gregory P. Smith added the comment: Marking release blocker as a crash is bad for a function that is documented as safe for use on untrusted input so long as it isn't large enough to overflow the stack. https://docs.python.org/3/library/ast.html#ast.literal_eval -- priority: normal

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Łukasz Langa added the comment: Confirmed in 3.10 and 3.11: >>> ast.literal_eval(r'''\ ... \ ... (\ ... \ ''') fish: Job 1, 'python' terminated by signal SIGSEGV (Address boundary error) 3.9 raises SyntaxError: >>> ast.literal_eval(r''' ... \ ... (\ ... \ ''') Traceback (most recent call

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Gregory P. Smith added the comment: (unable to reproduce on 3.9) -- nosy: +gregory.p.smith versions: -Python 3.9 ___ Python tracker ___

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

Change by Gregory P. Smith : -- versions: +Python 3.10, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue45408] [fuzzer] Weird input with continuation and newlines causes null deref in parser

_start AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x18b08c) ==85015==ABORTING -- components: Parser messages: 403427 nosy: ammar2, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: [fuzzer] Weird i

[issue30570] issubclass segfaults on objects with weird __getattr__

Irit Katriel added the comment: Reproduced on 3.11. -- nosy: +iritkatriel versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker

[issue26871] Change weird behavior of PyModule_AddObject()

Petr Viktorin added the comment: Since https://github.com/python/cpython/pull/23122, there is PyModule_AddObjectRef doesn't steal a reference. PyModule_AddObject is discouraged in the docs, but not formally deprecated. (As Stefan notes, the leaks are single references in case of a module

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Erlend E. Aasland added the comment: > What about closing this as third party? (Tcl/Tk is a dependency but still > it's a third party right?) Sure. I'll leave that for Terry or any of the other IDLE devs. We can adjust the resolution after close if needed. > Also what's up with this

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Shreyan Avigyan added the comment: Also what's up with this open-pending issue? -- status: open -> pending ___ Python tracker ___

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Shreyan Avigyan added the comment: What about closing this as third party? (Tcl/Tk is a dependency but still it's a third party right?) -- status: pending -> open ___ Python tracker

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Change by Erlend E. Aasland : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Change by Erlend E. Aasland : -- status: pending -> open title: [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters -> [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters ___ Python tracker

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Erlend E. Aasland added the comment: > The smiley emoji  is U+1F600 which is outside of the Unicode Basic > Multilingual Plane (BMP). Correct, and this is documented: https://docs.python.org/3/library/idle.html#user-output-in-shell Suggesting to close this as not-a-bug. -- nosy:

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Shreyan Avigyan added the comment: It's not a Python problem at all. This was occurring in IDLE only. And yeah I know how it print the character. It's just that I was confused that why IDLE is behaving like that. I am happy to learn that it has a fix coming soon. --

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Steven D'Aprano added the comment: The smiley emoji  is U+1F600 which is outside of the Unicode Basic Multilingual Plane (BMP). IDLE's underlying graphical toolkit, Tcl/Tk, has problems with Unicode characters outside of the BMP, so this may not be fixable by us. If all you want is to

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Change by Shreyan Avigyan : -- versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

("")' in IDLE and I saw a weird behavior. Actually to be accurate, many weird behaviors! 1. If I type in 'print())' and I want to delete the extra ')' but it just stuck. I can't backspace or delete anything I've typed but I can type more. 2. If we move our cursor (typing cursor, not the

[issue43746] Weird typing annotation closure behavior

Guido van Rossum added the comment: Just Don't Do This. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker ___

[issue43746] Weird typing annotation closure behavior

conchylicultor added the comment: Yes, I know I can rename the closure, or wrap the annotation in 'quote'. I just wanted to point this out as it felt confusing to me. For instance, it feels inconsistent with: ``` def fn(datetime: datetime.Time): # Works as expected ``` Or: ``` @dataclass

[issue43746] Weird typing annotation closure behavior

Joël Larose added the comment: An easy workaround would be to alias your import or to import your class directly. ``` from ... import losses as l class A: losses: l.Losses = l.Losses() ``` or ``` from ...losses import Losses class A: losses: Losses = Losses() ``` -- nosy:

[issue43746] Weird typing annotation closure behavior

Karthikeyan Singaravelan added the comment: I guess this is similar to the explanation at https://bugs.python.org/issue36363#msg338389 > The problem in the original code is that the annotation references a global > name that is shadowed by a local (to the class body) name, and because of

[issue43746] Weird typing annotation closure behavior

conchylicultor added the comment: Sure, here is a minimal reproductible example demonstrating the issue: ``` import pathlib class C: pathlib: pathlib.Path = None ``` Which raises: ``` File "py", line 5, in C pathlib: pathlib.Path = None AttributeError: 'NoneType' object has

[issue43746] Weird typing annotation closure behavior

Eric V. Smith added the comment: Can you put together an example we can run? Either from a single file, or multiple modules in the current directory? The "..." import makes it complicated to reproduce. -- ___ Python tracker

[issue43746] Weird typing annotation closure behavior

Change by Eric V. Smith : -- Removed message: https://bugs.python.org/msg390548 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue43746] Weird typing annotation closure behavior

Eric V. Smith added the comment: Can you put together an example we can actually run? -- nosy: +eric.smith ___ Python tracker ___

[issue43746] Weird typing annotation closure behavior

conchylicultor added the comment: The above example is a real world example I have currently have. Basically I have some dataclass based configuration like: in losses.py: ``` class LossesParams: ... ``` in dataset.py: ``` class DatasetParams: ... ``` in config.py: ```

[issue43746] Weird typing annotation closure behavior

Larry Hastings added the comment: By "use case", I mean, what problem are you solving in a useful program by doing this? So far it seems like a pointless exercise in seeing what funny behavior you can try with annotations. -- ___ Python tracker

[issue43746] Weird typing annotation closure behavior

conchylicultor added the comment: > Do you have an actual use case for self-referential annotations? I'm not sure I understand the question. My use case is the following: ``` from ... import losses class A: losses: losses.Losses = losses.Losses() ``` Currently this is failing be cause

[issue43746] Weird typing annotation closure behavior

Larry Hastings added the comment: Do you have an actual use case for self-referential annotations? -- nosy: +larry ___ Python tracker ___

[issue43746] Weird typing annotation closure behavior

conchylicultor added the comment: Interestingly mypy, pylint correctly resolve the closure. ``` class A: dataclasses: dataclasses.Field = dataclasses.field() A.dataclasses.other # mypy error: "Field[Any]" has no attribute "other" ``` So the current workaround is to use quotes: ```

[issue43746] Weird typing annotation closure behavior

Change by conchylicultor : -- components: +Library (Lib) -Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43746] Weird typing annotation closure behavior

Change by conchylicultor : -- components: +Interpreter Core type: -> behavior versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker ___

[issue43746] Weird typing annotation closure behavior

no attribute 'Losses' losses: losses.Losses = losses.Losses() ``` -- messages: 390304 nosy: conchylicultor priority: normal severity: normal status: open title: Weird typing annotation closure behavior ___ Python tracker <https://bugs.python.

[issue43586] sys.path is weird in Windows 10.

Shin Ryu added the comment: Thank you. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue43586] sys.path is weird in Windows 10.

Eryk Sun added the comment: > on windows, they print sys.path[0] is python38.zip not "". Isolated mode is probably enabled, i.e. `sys.flags.isolated == 1`. It's enabled by default for the embedded distribution [1], or if a "._pth" file exists beside and with the same base name as the

[issue43586] sys.path is weird in Windows 10.

cript directory is inserted before the entries inserted as a result of PYTHONPATH.") -- components: Windows messages: 389275 nosy: RyuSh1n, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: sys.path is weird in Windows 10. type: behavior

[issue42842] import logging.handlers shows weird behavior

: module 'logging' has no attribute 'handlers' -- messages: 384509 nosy: sasquatchplatypus priority: normal severity: normal status: open title: import logging.handlers shows weird behavior type: behavior versions: Python 3.9 ___ Python tracker <ht

[issue42334] Subclassing int and complex with keyword arguments weird

Terry J. Reedy added the comment: When reporting a failure please copy and paste the exception and message and when non-trivial, the traceback. In this case: "TypeError: 'test' is an invalid keyword argument for complex()". The difference between int and complex versus float is that the

[issue42334] Subclassing int and complex with keyword arguments weird

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42334] Subclassing int and complex with keyword arguments weird

Dennis Sweeney added the comment: Here's an example: class A(complex): def __init__(self, *args, test): self.test = test def __new__(cls, *args, test): return super().__new__(cls, *args) >>> a = A(1, test="TEST") >>> a (1+0j) >>> a.test 'TEST' >>> b = A(1, 1,

[issue42334] Subclassing int and complex with keyword arguments weird

Dennis Sweeney added the comment: This is because int, str, and complex are immutable. If I have class MyInt(int): def __init__(self, stuff): pass then when I call MyInt("19"), the string "19" is passed to the constructor int.__new__ before the overridden

[issue42334] Subclassing int and complex with keyword arguments weird

autospamfighter added the comment: I tried some more classes and str is weird, but dict and set work fine. very weird -- ___ Python tracker <https://bugs.python.org/issue42

  1   2   3   4   5   6   7   8   9   10   >