[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset b962544594c6a7c695330dd20fedffb3a1916ba6 by Miss Islington (bot) in branch '3.10': bpo-34602: Fix unportable test(1) operator in configure script (GH-30490) (GH-30491)

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by Thomas Klausner : -- nosy: +wiz nosy_count: 8.0 -> 9.0 pull_requests: +28694 pull_request: https://github.com/python/cpython/pull/30490 ___ Python tracker ___

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: > @ned.deily, @lukasz.langa: reopen this issue or open a new one? Since there are so many iterations on this issue already, I think a new issue would be better. -- ___ Python tracker

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ronald Oussoren added the comment: > My understanding of the resolution of this ticket is that it is still not > possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. > Is that correct? Yes, the code in msg324731 still fails. We're still using the mechanism described

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Jean-Paul Calderone added the comment: My understanding of the resolution of this ticket is that it is still not possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. Is that correct? In that case, the original bug report still seems valid and unresolved (and indeed,

[issue42538] AsyncIO strange behaviour

Joannah Nanjekye added the comment: I meant, "that describes the behaviour" -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue42538] AsyncIO strange behaviour

Joannah Nanjekye added the comment: I opened a documentation PR agreeing with @ncoghlan, that adds this behavior. See https://bugs.python.org/issue44665 -- nosy: +nanjekyejoannah ___ Python tracker

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Łukasz Langa added the comment: New changeset 2563dd2d0a1cf793afca328ae9e195b72bd2b391 by Łukasz Langa in branch '3.10': [3.10] bpo-34602: Quadruple stack size on macOS when compiling with UBSAN (GH-27309) (GH-28280)

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Łukasz Langa added the comment: New changeset be9de8721d63b9d8e032d508069daf88c06542c6 by Łukasz Langa in branch 'main': bpo-34602: Quadruple stack size on macOS when compiling with UBSAN (GH-27309) https://github.com/python/cpython/commit/be9de8721d63b9d8e032d508069daf88c06542c6 --

[issue42538] AsyncIO strange behaviour

Change by Nick Coghlan : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> asyncio.create_task() documentation should mention user needs to keep reference to the task ___ Python tracker

[issue42538] AsyncIO strange behaviour

Nick Coghlan added the comment: While filed later, issue44665 correctly describes the problem reported here: asyncio is behaving as expected, but the docs don't make it clear that you need to save a reference to the result of ensure_future()/create_task() if you don't want to risk the task

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by Chih-Hsuan Yen : -- nosy: -yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

Re: list() strange behaviour

Il 20/12/2020 21:00, danilob ha scritto: Hi, I'm an absolute beginner in Python (and in English too ;-) Running this code: -- # Python 3.9.0 a = [[1, 2, 0, 3, 0], [0, 4, 5, 0, 6], [7, 0, 8, 0, 9], [2, 3, 0, 0, 1], [0, 0, 1, 8, 0]] b = ((x[0] for x in a))

Re: list() strange behaviour

until you stop asking. > > This is just a thought, not a request for such a feature. > > -Original Message- > From: Python-list On > Behalf Of ast > Sent: Saturday, January 23, 2021 2:54 AM > To: python-list@python.org > Subject: Re: list() strang

Re: list() strange behaviour

On Sun, Jan 24, 2021 at 8:49 AM Cameron Simpson wrote: > > On 23Jan2021 12:20, Avi Gross wrote: > >I am wondering how hard it would be to let some generators be resettable? > > > >I mean if you have a generator with initial conditions that change as it > >progresses, could it cache away those

Re: list() strange behaviour

On 23Jan2021 12:20, Avi Gross wrote: >I am wondering how hard it would be to let some generators be resettable? > >I mean if you have a generator with initial conditions that change as it >progresses, could it cache away those initial conditions and upon some >signal, simply reset them? Objects

RE: list() strange behaviour

Of ast Sent: Saturday, January 23, 2021 2:54 AM To: python-list@python.org Subject: Re: list() strange behaviour Le 20/12/2020 à 21:00, danilob a écrit : > > > b = ((x[0] for x in a)) > There is a useless pair of parenthesis b = (x[0] for x in a) b is a GENERATOR expression

Re: list() strange behaviour

On 1/23/2021 2:54 AM, Unknown wrote: Le 20/12/2020 à 21:00, danilob a écrit : b = ((x[0] for x in a)) There is a useless pair of parenthesis b = (x[0] for x in a) b is a GENERATOR expression first list(b) calls next method on b repetedly until b is empty. So it provides the "content"

Re: list() strange behaviour

Le 20/12/2020 à 21:00, danilob a écrit : b = ((x[0] for x in a)) There is a useless pair of parenthesis b = (x[0] for x in a) b is a GENERATOR expression first list(b) calls next method on b repetedly until b is empty. So it provides the "content" of b second list(b) provides nothing

Re: list() strange behaviour

On 21Dec2020 08:09, Cameron Simpson wrote: >>b = ((x[0] for x in a)) > >This is a generator comprehension, and _not_ a list. I should amend this: a "generator _expression_", not comprehension. A "generator comprehension" is not a thing. Apologies, Cameron Simpson --

Re: list() strange behaviour

On 20Dec2020 21:00, danilob wrote: >I'm an absolute beginner in Python (and in English too ;-) Well your English is far better than my very poor second language. >Running this code: >-- ># Python 3.9.0 > >a = [[1, 2, 0, 3, 0], > [0, 4, 5, 0, 6], > [7, 0, 8, 0, 9], > [2,

Re: list() strange behaviour

On 2020-12-20 21:00, danilob wrote: > b = ((x[0] for x in a)) here you create a generator > print(list(b)) > [1, 0, 7, 2, 0] and then you consume all the things it generates here which means that when you go to do this a second time > print(list(b)) the generator is already empty/exhausted so

list() strange behaviour

Hi, I'm an absolute beginner in Python (and in English too ;-) Running this code: -- # Python 3.9.0 a = [[1, 2, 0, 3, 0], [0, 4, 5, 0, 6], [7, 0, 8, 0, 9], [2, 3, 0, 0, 1], [0, 0, 1, 8, 0]] b = ((x[0] for x in a)) print(list(b)) print(list(b)) ---

[issue42538] AsyncIO strange behaviour

Alexander Greckov added the comment: Thanks! That's resolved my problem, but this thing wasn't really obvious as for me. Probably it would be better to write about this explicitly in docs for the create_task. All in all this issue can be closed. --

[issue42538] AsyncIO strange behaviour

Andrew Svetlov added the comment: I understand the issue as the following: 1. You don't save the result of `asyncio.create_task()` somewhere. The task object is dereferenced and thus you see a warning. 2. With PYTHONASYNCIODEBUG on the task is referenced also by internal debug structure,

[issue42538] AsyncIO strange behaviour

New submission from Alexander Greckov : Hi! I've met strange behaviour related to the coroutine execution. Probably it's somehow related to the asyncio.Queue get() method. I have the following lines of code: class WeightSource: def __init__(self): self._queue = asyncio.Queue

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Change by Raymond Hettinger : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Change by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Raymond Hettinger added the comment: See also: https://bugs.python.org/msg131551 -- ___ Python tracker ___ ___ Python-bugs-list

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Raymond Hettinger added the comment: There may still be some holes still remaining in OrderedDict but it doesn't seem to have been relevant in practice and will become even less so now that regular dicts are ordered and compact. If an issue does are arise with someone setting OrderedDict

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset dcc0eb379613f279864af61023ea44c94aa0535c by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) https://github.com/python/cpython/commit/dcc0eb379613f279864af61023ea44c94aa0535c

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by Ned Deily : -- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset 782854f90ad5f73f787f68693d535f2b05514e13 by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) (GH-14549)

