[issue401534] Use confirmations rather than assertions

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

[issue401534] Use confirmations rather than assertions

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

[issue45539] Negative lookaround assertions sometimes leak capture groups

Matthew Barnett added the comment: It's definitely a bug. In order for the pattern to match, the negative lookaround must match, which means that its subexpression mustn't match, so none of the groups in that subexpression have captured. -- versions: +Python 3.10

[issue45539] Negative lookaround assertions sometimes leak capture groups

matcher failed. Instead, the state of the matcher is discarded and some bottom value is returned (None, null or undefined). Similarly, one would expect nested subexpressions to behave the same way, so that capture groups from failed match attempts are discarded. -- c

Re: Mental model of lookahead assertions

On 2020-02-27, Stefan Ram wrote: > One can count overlapping occurences as follows. > >|>>> print(len(findall('(?=aa)','cb'))) >|3 > > Every web page says that lookahead assertions do > not consume nor move the "current position". > >

Re: Mental model of lookahead assertions

Stefan Ram wrote: One can count overlapping occurences as follows. |>>> print(len(findall('(?=aa)','cb'))) |3 Every web page says that lookahead assertions do not consume nor move the "current position". But what mental model can I make of the regex engin

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: New changeset f82ce5b1b12873b65927149a016be6a7c65e979d by Victor Stinner in branch '3.8': [3.8] bpo-36389: Backport debug enhancements from master (GH-16796) https://github.com/python/cpython/commit/f82ce5b1b12873b65927149a016be6a7c65e979d --

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: After pushing some fixes to 3.8 and master branches, I tested the following commands in 3.7, 3.8 and master branches: make distclean ./configure --prefix=$HOME/.local --with-assertions make ./python -m test -j0 test_bytes test_gc test_capi These commands

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: I pushed one more fix in https://bugs.python.org/issue36389#msg354138 -- ___ Python tracker ___

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: New changeset 435b2eeb7bc5b8ec264e900b38bcb3d76552d777 by Victor Stinner in branch '3.8': bpo-38376: Fix _PyUnicode_CheckConsistency() definition (GH-16623) https://github.com/python/cpython/commit/435b2eeb7bc5b8ec264e900b38bcb3d76552d777 --

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: New changeset 6876257eaabdb30f27ebcbd7d2557278ce2e5705 by Victor Stinner in branch 'master': bpo-36389: _PyObject_CheckConsistency() available in release mode (GH-16612) https://github.com/python/cpython/commit/6876257eaabdb30f27ebcbd7d2557278ce2e5705

[issue38376] ./configure --with-assertions generates a broken build

Change by STINNER Victor : -- pull_requests: +16210 pull_request: https://github.com/python/cpython/pull/16623 ___ Python tracker ___

[issue38376] ./configure --with-assertions generates a broken build

STINNER Victor added the comment: My intent in bpo-36389 was to also provide _PyObject_CheckConsistency() in release mode to help debugging GC crash, especially in visit_decref(). I wrote PR 16612 to fix my implementation. -- ___ Python tracker

[issue38376] ./configure --with-assertions generates a broken build

Change by STINNER Victor : -- pull_requests: +16201 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16612 ___ Python tracker ___

[issue38376] ./configure --with-assertions generates a broken build

Thomas Wouters added the comment: The problem is _PyUnicode_CheckConsistency switched from being only defined when Py_DEBUG is set, to being defined unconditionally. That was a good change, but it made the API-compatibility hack of #defining _PyUnicode_CheckConsistency in

[issue38376] ./configure --with-assertions generates a broken build

Change by Thomas Wouters : -- keywords: +patch pull_requests: +16183 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16594 ___ Python tracker ___

[issue38376] ./configure --with-assertions generates a broken build

Vinay Sajip added the comment: Adding Thomas and Victor based on git blame on some of the source lines concerned. -- nosy: +twouters, vstinner ___ Python tracker ___

[issue38376] ./configure --with-assertions generates a broken build

Vinay Sajip added the comment: BTW it also seems to fail when just Py_DEBUG is specified (no --with-assertions). -- ___ Python tracker <https://bugs.python.org/issue38

