[issue42334] Subclassing int and complex with keyword arguments weird

: normal status: open title: Subclassing int and complex with keyword arguments weird versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42334> ___ ___ Pytho

Re: Weird behavior for IDLE...

On 10/13/2020 4:51 AM, Steve wrote: Why does IDLE always open with the lowest three lines of the window end up hidden below the bottom of the screen behind the task bar? Every time I use it, I have to stop and grab the top of the window and drag it up to see the line and row information. I

Weird behavior for IDLE...

Why does IDLE always open with the lowest three lines of the window end up hidden below the bottom of the screen behind the task bar? Every time I use it, I have to stop and grab the top of the window and drag it up to see the line and row information. I explored the Options/Configure IDLE but

[issue41920] Weird add operation of "0.2222 + 0.1111"

Leonard Schwennesen added the comment: Hi Steven, Thanks for your detailed explanations. They where very helpful for me. Now I know a bit more about Python and Computers in general. (; -- ___ Python tracker

[issue41920] Weird add operation of "0.2222 + 0.1111"

Steven D'Aprano added the comment: Hi Leonard, Any number which has only fixed precision will experience similar issues. It might affect different calculations. In Python, float, complex and Decimal have fixed precision, so they can experience this issue. But for simple calculations,

[issue41920] Weird add operation of "0.2222 + 0.1111"

Leonard Schwennesen added the comment: But this "bug" only affects floating numbers? -- ___ Python tracker ___ ___

[issue41920] Weird add operation of "0.2222 + 0.1111"

Leonard Schwennesen added the comment: Ok thank you for these resources. I didn't know that before. (; -- ___ Python tracker ___

[issue41920] Weird add operation of "0.2222 + 0.1111"

Steven D'Aprano added the comment: Some further resources: https://stackoverflow.com/questions/8215437/floating-point-accuracy-in-python https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate

[issue41920] Weird add operation of "0.2222 + 0.1111"

Steven D'Aprano added the comment: Please forgive me if my answer is a little bit brusque, but we get essentially this same bug report regularly, only the numbers are different. This is not a bug in Python, it is an unavoidable consequence of how floating point arithmetic works in every

[issue41920] Weird add operation of "0.2222 + 0.1111"

Leonard Schwennesen added the comment: Same problem with 0.-0. python returns 0.22218 and not 0. -- ___ Python tracker ___

[issue41920] Weird add operation of "0.2222 + 0.1111"

GCC 10.2.0] on linux I also tested that in a newly setup VM, same issue -- messages: 377871 nosy: ungedummt priority: normal severity: normal status: open title: Weird add operation of "0. + 0." type: behavior versions: Python 3.8 _

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by hai shi : -- nosy: +shihai1991 nosy_count: 5.0 -> 6.0 pull_requests: +20327 pull_request: https://github.com/python/cpython/pull/21169 ___ Python tracker ___

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Raymond Hettinger added the comment: Thanks for the report. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Raymond Hettinger added the comment: New changeset 5c01ed6f9366bc6fd880c18e5a2929de72bc1be6 by Miss Islington (bot) in branch '3.9': bpo-40725: Restore missing column of digits (GH-20313) (GH-20315) https://github.com/python/cpython/commit/5c01ed6f9366bc6fd880c18e5a2929de72bc1be6

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +19584 pull_request: https://github.com/python/cpython/pull/20315 ___ Python tracker

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +19582 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20313 ___ Python tracker

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by Rahul Kumaresan : -- nosy: +rahul-kumi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

Change by Karthikeyan Singaravelan : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40725] Documentation: Benchmark table in "What's new in Python 3.9" has weird values

ty: normal status: open title: Documentation: Benchmark table in "What's new in Python 3.9" has weird values versions: Python 3.9 ___ Python tracker <https://bug

[issue39918] random.Random(False) weird error

STINNER Victor added the comment: Fixed by: New changeset 00d7cd8ab8db2c1e1f591ade828f88a1a973d70f by Victor Stinner in branch 'master': bpo-38075: Fix random_seed(): use PyObject_CallOneArg() (GH-18897) https://github.com/python/cpython/commit/00d7cd8ab8db2c1e1f591ade828f88a1a973d70f

[issue39918] random.Random(False) weird error