[issue34602] python3 resource.setrlimit strange behaviour under macOS

miss-islington added the comment: New changeset bf82cd3124df94935c6e3190c7c40b76918d2174 by Miss Islington (bot) in branch '3.7': bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) https://github.com/python/cpython/commit/bf82cd3124df94935c6e3190c7c40b76918d2174

[issue34602] python3 resource.setrlimit strange behaviour under macOS

miss-islington added the comment: New changeset bd92b94da93198c8385c06ca908407f172c7e8b2 by Miss Islington (bot) in branch '3.8': bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) https://github.com/python/cpython/commit/bd92b94da93198c8385c06ca908407f172c7e8b2

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset 5bbbc733e6cc0804f19b071944af8d4719e26ae6 by Ned Deily in branch 'master': bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546) https://github.com/python/cpython/commit/5bbbc733e6cc0804f19b071944af8d4719e26ae6 --

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by Ned Deily : -- pull_requests: +14359 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14546 ___ Python tracker ___

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: > So we should keep an eye open for reports of segfaults running tests as > originally reported in Issue18075. Now there are such reports for 3.7.4rc1, at least. Release builds seem to be OK but at least four tests now fail on macOS 10.14.5 when built

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: Thanks for the analyses everyone! Also see the discussion in duplicate Issue36432. I was never able to reproduce the failure on earlier versions of macOS but then it seemed to become a hard failure with the release of 10.14.4. I haven't gone back and tried

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset fbe2a1394bf52f5a4455681e1b1f705a31559585 by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-34602: Avoid failures setting macOS stack resource limit (GH-13011) (GH-13014)

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by miss-islington : -- pull_requests: +12936 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34602] python3 resource.setrlimit strange behaviour under macOS