[issue38376] ./configure --with-assertions generates a broken build

New submission from Vinay Sajip : Following ./configure --prefix=$HOME/.local --with-assertions and then running make leads to an error: $ make gcc -pthread -c -Wno-unused-result -Wsign-compare -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Oh, I didn't mean to imply that these are the only options I'd support - just that these are the things I've thought through and that I think will all work well... I'm sure there are more options available ;) --

[issue19645] decouple unittest assertions from the TestCase class

Change by Robert Collins : -- versions: +Python 3.9 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Ok so design wise - there is state on the TestCase that influences assertions; in potentially two ways. The first way is formatting - the amount of detail shown in long list comparisons etc. The second way I don't think we have at the moment

[issue19645] decouple unittest assertions from the TestCase class

R. David Murray added the comment: "But - what are we solving for here?" I'll tell you what my fairly common use case is. Suppose I have some test infrastructure code, and I want to make some assertions in it. What I invariably end up doing is passing 'self' into the infr

[issue19645] decouple unittest assertions from the TestCase class

se context, with an unittest-compatible runner. If people corrupt it, I guess it's their problem? The point of decoupling is imho that other test runner might use the separate set of assertions. These assertions should raise a sensible default (i.e AssertionError) when encountering troubles, and accepting an

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Right now that attribute could be set by each test separately, or even varied within a test. TBH I'm not sure that the attribute really should be supported; perhaps thinking about breaking the API is worth doing. But - what are we solving for here. The OP

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Or even making the assert methods into custom descriptors. -- ___ Python tracker ___ ___

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Hmm, it could be done by __init_subclass__ potentially. -- ___ Python tracker ___ ___

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Suppose failureException is set to TypeError on that TestCase class, how would your assertEquals signal failure to the test runner? -- ___ Python tracker

[issue19645] decouple unittest assertions from the TestCase class

Pascal Chambon added the comment: I don't get it, why would failureException block anything ? The unittest.TestCase API must remain the same anyway, but it could become just a wrapper towards external assertions. For example : class TestCase: assertEqual = wrap(assertions.assert_equal

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Has anyone seen any real world use cases for failureException? It's a real hindrance to a whole bunch of changes sounds decoupling. On the other hand something like assertThat could catch a custom exception from the matchers (subclass of AssertionError) and

[issue19645] decouple unittest assertions from the TestCase class

) don't need to access an instance dict, they could be turned into such instance-less methods, and thus be usable from other testing frameworks (like pytest, for those who want to use pytest fixtures and yet benefit from advanced assertions like Django's TestCase's assertions). "failureExce

[issue37262] Make unittest assertions staticmethods/classmethods

Pascal Chambon added the comment: Indeed I missed this ticket, thanks -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37262] Make unittest assertions staticmethods/classmethods

Robert Collins added the comment: I think this is strictly redundant with that other ticket and I'm going to close it. That said, they need access to self.failureException. https://docs.python.org/3/library/unittest.html#unittest.TestCase.failureException -- stage: -> resolved

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Sorry for the slow reply here; There are API breaks involved in any decoupling that involves the exception raising because of the failureException attribute. Something with signalling that can be adapted by other test suites etc might have merit, but I

[issue37262] Make unittest assertions staticmethods/classmethods

Change by Karthikeyan Singaravelan : -- components: +Library (Lib) -Tests nosy: +ezio.melotti, michael.foord, rbcollins versions: -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker

[issue37262] Make unittest assertions staticmethods/classmethods

Karthikeyan Singaravelan added the comment: See also issue19645 which seems to be a slightly related discussion -- nosy: +xtreak ___ Python tracker ___

[issue37262] Make unittest assertions staticmethods/classmethods

other testing frameworks (like pytest, for those who want to use all the power of fixtures and yet benefit from advanced assertions, like Django's TestCase's assertXXX). Am I missing something here? -- components: Tests messages: 345463 nosy: pakal priority: normal severity: normal status

[issue27423] Failed assertions when running test.test_os on Windows

