[issue400683] randomize test execution order in regrtest.py

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

[issue400683] randomize test execution order in regrtest.py

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

[issue38664] await execution order leads to throw or bad syntax

Andrew Svetlov added the comment: What patch are you talking about? For me, patch means something special; e.g. working fork of CPython where the proposed idea is implemented. I read await coro()[key] as 1. Function named coro() returns a dict-like object 2. An element under key is selected

[issue38664] await execution order leads to throw or bad syntax

ait index_coroutine(coro(), slice(1, 5)) This is gross. It's a bug since it unnecessarily requires unpythonic code and throws pythonic code. My suggested patch would be to move the evaluation of the await statement higher up on the execution order so the former snippets would be valid python s

[issue34627] Python incorrect execution order

badrussians added the comment: Big Sorry - it is my mistake. In terminal I execute same file, but in other location. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue34627] Python incorrect execution order

Karthikeyan Singaravelan added the comment: Can you please describe the problem and the output you are expecting so that we can determine if it's a bug in Python or the logic of the code which will get better help from sites stackoverflow ? It will be helpful if you can do `tree` on the

[issue34627] Python incorrect execution order

' -- components: Interpreter Core files: test2.py messages: 324996 nosy: badrussians priority: normal severity: normal status: open title: Python incorrect execution order type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47795/test2.py

Re: unittest.Testsuite and execution order

On 20 Apr 2018 8:39 am, "Chris Angelico" wrote: On Fri, Apr 20, 2018 at 3:01 PM, Francesco Russo wrote: > On 18/04/18 20:26, Chris Angelico wrote: >> This is a bad idea. Each function that starts test_ should be >> completely independent. You should be

Re: unittest.Testsuite and execution order