STINNER Victor added the comment: > Should that 0 in the PyObject_Vectorcall be a 1 instead? Right. I proposed PR 18897 to fix it and add an unit test on seed(False). -- ___ Python tracker

[issue39918] random.Random(False) weird error

Mark Dickinson added the comment: The lines here look odd to me: https://github.com/python/cpython/blob/363fab83b8a0e6d924c7a7c577feec6a2812bb8c/Modules/_randommodule.c#L290-L291 args[0] = arg; n = PyObject_Vectorcall(_randomstate_global->Long___abs__, args, 0,

[issue39918] random.Random(False) weird error

Change by STINNER Victor : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39918] random.Random(False) weird error

Miro Hrončok added the comment: Possibly related to https://bugs.python.org/issue32554 https://github.com/python/cpython/pull/15382 Deprecate hashing arbitrary types in random.seed() -- nosy: +hroncok, vstinner ___ Python tracker

[issue39918] random.Random(False) weird error

uld you arrange for a better message? -- components: Library (Lib) messages: 363766 nosy: loganjerry priority: normal severity: normal status: open title: random.Random(False) weird error type: behavior versions: Python 3.9

[issue39474] col_offset for parenthesized expressions looks weird

Guido van Rossum added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39474] col_offset for parenthesized expressions looks weird

miss-islington added the comment: New changeset 2076d4f97ef514bb4dc4ca768fbaa3f538ce7f1f by Miss Islington (bot) in branch '3.8': bpo-39474: Fix AST pos for expressions like (a)(b), (a)[b] and (a).b. (GH-18477) https://github.com/python/cpython/commit/2076d4f97ef514bb4dc4ca768fbaa3f538ce7f1f

[issue39474] col_offset for parenthesized expressions looks weird

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

[issue39474] col_offset for parenthesized expressions looks weird

Serhiy Storchaka added the comment: New changeset 6e619c48b8e804ece9521453fc8da0640a04d5b1 by Serhiy Storchaka in branch 'master': bpo-39474: Fix AST pos for expressions like (a)(b), (a)[b] and (a).b. (GH-18477)

[issue39474] col_offset for parenthesized expressions looks weird

Batuhan Taskaya added the comment: > Are you going to work on a patch then, Batuhan? Serhiy already submitted a PR, which looks great. -- ___ Python tracker ___

[issue39474] col_offset for parenthesized expressions looks weird

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +17847 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18477 ___ Python tracker

[issue39474] col_offset for parenthesized expressions looks weird

Change by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39474] col_offset for parenthesized expressions looks weird

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39474] col_offset for parenthesized expressions looks weird

Lysandros Nikolaou added the comment: Are you going to work on a patch then, Batuhan? -- ___ Python tracker ___ ___

[issue39474] col_offset for parenthesized expressions looks weird

Guido van Rossum added the comment: This is also a 3.8 issue. We discovered this with pegen, and would love to see it fixed. -- nosy: +gvanrossum versions: +Python 3.8 ___ Python tracker

[issue39474] col_offset for parenthesized expressions looks weird

Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39474] col_offset for parenthesized expressions looks weird

Change by Batuhan : -- title: col_offset for parenthesized expressions looks weird on attribute access -> col_offset for parenthesized expressions looks weird type: -> behavior ___ Python tracker <https://bugs.python.org/i

[issue39474] col_offset for parenthesized expressions looks weird on attribute access

arens if it is any if approved. -- components: Interpreter Core messages: 360844 nosy: BTaskaya, benjamin.peterson, pablogsal priority: normal severity: normal status: open title: col_offset for parenthesized expressions looks weird on attribute access versions

[issue38808] weird bug while using a for loop and array

Zach kuunka added the comment: I will check that out, Thank you -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38808] weird bug while using a for loop and array

Mark Dickinson added the comment: This isn't a bug: it's the way that Python's assignment model works. This is explained in various places (including the official Python documentation), but you may find this excellent presentation by Ned Batchelder useful:

[issue38808] weird bug while using a for loop and array

Zach kuunka added the comment: I found out it just happens when you set an array to an array they behave as the same thing, which if its not a bug it sure is counter-intuitive. if you do x = 1 then y = x then add one to y you have y = 2 and x = 1 if you do it for an array arr1 = [1] then

[issue38808] weird bug while using a for loop and array