STINNER Victor added the comment: This bug has been fixed in test_os or libregrtest, I don't recall, but it's now fixed ;-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

Re: Assertions

On Thursday, September 21, 2017 at 9:29:19 AM UTC-7, Tobiah wrote: > Are these completely equivalent? > > def foo(thing): > > assert(thing > 0), "Thing must be greater than zero" > > > def foo(thing): > > if not (thing > 0): raise AssertionError("Thing must be greater than >

Re: Assertions

Op 2017-09-22, Thomas Jollans schreef : > Just to make the implication explicit: > from math import nan nan is nan > True nan == nan > False nan != nan > True To add to the fun: >>> nan is nan True Stephan --

Re: Assertions

On 2017-09-22 14:43, Steve D'Aprano wrote: > In the case of floating point NANs, they are unordered with respect to all > numbers. So for any number x, we always have: > > NAN == x > NAN < x > NAN > x > NAN <= x > NAN >= x > > all return False, and > > NAN != x > > return True. Just to make

Re: Assertions

On Fri, 22 Sep 2017 10:03 pm, alister wrote: > On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote: > >> On Fri, 22 Sep 2017 08:50 pm, alister wrote: >> The bottom line is, if I saw if not (thing > 0): raise AssertionError(...) in a code review, I'd probably

Re: Assertions

On 2017-09-22 14:03, alister via Python-list wrote: > On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote: >> On Fri, 22 Sep 2017 08:50 pm, alister wrote: >>> [snip] >>> >>> In a code review I would want the condition changed to be less noisy/ >>> confusing to the reader. >>> >>> if thing

Re: Assertions

On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote: > On Fri, 22 Sep 2017 08:50 pm, alister wrote: > >>> The bottom line is, if I saw >>> >>> if not (thing > 0): raise AssertionError(...) >>> >>> in a code review, I'd probably insist that either it be changed to use >>> `assert`, >>> or

Re: Assertions

On Fri, 22 Sep 2017 08:50 pm, alister wrote: >> The bottom line is, if I saw >> >> if not (thing > 0): raise AssertionError(...) >> >> in a code review, I'd probably insist that either it be changed to use >> `assert`, >> or the exception be changed to ValueError, whichever better expresses >>

Re: Assertions

because it > uses the assert keyword! > > The second is testing a condition, and if need be, raising an exception. > Which looks like an inappropriate exception. Why AssertionError? It > looks like it ought to be a ValueError. > > Assertions aren't merely a synonym

Re: Assertions

On Fri, Sep 22, 2017 at 3:49 AM, Steve D'Aprano wrote: > On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote: > >> Impressive. That means that, in 2.7, it's actually equivalent to: >> > def test3(): >> ... if not foo: raise AssertionError, "bar baz" > > That's

Re: Assertions

On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote: > On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano > wrote: >> That is definitely version-dependent, because I've just tried it and got >> different byte-code in Python 2.7. >> >> py> import dis >> py> def test1(): >>

Re: Assertions

I think we should say that the two above are very different. The first is an actual assertion. It has to be an assertion, because it uses the assert keyword! The second is testing a condition, and if need be, raising an exception. Which looks like an inappropriate exception. Why AssertionErro

Re: Assertions

On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano wrote: > That is definitely version-dependent, because I've just tried it and got > different byte-code in Python 2.7. > > py> import dis > py> def test1(): > ... assert foo, "bar baz" > ... > py> def test2(): > ...

Re: Assertions

On Fri, 22 Sep 2017 02:59 am, Ned Batchelder wrote: > On 9/21/17 12:29 PM, Tobiah wrote: >> Are these completely equivalent? [... assert, versus test and raise AssertionError ...] > Let's see: [...] > Yes, they are completely equivalent, compiling to precisely the same > bytecode. That is

Re: Assertions

On 9/21/17 12:29 PM, Tobiah wrote: Are these completely equivalent? def foo(thing): assert(thing > 0), "Thing must be greater than zero" def foo(thing): if not (thing > 0): raise AssertionError("Thing must be greater than zero") Other than the fact that the assertion

Assertions

Are these completely equivalent? def foo(thing): assert(thing > 0), "Thing must be greater than zero" def foo(thing): if not (thing > 0): raise AssertionError("Thing must be greater than zero") Other than the fact that the assertion can be turned off with -O? Thanks,

[issue27423] Failed assertions when running test.test_os on Windows

Steve Dower added the comment: The warnings are expected - Python has to be able to handle arbitrarily bad parameters/use without crashing, while the CRT assumes that bugs belong to the direct caller who needs to fix them. As a result, it will assert and terminate for blatantly incorrect

[issue27423] Failed assertions when running test.test_os on Windows

Eryk Sun added the comment: test_os intentionally operates on invalid file descriptors. In the Windows CRT this leads to failed assertions, such as from its _VALIDATE_RETURN macro. This macro would also call the default invalid parameter handler, which would kill the process, but that's

[issue27423] Failed assertions when running test.test_os on Windows

Emanuel Barry added the comment: I'm not sure about the patch - sure, the messages might go away, but I find it concerning that the assertions are failing to begin with. Of course, it only happens when in debug (and this might be a non-issue in practice, I haven't checked), but shouldn't we