miss-islington added the comment: New changeset 52a5b71063af68c42b048095c4e555e93257f151 by Miss Islington (bot) in branch '3.7': bpo-34602: Avoid failures setting macOS stack resource limit (GH-13011) https://github.com/python/cpython/commit/52a5b71063af68c42b048095c4e555e93257f151

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by miss-islington : -- pull_requests: +12934 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ned Deily added the comment: New changeset 883dfc668f9730b00928730035b5dbd24b9da2a0 by Ned Deily in branch 'master': bpo-34602: Avoid failures setting macOS stack resource limit (GH-13011) https://github.com/python/cpython/commit/883dfc668f9730b00928730035b5dbd24b9da2a0 --

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Change by Ned Deily : -- keywords: +patch pull_requests: +12932 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Chih-Hsuan Yen added the comment: I guess Inada Naoki was to say https://bugs.python.org/issue36432 in the last comment. -- nosy: +yan12125 ___ Python tracker ___

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Inada Naoki added the comment: https://bugs.python.org/issue34602 may be relating to this. -- nosy: +inada.naoki ___ Python tracker ___

[issue34602] python3 resource.setrlimit strange behaviour under macOS

marche147 added the comment: Thanks for the repro! It did help for pinpointing the issue. So I took a little spare time and dived into xnu kernel code, here is my assumption based on what I found (N.B. : My assumption comes from a simple experiment and a brief skim of the source code within

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Vladimir Matveev added the comment: I can repro it with a given sample file ``` vladima-mbp $ cat test.c #include #include #include #include #include int main() { struct rlimit rl; if(getrlimit(RLIMIT_STACK, ) < 0) { perror("getrlimit"); exit(1); } rl.rlim_cur =

[issue34602] python3 resource.setrlimit strange behaviour under macOS

Ronald Oussoren added the comment: I get the same error, also with python3.7. Both for homebrew and a python.org installer. -- components: +macOS nosy: +ned.deily, ronaldoussoren versions: +Python 3.7 ___ Python tracker

[issue34602] python3 resource.setrlimit strange behaviour under macOS

un the above-mentioned python script on linux, also it does not generate exceptions both on python2 (2.7.10) & python3 (3.6.5). -- components: Library (Lib) messages: 324731 nosy: marche147 priority: normal severity: normal status: open title: python3 resource.setrlimit strange behav

Re: strange behaviour when writing a large amount of data on stdout

On Thursday, November 24, 2005 at 8:06:34 PM UTC+5:30, bon...@gmail.com wrote: > Bengt Richter wrote: > > Depends on what you run ;-) Maybe how many times buggy apps die in unusual > > ways. > > Or worse, buggy drivers. Your car might have bad 4-wheel drive that you > > never used, > > so you

Re: Strange behaviour with numbers in exponential notation

Am 04.09.16 um 10:29 schrieb Nobody: On Fri, 02 Sep 2016 18:18:08 +0200, Christian Gollwitzer wrote: 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is a 64bit IEEE number. The largest exact integer there is 2**53 (~10^16), everything beyond cannot be

Re: Strange behaviour with numbers in exponential notation

On Fri, 02 Sep 2016 18:18:08 +0200, Christian Gollwitzer wrote: > 1e26 denotes a *floating point number* Floating point has finite > precision, in CPython it is a 64bit IEEE number. The largest exact > integer there is 2**53 (~10^16), everything beyond cannot be accurately > represented. Uh,

Re: Strange behaviour with numbers in exponential notation

Am 03.09.16 um 02:31 schrieb Marco Sulla: On 2 September 2016 at 21:12, Christian Gollwitzer wrote: Am 02.09.16 um 19:24 schrieb Marco Sulla: Because Python has no long double type? Python no of course, but C++ yes, and CPython is written in C++. However, I think the answer

Re: Strange behaviour with numbers in exponential notation

On 3 September 2016 at 02:31, Marco Sulla wrote: > Python no of course, but C++ yes, and CPython is written in C++. Sorry, I just founded CppPython... -- https://mail.python.org/mailman/listinfo/python-list

Re: Strange behaviour with numbers in exponential notation

On 2 September 2016 at 21:12, Christian Gollwitzer wrote: > Am 02.09.16 um 19:24 schrieb Marco Sulla: > Because Python has no long double type? Python no of course, but C++ yes, and CPython is written in C++. However, I think the answer is here:

Re: Strange behaviour with numbers in exponential notation

On 2016-09-02 20:47, Random832 wrote: On Fri, Sep 2, 2016, at 15:12, Christian Gollwitzer wrote: Tradition? All languages I know of treat a number with an exponent as floating point. Scheme does allow you to give integers (and rationals) in decimal and/or exponential notation with the "#e"

Re: Strange behaviour with numbers in exponential notation

On Fri, Sep 2, 2016, at 15:12, Christian Gollwitzer wrote: > Tradition? All languages I know of treat a number with an exponent as > floating point. Scheme does allow you to give integers (and rationals) in decimal and/or exponential notation with the "#e" prefix. --

Re: Strange behaviour with numbers in exponential notation

Christian Gollwitzer : > Am 02.09.16 um 19:24 schrieb Marco Sulla: >> float has an 'exponentfloat' syntax. Why integers does not have an >> equivalent syntax? > > Tradition? All languages I know of treat a number with an exponent as > floating point. Approximate real numbers are

Re: Strange behaviour with numbers in exponential notation

Am 02.09.16 um 19:24 schrieb Marco Sulla: Excuse me, I forgot to include the python list mail addess. I repost the mail. On Fri, Sep 2, 2016 at 6:18 PM, Christian Gollwitzer wrote: 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is

Re: Strange behaviour with numbers in exponential notation

On Fri, Sep 2, 2016, at 13:02, Marco Sulla wrote: > On Fri, Sep 2, 2016 at 6:17 PM, Random832 wrote: > > Trying to add 1 gets it rounded off again, and the value is simply > > printed as 1e+26 by default because this is the shortest representation > > that gives the same

Re: Strange behaviour with numbers in exponential notation

Excuse me, I forgot to include the python list mail addess. I repost the mail. On Fri, Sep 2, 2016 at 6:18 PM, Christian Gollwitzer wrote: > 1e26 denotes a *floating point number* Floating point has finite precision, > in CPython it is a 64bit IEEE number. The largest exact

Re: Strange behaviour with numbers in exponential notation

Am 02.09.16 um 17:51 schrieb Marco Sulla: 10**26 - 1 99 1e26 - 1 1e+26 10**26 is computed with integer arithmetics. Python has bigints (i.e. as big as the memory allows) 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is

Re: Strange behaviour with numbers in exponential notation

On Fri, Sep 2, 2016, at 11:51, Marco Sulla wrote: > >>> 10**26 - 1 > 99 > >>> 1e26 - 1 > 1e+26 > > > Why? Exponential notation creates floating point numbers, which have a limited amount of precision in binary. Specifically (on my system which, as most modern

Strange behaviour with numbers in exponential notation

>>> 10**26 - 1 99 >>> 1e26 - 1 1e+26 Why? -- https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

On 01/15/2016 05:58 PM, Shiva Upreti wrote: > > What kind of further details do you want? Please tell me and i will try my > best to provide them. As always, post a small but complete example test program (no more than 20 lines of code) that has the problem. Paste it in such a way that one can

Re: wxpython strange behaviour

On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti wrote: > https://gist.github.com/anonymous/4baa67aafd04555eb4e6 > > I wrote the above code to display a toasterbox, and I didnt want it to > display any frames on the screen, just a toasterbox. The problem with this > code

wxpython strange behaviour

https://gist.github.com/anonymous/4baa67aafd04555eb4e6 I wrote the above code to display a toasterbox, and I didnt want it to display any frames on the screen, just a toasterbox. The problem with this code is that it runs fine when I run it the first time, but when I run it next time it shows

Re: wxpython strange behaviour

On 15/01/2016 17:05, Shiva Upreti wrote: https://gist.github.com/anonymous/4baa67aafd04555eb4e6 I wrote the above code to display a toasterbox, and I didnt want it to display any frames on the screen, just a toasterbox. The problem with this code is that it runs fine when I run it the first

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:35:57 PM UTC+5:30, Shiva Upreti wrote: > https://gist.github.com/anonymous/4baa67aafd04555eb4e6 > > I wrote the above code to display a toasterbox, and I didnt want it to > display any frames on the screen, just a toasterbox. The problem with this > code is

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:55:59 PM UTC+5:30, Ian wrote: > On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti > wrote: > > https://gist.github.com/anonymous/4baa67aafd04555eb4e6 > > > > I wrote the above code to display a toasterbox, and I didnt want it to > >

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:55:59 PM UTC+5:30, Ian wrote: > On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti > wrote: > > https://gist.github.com/anonymous/4baa67aafd04555eb4e6 > > > > I wrote the above code to display a toasterbox, and I didnt want it to > >

Re: wxpython strange behaviour

On Saturday, January 16, 2016 at 2:22:24 AM UTC+5:30, Mark Lawrence wrote: > On 15/01/2016 17:05, Shiva Upreti wrote: > > https://gist.github.com/anonymous/4baa67aafd04555eb4e6 > > > > I wrote the above code to display a toasterbox, and I didnt want it to > > display any frames on the screen,

Re: wxpython strange behaviour

On Saturday, January 16, 2016 at 4:39:12 AM UTC+5:30, Dietmar Schwertberger wrote: > On 15.01.2016 18:05, Shiva Upreti wrote: > > Please help me solve these issues. > Please decide first on which list or forum you want your questions to be > answered. Once people find out that you are asking the

Re: wxpython strange behaviour

On 15.01.2016 18:05, Shiva Upreti wrote: Please help me solve these issues. Please decide first on which list or forum you want your questions to be answered. Once people find out that you are asking the same questions all over, the support will soon end. Regards, Dietmar --

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Serhiy Storchaka added the comment: Here is a patch that fixes an infinite loop reported in msg254071. May be this is not the best solution. It makes the behavior of Python and C implementation differ (the former just iterates a linked list, the latter raises an error). But to reproduce

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Roundup Robot added the comment: New changeset 1594c23d8c2f by Serhiy Storchaka in branch '3.5': Issue #24726: Revert setting the value on the dict if https://hg.python.org/cpython/rev/1594c23d8c2f New changeset b391e97ccfe5 by Serhiy Storchaka in branch 'default': Issue #24726: Revert setting

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Serhiy Storchaka added the comment: Wrong issue. The correct one is issue25410. -- ___ Python tracker ___ ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Serhiy Storchaka added the comment: Thanks for your review Eric. test_delitem_2 was not added because it fails in just added TestCase for COrderedDict subclass. Added tests for direct calls of other dict methods as Eric suggested. During writing new tests for direct calls of other dict

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Serhiy Storchaka added the comment: Ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Eric Snow added the comment: FTR, this will likely involve more than just fixing odict_repr(). -- ___ Python tracker ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Serhiy Storchaka added the comment: __repr__() allocates a list with the size len(od) and fills it iterating linked list. If the size of linked list is less then the size of the dict, the rest of the list is not initialized. Even worse things happened when the size of linked list is greater

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Terry J. Reedy added the comment: Attached revised file that runs to completion on 2.7 and 3.x. -- nosy: +terry.reedy stage: - test needed versions: +Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40089/tem2.py ___ Python

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Terry J. Reedy added the comment: Marco, #-prefixed issue numbers like this, #24721, #24667, and #24685, are easier to read. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24726 ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24726 ___ ___

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Raymond Hettinger added the comment: There is a bug in _PyObject_GenericSetAttrWithDict() Objects/object.c where a calls are made to PyDict_SetItem() and PyDict_DelItem() without checking first checking for PyDict_CheckExact(). * In PEP 372, OrderedDict was consciously specified to be a

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24726 ___ ___ Python-bugs-list

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

Marco Paolini added the comment: Linking related issues http://bugs.python.org/issue24721 http://bugs.python.org/issue24667 and http://bugs.python.org/issue24685 -- nosy: +mpaolini ___ Python tracker rep...@bugs.python.org

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

: test.py messages: 247421 nosy: Mark.Shannon, eric.snow priority: normal severity: normal status: open title: OrderedDict has strange behaviour when dict.__setitem__ is used. type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file40028/test.py

[issue24438] Strange behaviour when multiplying imaginary inf by 1

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24438 ___ ___

[issue24438] Strange behaviour when multiplying imaginary inf by 1

Steven D'Aprano added the comment: I've found the same behaviour going back to Python 1.5. I think what happens here is that (0+∞j)*1 evaluates the multiplication by implicitly coercing the int to a complex: (0+∞j)*(1+0j) = (0*1 + ∞j*1 + 0*0j + ∞j*0j) = (0-NAN + ∞j+0j) = (NAN

[issue24438] Strange behaviour when multiplying imaginary inf by 1

Mark Dickinson added the comment: Closing as not a bug; for the suggestion of changing the mixed-type arithmetic behaviour, I think that's something that should be discussed on the python-ideas mailing list. -- resolution: - not a bug stage: - resolved status: open - closed

  1   2   3   4   >