be anything print(Arr2) Also i'm interested to know why this happens, Thank You -- components: Library (Lib) files: brokentest.py messages: 356648 nosy: Zach kuunka priority: normal severity: normal status: open title: weird bug while using a for loop and array type: behavior versions

[issue27994] In the argparse help(argparse) prints weird comments instead of good docstrings

Change by Raymond Hettinger : -- nosy: +rhettinger resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue27994] In the argparse help(argparse) prints weird comments instead of good docstrings

Change by Lewis Gaul : -- nosy: +aeros ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27994] In the argparse help(argparse) prints weird comments instead of good docstrings

Lewis Gaul added the comment: This doesn't seem to be the case [anymore] to me, should this be closed? -- nosy: +Lewis Gaul ___ Python tracker ___

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

miss-islington added the comment: New changeset 80cb055aa45f37951b8e3097fe4367d443d455ae by Miss Islington (bot) in branch '3.7': bpo-38185: Fixed case-insensitive string comparison in sqlite3.Row indexing. (GH-16190)

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

miss-islington added the comment: New changeset d8d653c2d0d267eb1e44f6cdb916945029fec3b1 by Miss Islington (bot) in branch '3.8': bpo-38185: Fixed case-insensitive string comparison in sqlite3.Row indexing. (GH-16190)

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

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

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

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

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

Serhiy Storchaka added the comment: New changeset f669581a9527afb0d2325f9845a86715c0ba365d by Serhiy Storchaka in branch 'master': bpo-38185: Fixed case-insensitive string comparison in sqlite3.Row indexing. (GH-16190)

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +15796 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16190 ___ Python tracker

[issue38185] Weird way of case-insensitive indexing of sqlite3.Row

letters, but has weird behavior for digits, '_' and non-ASCII characters. For example: >>> import sqlite3 >>> con = sqlite3.connect(":memory:") >>> con.row_factory = sqlite3.Row >>> row = con.execute("select 1 as a_1").fetchone() >&

Re: Weird Python Bug

On 2019-09-13 20:17, CrazyVideoGamez wrote: For some reason, if you put in the code def odd_ones_out(numbers): for num in numbers: count = numbers.count(num) if not count % 2 == 0: for i in range(count): numbers.remove(num) return

RE: Weird Python Bug

2, 67, 67] >>> odd_ones_out(nums) [4, 67, 67] >>> nums [4, 67, 67] >>> -Original Message- From: Python-list On Behalf Of CrazyVideoGamez Sent: Friday, September 13, 2019 3:18 PM To: python-list@python.org Subject: Weird Python Bug For some reason, if you put i

Weird Python Bug

For some reason, if you put in the code def odd_ones_out(numbers): for num in numbers: count = numbers.count(num) if not count % 2 == 0: for i in range(count): numbers.remove(num) return numbers nums = [72, 4, 82, 67, 67]

[issue37208] Weird exception behaviour in ProcessPoolExecutor

Change by Brian Quinlan : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37208] Weird exception behaviour in ProcessPoolExecutor

Change by F. Raab : -- nosy: +raabf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37208] Weird exception behaviour in ProcessPoolExecutor

Change by Brian Quinlan : -- resolution: -> duplicate superseder: -> picke cannot dump Exception subclasses with different super() args ___ Python tracker ___

[issue37208] Weird exception behaviour in ProcessPoolExecutor

Brian Quinlan added the comment: That's a super interesting bug! It looks like this issue is that your exception can't be round-tripped using pickle i.e. >>> class PoolBreaker(Exception): ... def __init__(self, num): ... super().__init__() ... self.num = num ... >>>

[issue37208] Weird exception behaviour in ProcessPoolExecutor

Change by Karthikeyan Singaravelan : -- nosy: +bquinlan, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37208] Weird exception behaviour in ProcessPoolExecutor

New submission from Iceflower : I don't really know where this belongs, but it is at least for me not an expected behaviour. It is weird for me at all. Please take a look if this is an intended behaviour and why it is like that. Tested with py3.7.3, py3.8.0b1 ``` A process in the process

[issue35175] Builtin function all() is handling dict() types in a weird way.

Change by Josh Rosenberg : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue35175] Builtin function all() is handling dict() types in a weird way.

Karthikeyan Singaravelan added the comment: Dictionary iterates over keys and this is expected behavior. If you need to iterate by values you should use dict().values() $ python3 -c 'for i in dict(a=1): print(i)' a $ python3 -c 'print(all(dict(a=False)))' # Iterate by keys and thus 'a' is