[issue27423] Failed assertions when running test.test_os on Windows

Changes by Serhiy Storchaka : -- nosy: +haypo ___ Python tracker ___ ___

[issue27423] Failed assertions when running test.test_os on Windows

Eryk Sun added the comment: The attached patch suppresses the failed-assertion message boxes when running test_os on a debug build. -- keywords: +patch nosy: +eryksun stage: needs patch -> patch review Added file: http://bugs.python.org/file43595/issue27423_1.patch

[issue27423] Failed assertions when running test.test_os on Windows

, zach.ware priority: normal severity: normal stage: needs patch status: open title: Failed assertions when running test.test_os on Windows type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43590/test_os failed assertion.png ___ Python

[issue19006] UnitTest docs should have a single list of assertions

Roundup Robot added the comment: New changeset ddb8fa84a119 by Ezio Melotti in branch '2.7': #19006: fix wording in unittest docs. https://hg.python.org/cpython/rev/ddb8fa84a119 New changeset 84f34e8685de by Ezio Melotti in branch '3.5': #19006: fix wording in unittest docs.

[issue19006] UnitTest docs should have a single list of assertions

Ezio Melotti added the comment: Fixed, thanks for the review! -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker

[issue25517] regex howto example in "Lookahead Assertions"

Ezio Melotti added the comment: Fixed, thanks for the patch! -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue25517] regex howto example in "Lookahead Assertions"

Roundup Robot added the comment: New changeset c6b5c03183e3 by Ezio Melotti in branch '2.7': #25517: fix regex in the regex howto. Patch by Elena Oat. https://hg.python.org/cpython/rev/c6b5c03183e3 New changeset 6bd4a4907f66 by Ezio Melotti in branch '3.5': #25517: fix regex in the regex

[issue25517] regex howto example in "Lookahead Assertions"

Elena Oat added the comment: Corrected the regular expression and documented why [^.]* is used. -- keywords: +patch nosy: +Elena.Oat Added file: http://bugs.python.org/file41566/issue25517.diff ___ Python tracker

[issue25517] regex howto example in "Lookahead Assertions"

Changes by Ezio Melotti : -- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett versions: -Python 3.4 ___ Python tracker

[issue19006] UnitTest docs should have a single list of assertions

Kushal Das added the comment: The patch looks good to me. Commit :) -- ___ Python tracker ___ ___

[issue19006] UnitTest docs should have a single list of assertions

Ezio Melotti added the comment: Here's a patch. -- assignee: docs@python -> ezio.melotti keywords: +patch stage: -> commit review versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file41462/issue19006.diff

[issue23919] [Windows] test_os fails several C-level assertions

Roundup Robot added the comment: New changeset 69c4fa62b608 by Steve Dower in branch '3.5': Issue #23919: Prevents assert dialogs appearing in the test suite. https://hg.python.org/cpython/rev/69c4fa62b608 New changeset 62897db9ae51 by Steve Dower in branch 'default': Issue #23919: Prevents