On Fri, Apr 20, 2018 at 3:01 PM, Francesco Russo wrote: > On 18/04/18 20:26, Chris Angelico wrote: >> This is a bad idea. Each function that starts test_ should be >> completely independent. You should be able to run any one of them on >> its own (say, if you're trying to

Re: unittest.Testsuite and execution order

On 18/04/18 20:26, Chris Angelico wrote: > On Thu, Apr 19, 2018 at 2:51 AM, Francesco Russo > wrote: >> My use case: my SUT is split into modules. Besides writing unit tests for >> each module, I want to write an integration test, and I also need to >> perform some

Re: unittest.Testsuite and execution order

On Thu, Apr 19, 2018 at 2:51 AM, Francesco Russo wrote: > My use case: my SUT is split into modules. Besides writing unit tests for > each module, I want to write an integration test, and I also need to > perform some actions between two calls to the SUT. In my case, the

unittest.Testsuite and execution order

Hello! I'm reading the documentation of unittest.TestSuite (Python 2 and 3), but I can't find any explicit sentence stating that TestSuite will honor the order. I can only read that TestSuite can group test cases together. Please blame it on my poor English skills if I'm not interpreting the

[issue9788] atexit and execution order

Éric Araujo mer...@netwok.org added the comment: Reopened as #15233. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788 ___ ___

[issue9788] atexit and execution order

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset e37fa30c4be4 by Éric Araujo in branch '3.2': Document that atexit execution order is undefined (#9788) http://hg.python.org/cpython/rev/e37fa30c4be4 -- nosy: +python-dev

[issue9788] atexit and execution order

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset df415bfbb652 by Éric Araujo in branch '2.7': Document that atexit execution order is undefined (#9788) http://hg.python.org/cpython/rev/df415bfbb652 -- ___ Python tracker

[issue9788] atexit and execution order

Éric Araujo mer...@netwok.org added the comment: Given Benjamin and Giampaolo’s support, I committed my patch, so that at least the current behavior is documented. I personally have no opinion on LIFO vs. FIFO vs. undefined; I just think that the atexit module is not a wrapper around C’s

[issue9788] atexit and execution order

Giampaolo Rodola' g.rod...@gmail.com added the comment: Thanks. After all, I think that keeping atexit simple is the best solution and a doc adjustement is just fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788

[issue9788] atexit and execution order

Éric Araujo mer...@netwok.org added the comment: Here’s a patch. -- keywords: +needs review, patch resolution: accepted - stage: needs patch - patch review versions: +Python 3.3 -Python 3.1 Added file: http://bugs.python.org/file22318/doc-atexit-order-undefined.diff

[issue9788] atexit and execution order

Charles-François Natali neolo...@free.fr added the comment: I don't think the order should be defined. I disagree. The C standard explicitely states that the functions are called in LIFO order (which is the natural order in this case). The current implementation guarantees LIFO order, I

[issue9788] atexit and execution order

Changes by Skip Montanaro s...@pobox.com: -- nosy: -skip.montanaro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788 ___ ___ Python-bugs-list

[issue9788] atexit and execution order

Meador Inge mead...@gmail.com added the comment: I agree with Antoine's LIFO comment. Also, FWIW, the C standard library behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3): First, all functions registered by the atexit function are called, in the reverse order of their

[issue9788] atexit and execution order

? -- components: Library (Lib) messages: 115747 nosy: giampaolo.rodola priority: normal severity: normal status: open title: atexit and execution order versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788

[issue9788] atexit and execution order

Skip Montanaro s...@pobox.com added the comment: I'm sure you can craft cases where one order is preferable to another, but I don't think you can make the case in general that first in, first out is preferable to last in, first out, or any other ordering of exit functions. -- nosy:

[issue9788] atexit and execution order

Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788 ___ ___ Python-bugs-list

[issue9788] atexit and execution order

Giampaolo Rodola' g.rod...@gmail.com added the comment: I think it's not a matter of preferable but most expected and I see FIFO as the most expected behavior in this case. -- ___ Python tracker rep...@bugs.python.org

[issue9788] atexit and execution order

Antoine Pitrou pit...@free.fr added the comment: LIFO looks preferable if you want your setup/teardown code to be properly nested (that is, if I set up A before B, I want B to be torn down before A). -- nosy: +pitrou ___ Python tracker

[issue9788] atexit and execution order

Éric Araujo mer...@netwok.org added the comment: It seems to me that atexit is simple by design: It registers callables that do one thing, period. If you have dependencies in your cleanup code, you should write a function doing the Right Thing™ and register that. This keeps the implementation

[issue9788] atexit and execution order

Benjamin Peterson benja...@python.org added the comment: I don't think the order should be defined. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9788 ___

[issue9788] atexit and execution order

Giampaolo Rodola' g.rod...@gmail.com added the comment: Ok, I'll shut up then. =) If you agree, I could make a patch to make the docs more explicit about atexit’s simplicity and lack of guarantee about run order. Sure, go ahead. -- ___ Python

[issue9788] atexit and execution order

Changes by Éric Araujo mer...@netwok.org: -- assignee: - eric.araujo components: +Documentation -Library (Lib) resolution: - accepted stage: - needs patch versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org

Execution order

Here is some code from a pyqt4.5.4 application on python 2.6 def findData(self): self.ui.label.setText('Processing... ') # here we do something which takes a few seconds self.refreshGrid() The problem is that the text in the self.ui.label is only changed on screen after

Re: Execution order

DarkBlue wrote: Here is some code from a pyqt4.5.4 application on python 2.6 def findData(self): self.ui.label.setText('Processing... ') # here we do something which takes a few seconds self.refreshGrid() The problem is that the text in the self.ui.label is

Re: Execution order

On Sep 11, 9:34 pm, Diez B. Roggisch de...@nospam.web.de wrote: DarkBlue wrote: Here is some code from a pyqt4.5.4  application on python 2.6 def findData(self):       self.ui.label.setText('Processing... ')       # here we do something which takes a few seconds      

[issue6604] test_distutils subtest test_get_exe_bytes fails depending on execution order

Tarek Ziadé ziade.ta...@gmail.com added the comment: This was fixed in r71759 and backported in the 2.6 branch in r71765, thanks for the feedback! -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org

[issue6604] test_distutils subtest test_get_exe_bytes fails depending on execution order

the warning and producing a happier test ;e) -- assignee: tarek components: Distutils files: python-2.6.2-test_distutils.patch keywords: patch messages: 91100 nosy: matejcik, tarek severity: normal status: open title: test_distutils subtest test_get_exe_bytes fails depending on execution order type

execution order in list/generator expression

Hi, I am wondering how this is evaluated. a=(x for x in [1,2,3,4]) p=[4,5] c=[x for x in p if x in list(a)] c is [] but if I expand a first, like a = list(a) c is [4] So it seems that the if part don't get expanded ? -- http://mail.python.org/mailman/listinfo/python-list

Re: execution order in list/generator expression

[EMAIL PROTECTED] wrote: Hi, I am wondering how this is evaluated. a=(x for x in [1,2,3,4]) p=[4,5] c=[x for x in p if x in list(a)] c is [] No it isn't. In [1]: a=(x for x in [1,2,3,4]) In [2]: p=[4,5] In [3]: c=[x for x in p if x in list(a)] In [4]: c Out[4]: [4] I'm willing

Re: execution order in list/generator expression

[EMAIL PROTECTED] wrote: Hi, I am wondering how this is evaluated. a=(x for x in [1,2,3,4]) p=[4,5] c=[x for x in p if x in list(a)] c is [] but if I expand a first, like a = list(a) c is [4] So it seems that the if part don't get expanded ? Well, for every element in p it

Re: execution order in list/generator expression

Ah, no wonder. I test with p=[5,4]. thanks. so basically, I still need to expand it first given this behaviour. Robert Kern wrote: [EMAIL PROTECTED] wrote: Hi, I am wondering how this is evaluated. a=(x for x in [1,2,3,4]) p=[4,5] c=[x for x in p if x in list(a)] c is []