[issue35175] Builtin function all() is handling dict() types in a weird way.

() types in a weird way. type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47912/all-dict-example.py ___ Python tracker <https://bugs.python.org/issue35

Re: Help Needed : script weird result.

On Sunday, September 2, 2018 at 1:12:17 AM UTC+8, moh...@gmail.com wrote: > All, > > I m trying to run this small script to find the lowest of the given array of > numbers. The script works fine for various combination of inputs but fails in > a weird way for a particular set

Re: Help Needed : script weird result.

On Sat, 1 Sep 2018 10:11:59 -0700 (PDT), moha...@gmail.com wrote: > All, > > I m trying to run this small script to find the lowest of the given > array of numbers. The script works fine for various combination of > inputs but fails in a weird way for a particular set of inputs, can

Re: Help Needed : script weird result.

On 9/1/18 1:11 PM, moha...@gmail.com wrote: All, I m trying to run this small script to find the lowest of the given array of numbers. The script works fine for various combination of inputs but fails in a weird way for a particular set of inputs, can anyone point the mistake in the script

Re: Help Needed : script weird result.

On Sat, Sep 1, 2018 at 1:26 PM duncan smith wrote: > > On 01/09/18 18:11, moha...@gmail.com wrote: > > All, > > > > I m trying to run this small script to find the lowest of the given array > > of numbers. The script works fine for various combination of inputs

Re: Help Needed : script weird result.

On 01/09/18 18:11, moha...@gmail.com wrote: > All, > > I m trying to run this small script to find the lowest of the given array of > numbers. The script works fine for various combination of inputs but fails in > a weird way for a particular set of inputs, can anyone po

Help Needed : script weird result.

All, I m trying to run this small script to find the lowest of the given array of numbers. The script works fine for various combination of inputs but fails in a weird way for a particular set of inputs, can anyone point the mistake in the script and the behavior. Script x = input ("

[issue33993] zipfile module weird behavior when used with zipinfo

Serhiy Storchaka added the comment: Use: rel_name = "tmp/test.md" -- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue33993] zipfile module weird behavior when used with zipinfo

New submission from Micheal Gardner : when i want to zip a empty folder, i use following code ``` import zipfile zfile = zipfile.ZipFile("tmp.zip",'w') zif = zipfile.ZipInfo("tmp/") zfile.writestr(zif,"") zfile.close() ``` but in this case, things become weir

[issue33993] zipfile module weird behavior when used with zipinfo

Change by Micheal Gardner : -- components: Library (Lib) nosy: Micheal Gardner priority: normal severity: normal status: open title: zipfile module weird behavior when used with zipinfo type: behavior versions: Python 2.7, Python 3.6 ___ Python

Re: Weird side effect of default parameter

Steven D'Aprano wrote: > Python function default values use *early binding*: the default parameter > is evaluated, ONCE, when the function is defined, and that value is used > each time it is needed. Thanks, "early binding" was the clue I was missing. robert --

Re: Weird side effect of default parameter

On Thu, 03 May 2018 19:47:37 +, Robert Latest via Python-list wrote: > Hello, > > I don't understand the behavior of the code below. Why does the dict > property "a" of both objects contain the same keys? This is only if > "a=dict" is in the initializer. If I put self.a = dict() into the

Re: Weird side effect of default parameter

This is a well known feature of Python.   It's a very common "gotcha" to new Python programmers. Google "Mutable default parameters in Python" for long list of explanations and fixes. In short, don't use a mutable object as a default parameter. Gary Herron On 05/03/2018 12:47 PM,

Weird side effect of default parameter

Hello, I don't understand the behavior of the code below. Why does the dict property "a" of both objects contain the same keys? This is only if "a=dict" is in the initializer. If I put self.a = dict() into the init function, I get two separate dicts class Foo(object): def __init__(self, x,

[issue32688] weird comment out line of code

Brett Cannon added the comment: Thanks! On Sun, Jan 28, 2018, 19:32 Xiang Zhang, wrote: > > Xiang Zhang added the comment: > > Done. > > -- > versions: -Python 3.6 > > ___ > Python

[issue32688] weird comment out line of code