[issue23919] [Windows] test_os fails several C-level assertions

Changes by Steve Dower : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue23919] [Windows] test_os fails several C-level assertions

STINNER Victor added the comment: I would prefer to disable the popups and messages to stderr by default in Python directly. If some users want to see them, we can add a -X option to enable them. Example: -X enable_mscrt_checks. What do you think? Do you recall who complain that Python hides

[issue23919] [Windows] test_os fails several C-level assertions

STINNER Victor added the comment: 23919_1.patch looks good to me. -- ___ Python tracker ___ ___

[issue23919] [Windows] test_os fails several C-level assertions

Steve Dower added the comment: I referred to the issues that had -n added in the first place many times while adding the IPH handlers, but I don't have them handy now on my phone. The rationale was that people who cause assertions in their C extensions should see them and not have Python

[issue23919] [Windows] test_os fails several C-level assertions

Steve Dower added the comment: This patch: * defaults to no assert dialogs and no stderr output * enables stderr output for assertions on "-vv" (or more) * displays a deprecation message on "-n" -- assignee: -> steve.dower keywords: +patch versions: +Pyth

[issue19006] UnitTest docs should have a single list of assertions

Changes by Nicholas H.Tollervey : -- nosy: +kushal.das, ntoll ___ Python tracker ___ ___

[issue19006] UnitTest docs should have a single list of assertions

Changes by Arnon Yaari : -- nosy: +wiggin15 ___ Python tracker ___ ___ Python-bugs-list

[issue23919] [Windows] test_os fails several C-level assertions

Steve Dower added the comment: So just discussed with Zach the idea of hiding all assertion outputs by default and then using -n to display the output on stderr. That would help people get started running tests locally as well, since the dialogs that appear by default look like pretty bad

[issue23919] [Windows] test_os fails several C-level assertions

Changes by STINNER Victor victor.stin...@gmail.com: -- title: test_os fails several C-level assertions - [Windows] test_os fails several C-level assertions ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23919

[issue23919] test_os fails several C-level assertions

STINNER Victor added the comment: The fix for these is to hide the output, which is in the test modules handling of the -n option. Since Python raises an exception for EBADF, I don't see the purpose of these assertion messages. -- ___ Python

[issue23919] test_os fails several C-level assertions

Steve Dower added the comment: I mean we just suppress the output completely. Currently it sets the mode to stderr but we can set it to silent, though I don't recall what the name of the constant we need is. -- ___ Python tracker

[issue23919] test_os fails several C-level assertions

Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23919 ___ ___ Python-bugs-list

[issue23919] test_os fails several C-level assertions

Steve Dower added the comment: The fix for these is to hide the output, which is in the test modules handling of the -n option. The assertions should fail, as they are testing error conditions. -- ___ Python tracker rep...@bugs.python.org http

[issue23919] test_os fails several C-level assertions

Zachary Ware added the comment: Here's the problem with that: C:\Data\code\CPython\hg.python.org\defaultpython -m test.test_os Running Debug|Win32 interpreter... s..crash with error popup -- ___ Python tracker rep...@bugs.python.org

[issue23919] test_os fails several C-level assertions

... -- Ran 189 tests in 7.424s OK (skipped=75) 1 test OK. -- components: Windows messages: 240522 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_os fails several C-level assertions

[issue814253] Grouprefs in lookbehind assertions

Roundup Robot added the comment: New changeset b78195af96f5 by Serhiy Storchaka in branch 'default': Issues #814253, #9179: Group references and conditional group references now https://hg.python.org/cpython/rev/b78195af96f5 New changeset 5387095b8675 by Serhiy Storchaka in branch '2.7': Issues

[issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O

New submission from STINNER Victor: Spinoff of the issue #22926: asyncio.get_event_loop() must always raise an exception, even when assertions are disabled by -O. Attached patch implements this suggestion. -- components: asyncio files: get_event_loop.patch keywords: patch messages

[issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O

Roundup Robot added the comment: New changeset b4dce0e695df by Victor Stinner in branch '3.4': Issue #23074: asyncio.get_event_loop() now raises an exception if the thread https://hg.python.org/cpython/rev/b4dce0e695df -- nosy: +python-dev ___ Python

[issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O

STINNER Victor added the comment: Change applied to Python 3.4, 3.5 and Tulip (c6115bc83acc). Thanks for the review Guido. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23074

[issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O

STINNER Victor added the comment: I also updated aiotest test suite: https://bitbucket.org/haypo/aiotest/commits/d6f544a16a8f55729268d8d4b8d864d1b0af2d12 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23074

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Hi, I'm glad you're interested in this. I very much want to see a matcher/hamcrest approach rather than a library of assertions per se - because match-or-except makes layering things harder. -- ___ Python tracker

[issue814253] Grouprefs in lookbehind assertions

Roundup Robot added the comment: New changeset fac649bf2d10 by Serhiy Storchaka in branch '2.7': Issues #814253, #9179: Group references and conditional group references now https://hg.python.org/cpython/rev/fac649bf2d10 New changeset 9fcf4008b626 by Serhiy Storchaka in branch '3.4': Issues

[issue814253] Grouprefs in lookbehind assertions

Roundup Robot added the comment: New changeset 0e2c7d774df3 by Serhiy Storchaka in branch '2.7': Silence the failure of test_pyclbr after adding a property in sre_parse https://hg.python.org/cpython/rev/0e2c7d774df3 New changeset 246c9570a757 by Serhiy Storchaka in branch '3.4': Silence the

[issue814253] Grouprefs in lookbehind assertions

Serhiy Storchaka added the comment: Now group references to groups with fixed width are supported in lookbehind assertions. -- assignee: effbot - serhiy.storchaka resolution: - fixed stage: patch review - resolved status: open - closed versions: +Python 2.7, Python 3.4, Python 3.5

[issue814253] Grouprefs in lookbehind assertions

Serhiy Storchaka added the comment: The patch for issue9179 fixes this issue too. -- nosy: +serhiy.storchaka superseder: - Lookback with group references incorrect (two issues?) ___ Python tracker rep...@bugs.python.org

[issue19645] decouple unittest assertions from the TestCase class

Serhiy Storchaka added the comment: Here are most popular idioms which deserve special assertion methods: assertHasAttr(obj, name) == assertTrue(hasattr(obj, name)) assertIsSubclass(type, expected) == assertTrue(issubclass(type, expected)) assertTypeIs(obj, expected) == assertIs(type(obj),

[issue19645] decouple unittest assertions from the TestCase class

Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19645 ___ ___ Python-bugs-list

Re: Assertions are bad, m'kay?

On Fri, 07 Mar 2014 16:15:36 -0800, Dan Stromberg wrote: On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Assertions are not bad! They're just misunderstood and abused. You should read this guy's blog post on when to use assert: http://import

Re: Assertions are bad, m'kay?

-compliant code! Assertions are not bad! They're just misunderstood and abused. (By the way, assertions are not the same as assumptions. Asserts can be used to check that assumptions are correct, or to check the internal logic of your reasoning. Whereas assumptions are just accepted as if they were

Re: Assertions are bad, m'kay?

On Fri, Mar 7, 2014 at 10:11 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: http://xkcd.com/1339/ Abusing assert for arg checking violates XKCD 1339. Write standards-compliant code! Assertions are not bad! They're just misunderstood and abused. (By the way, assertions

Re: Assertions are bad, m'kay?

On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Assertions are not bad! They're just misunderstood and abused. You should read this guy's blog post on when to use assert: http://import-that.dreamwidth.org/676.html Nice article. BTW, what about

Re: Assertions are bad, m'kay?

Dan Stromberg drsali...@gmail.com writes: BTW, what about: if value = 3: raise AssertionError('value must be = 3') That would be very confusing, since it would only appear when the value is = 3. Were you making some other point? -- \“If this is your first visit to the USSR, you

  1   2   3   >