Xiang Zhang added the comment: Done. -- versions: -Python 3.6 ___ Python tracker ___ ___

[issue32688] weird comment out line of code

Xiang Zhang added the comment: New changeset 997478eb797b31bd724135ca17781d1cf4b89cfa by Xiang Zhang in branch 'master': bpo-32688: Make why the line is commented out clear (GH-5405) https://github.com/python/cpython/commit/997478eb797b31bd724135ca17781d1cf4b89cfa

[issue32688] weird comment out line of code

Change by Xiang Zhang : -- pull_requests: +5238 ___ Python tracker ___ ___

[issue32688] weird comment out line of code

Brett Cannon added the comment: We should probably delete the line regardless so no one else gets thrown by this (or at least leave a comment). -- ___ Python tracker

[issue32688] weird comment out line of code

Xiang Zhang added the comment: Ahh, I figure out that the line is useless and can't affect any logic then. So the analyzer is right! Sorry for the bother Brett. -- resolution: -> not a bug stage: -> resolved status: open -> closed

[issue32688] weird comment out line of code

Brett Cannon added the comment: I don't remember why that line was commented out to make the analyzer happy. -- ___ Python tracker

[issue32688] weird comment out line of code

Xiang Zhang added the comment: Sorry, forget links, it's https://github.com/python/cpython/blob/master/Python/ceval.c#L3528 , and the commit is b94767ff44edf5d461d7cb1c8eb5160f83886358. -- ___ Python tracker

[issue32688] weird comment out line of code

6 nosy: brett.cannon, xiang.zhang priority: normal severity: normal status: open title: weird comment out line of code versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31952] Weird behavior on tupple item assignment

Emanuel Barry added the comment: This is a known issue, and is properly explained here: https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works -- nosy: +ebarry resolution: -> not a bug stage: -> resolved

[issue31952] Weird behavior on tupple item assignment

Change by Lucas Bertoldo : -- versions: +Python 2.7, Python 3.5 ___ Python tracker ___

[issue31952] Weird behavior on tupple item assignment

omponents: Interpreter Core files: python bug.png messages: 305613 nosy: Lucas Bertoldo priority: normal severity: normal status: open title: Weird behavior on tupple item assignment type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47252/python bug.png __

[issue29432] wait_for(gather(...)) logs weird error message

Chris Jerdonek added the comment: By the way, I see this exact issue was also raised and discussed here, with a couple responses by Guido, too: https://github.com/python/asyncio/issues/253 -- ___ Python tracker

[issue29432] wait_for(gather(...)) logs weird error message

Chris Jerdonek added the comment: I noticed that the future defined by asyncio.gather(sleep) is in a "pending" state immediately after the asyncio.TimeoutError. One workaround is to wait for the cancellation to finish: @asyncio.coroutine def main(): sleep = asyncio.sleep(0.2)

[issue30570] issubclass segfaults on objects with weird __getattr__

Changes by Jim Fasarakis-Hilliard : -- nosy: +Jim Fasarakis-Hilliard ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Serhiy Storchaka added the comment: This looks as yet one example of issues similar of issue14010. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue30570] issubclass segfaults on objects with weird __getattr__

R. David Murray added the comment: Yes, but we try to make it not possible to segfault the interpreter with pure python code that isn't intentionally mucking with C-level stuff, so this is a bug we would like to fix. -- nosy: +r.david.murray ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Louie Lu added the comment: Without this segfault, I think you do a wrong operation. In other cases, for example: >>> issubclass(10, int) Traceback (most recent call last): File "", line 1, in TypeError: issubclass() arg 1 must be a class `issubclass` will return TypeError on instance, if

[issue30570] issubclass segfaults on objects with weird __getattr__

Louie Lu added the comment: I can reproduce this bugs on 3.7, Linux. Python 3.7.0a0 (heads/master:d3bedf356a, Jun 5 2017, 10:21:52) [GCC 6.3.1 20170306] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def __getattr__(self, attr): ...

[issue30570] issubclass segfaults on objects with weird __getattr__

Changes by Bruno Oliveira : -- nosy: +Bruno Oliveira ___ Python tracker ___ ___

[issue30570] issubclass segfaults on objects with weird __getattr__

Daniel Lepage added the comment: I tried it on python 2.7.12 and python 2.6.9 since I had them lying around and got the same behavior. -- ___ Python tracker

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