Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
"Guido van Rossum" <[EMAIL PROTECTED]> writes: > Same here; let's tread carefully here and not change this with 3.0. > Starting to deprecate in 3.1 and killing in 3.3 would be soon enough. I'm very glad this is on the table. Even though I'd really like to see the names become PEP-8-conformant in the 2.x series, the arguments against such haste are compelling. So I'm convinced to be +1 on post-3.0 for changing the unittest API. > I like using only the assertKeyword variants, removing assert_, fail*, > and assertEquals. I'm the opposite. I prefer the 'fail*' variants over the 'assert*' variants, because "fail" tells me exactly what the function will *do*, while "assert" leaves it implicit what will actually happen if the assertion is false. For this reason, I'd prefer the "fail*" names to be recommended, and the "assert*" names to be, if not deprecated, then at least second-class citizens. -- \ “I think there is a world market for maybe five computers.” | `\ —Thomas Watson, chairman of IBM, 1943 | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Ben Finney wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> writes: [...] > > I like using only the assertKeyword variants, removing assert_, fail*, > > and assertEquals. > > I'm the opposite. I prefer the 'fail*' variants over the 'assert*' > variants, because "fail" tells me exactly what the function will *do*, > while "assert" leaves it implicit what will actually happen if the > assertion is false. > > For this reason, I'd prefer the "fail*" names to be recommended, and > the "assert*" names to be, if not deprecated, then at least > second-class citizens. On the other hand, “assert*” names are positive statements of what the behaviour of the system-under-test is. And conversely, “fail*” names are a bit like implementation details of how the test is written. So I personally have a mild preference for the assert* names. My suspicion is that it will be very hard to get consensus on the colour of this particular bike shed :) -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asser ts vs. failIf/Unlesses
Andrew Bennetts puzzling.org> writes: > > On the other hand, “assert*” names are positive statements of what the > behaviour of the system-under-test is. And conversely, “fail*” names are a > bit like implementation details of how the test is written. So I personally > have a mild preference for the assert* names. The problem with "fail*" is that you get names like "failIfNotEqual" (or perhaps even "failUnlessNotEqual") which are double negatives and therefore much more annoying to read and decipher. I always had the same problem when reading Perl's "unless" statements. They are, IMO, useless complication. "assert*" names are, well, assertive :-) (not to mention "assert" is a widely established name in various languages - including Python - for checking that things went as expected) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou <[EMAIL PROTECTED]> writes: > The problem with "fail*" is that you get names like "failIfNotEqual" That would better be written (preferring PEP 8 names) "fail_unless_equal". > (or perhaps even "failUnlessNotEqual") idem, "fail_if_equal". > which are double negatives Exactly. With "if" and "unless" at our disposal, we can avoid such double negatives. > (not to mention "assert" is a widely established name in various > languages - including Python - for checking that things went as > expected) That's another reason to avoid "assert" in the name: these methods *don't* necessarily use the 'assert' statement. Avoiding the implication that they do use that is a good thing. -- \ “Never do anything against conscience even if the state demands | `\ it.” —Albert Einstein | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Andrew Bennetts <[EMAIL PROTECTED]> writes: > On the other hand, “assert*” names are positive statements of what > the behaviour of the system-under-test is. That statement is better made by the name of the test case. The method used for implementing the test shouldn't need to be part of that statement. > And conversely, “fail*” names are a bit like implementation > details of how the test is written. Entirely appropriate, since those names are used exactly at the point of implementing the test, and the names are not visible outside that implementation. No? > My suspicion is that it will be very hard to get consensus on the > colour of this particular bike shed :) Perhaps so :-) -- \ “Quidquid latine dictum sit, altum viditur.” (“Whatever is | `\ said in Latin, sounds profound.”) —anonymous | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] AMD64-W2k8 buildbot wedged
The compilation step on this buildbot is failing because it can't delete or overwrite any of the Python DLLs [1]. Is there any way to fix this remotely, or at least to tell why kill_python isn't doing the trick? (Going back a bit further, it looks like test_multiprocessing is the culprit as the original hanging test. The number of 64-bit safeness warnings being emitted by the current trunk is also fairly worrying) Cheers, Nick. [1] http://www.python.org/dev/buildbot/all/AMD64%20W2k8%20trunk/builds/757/step-compile/0 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: ass erts vs. failIf/Unlesses
Ben Finney benfinney.id.au> writes:
>
> That would better be written (preferring PEP 8 names)
> "fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
> That's another reason to avoid "assert" in the name: these methods
> *don't* necessarily use the 'assert' statement.
But all those constructs (assert, assertEqual, etc.) raise the same exception
type named AssertionError which, if you care for naming consistency, is more
important than whether or not they are implemented in terms of each other. :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou wrote:
Ben Finney benfinney.id.au> writes:
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
"Fail" isn't a negative. As Guido said, it's a description of the test
behavior under particular circumstances. "fail_unless_equal" says quite
clearly that the test requires equality of the values.
That's another reason to avoid "assert" in the name: these methods
*don't* necessarily use the 'assert' statement.
But all those constructs (assert, assertEqual, etc.) raise the same exception
type named AssertionError which, if you care for naming consistency, is more
important than whether or not they are implemented in terms of each other. :-)
But the important behavior is the failure of the test, not the specific
exception that is raised to fail it. Or would you prefer tests that
raise other exceptions to succeed? The exception type is an
implementation detail, and a fairly unimportant one as far as the
purpose of testing goes.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou <[EMAIL PROTECTED]> writes:
> Ben Finney benfinney.id.au> writes:
> > That would better be written (preferring PEP 8 names)
> > "fail_unless_equal".
>
> Which is still a double negative ("fail" and "unless" are both
> negative words).
Hmm, not to this native-English-speaker's ear. "fail" is a verb
stating what will be done, while "unless" and "if" are the conditions
under which it will be done.
> > That's another reason to avoid "assert" in the name: these methods
> > *don't* necessarily use the 'assert' statement.
>
> But all those constructs (assert, assertEqual, etc.) raise the same
> exception type named AssertionError
Only by default. They can be overridden to raise any exception type.
The only thing they have in common at that point (when the exception
is raised) is that they have failed the test.
--
\ “First things first, but not necessarily in that order.” —The |
`\ Doctor, _Doctor Who_ |
_o__) |
Ben Finney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Update bz2 library?
I just noticed that the bz2lib version was updated to 1.0.5 in December of 2007, for security reasons. I suspect it would be good to be sure to ship this with 2.6 or 3.0. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asser ts vs. failIf/Unlesses
Let's split hairs a little... Steve Holden holdenweb.com> writes: > "Fail" isn't a negative. As Guido said, it's a description of the test > behavior under particular circumstances. In most circumstances, "fail" is a negative word defined as the contrary of something else (that is, as the "failure to pass/succeed/perform/achieve/..."), while the reverse is not true (few people would define "success" or "passing a test" as the negative of "failure", except in desperate circumstances). Although I'm not a native English speaker, I don't think our respective languages and cultures differ on this point. > "fail_unless_equal" says quite > clearly that the test requires equality of the values. Actually, saying "that the test requires equality of the values" translates directly into an "assert equals" (or "enforce equals" if you want a stronger word) rather than a "fail if not equal". It is a grammatical fact... In other words, if you express a requirement, you intent to say how the implementation under test is supposed to behave for it to be considered successful, not the conditions under which its behaviour constitutes a failure. As you said, if an exception is thrown which isn't part of the testing protocol (e.g. something other than an AssertionError), the test is still said to fail... if the intent of testing were to test for failure conditions, on the contrary, the test would be said to be passed (because it wouldn't have met the failure conditions). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou wrote: Let's split hairs a little... Steve Holden holdenweb.com> writes: "Fail" isn't a negative. As Guido said, it's a description of the test behavior under particular circumstances. In most circumstances, "fail" is a negative word defined as the contrary of something else (that is, as the "failure to pass/succeed/perform/achieve/..."), while the reverse is not true (few people would define "success" or "passing a test" as the negative of "failure", except in desperate circumstances). Although I'm not a native English speaker, I don't think our respective languages and cultures differ on this point. "fail_unless_equal" says quite clearly that the test requires equality of the values. Actually, saying "that the test requires equality of the values" translates directly into an "assert equals" (or "enforce equals" if you want a stronger word) rather than a "fail if not equal". It is a grammatical fact... In other words, if you express a requirement, you intent to say how the implementation under test is supposed to behave for it to be considered successful, not the conditions under which its behaviour constitutes a failure. Agreed. I tend to think of testing as action followed by assertion - I do this and this should have happened. Your tests usually define 'expected behaviour' rather than defining how your code won't fail... Michael As you said, if an exception is thrown which isn't part of the testing protocol (e.g. something other than an AssertionError), the test is still said to fail... if the intent of testing were to test for failure conditions, on the contrary, the test would be said to be passed (because it wouldn't have met the failure conditions). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A proposed solution for Issue 502236: Asyncrhonousexceptions between threads
Thanks Guys So it seems as if I've made some pretty basic newbie mistakes then :-$ 1. Posting to the wrong list 2. Posting about something that already has a work around oh well never mind - better luck next time ;-) Only one thing comes to my mind about the comments made saying that this is no longer an issue: All of the solutions presented rely on the use of a third party library to control the threading. It appears as if there have been no basic changes to the thread package that ships with Python to resolve this. While it is possible to set and read global variables &c to do something close - it doesn't strike me as a nice solution as Python offers in so many other places. However, I am willing to concede that as the issue has been dormant (or appears to be) now for ~2years that it can not be a particularly burning issue. So I'll go back and trawl the open issues for something else to help my favourite language get better :-) Andy - Brain chemistry is not just for Christmas [snipped the replies to cut down on re-quote spam - cos I kind of hate that] _ Invite your Facebook friends to chat on Messenger http://clk.atdmt.com/UKM/go/101719649/direct/01/___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Mon, 14 Jul 2008 12:45:58 am Michael Foord wrote: > I tend to think of testing as action followed by assertion - > I do this and this should have happened. Your tests usually define > 'expected behaviour' rather than defining how your code won't fail... Who is the "your" that you are speaking for there? It isn't me. I tend to think of tests as *both* expected behaviour and unexpected behaviour: sometimes a test is most naturally written as "this should happen" and sometimes as "this shouldn't happen". It depends on what I'm testing. When it comes to test-driven development, I will often start by thinking "What test can I write to make this code fail?" -- not "what test can I write to make this code pass?". Having come up with a failure mode, the test is often most naturally written as "fail if" or "fail unless", and I resent having to turn the condition around into a "assert if not" test just to satisfy others who are never going to read my code. I wish people would go find another bike shed to interfere with. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou wrote: Let's split hairs a little... Steve Holden holdenweb.com> writes: "Fail" isn't a negative. As Guido said, it's a description of the test behavior under particular circumstances. In most circumstances, "fail" is a negative word defined as the contrary of something else (that is, as the "failure to pass/succeed/perform/achieve/..."), while the reverse is not true (few people would define "success" or "passing a test" as the negative of "failure", except in desperate circumstances). Although I'm not a native English speaker, I don't think our respective languages and cultures differ on this point. "The test will fail" is an assertion (in English, not in Python :). It is not a negative. "The test will not fail" is an assertion containing a negative. "The test will not not fail" is an assertion containing a double negative. "fail_unless_equal" says quite clearly that the test requires equality of the values. Actually, saying "that the test requires equality of the values" translates directly into an "assert equals" (or "enforce equals" if you want a stronger word) rather than a "fail if not equal". It is a grammatical fact... Right. For extra points, discuss the differences between "fail_unless_equal", "fail_if_not_equal", assert_equals" and "assert_unequal". In other words, if you express a requirement, you intent to say how the implementation under test is supposed to behave for it to be considered successful, not the conditions under which its behaviour constitutes a failure. As you said, if an exception is thrown which isn't part of the testing protocol (e.g. something other than an AssertionError), the test is still said to fail... if the intent of testing were to test for failure conditions, on the contrary, the test would be said to be passed (because it wouldn't have met the failure conditions). But Guido said: > I like using only the assertKeyword variants, removing assert_, fail*, > and assertEquals. So we are now no longer discussing what color to paint the bike shed, we are discussing how to describe the color. Let's stop. This is getting silly. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Mon, 14 Jul 2008 12:39:48 am Antoine Pitrou wrote: > Let's split hairs a little... > > Steve Holden holdenweb.com> writes: > > "Fail" isn't a negative. As Guido said, it's a description of the > > test behavior under particular circumstances. > > In most circumstances, "fail" is a negative word defined as the > contrary of something else (that is, as the "failure to > pass/succeed/perform/achieve/..."), while the reverse is not true > (few people would define "success" or "passing a test" as the > negative of "failure", except in desperate circumstances). "Few people"? Do you have studies to support your claim, or are you just projecting your own opinion as if it were an objective fact? I often consider "success" as the negative of failure: my code didn't fail. The bridge didn't fall down. The invasion didn't get bogged down in a long and pointless guerrilla war. The medicine didn't have massive side-effects. These are all successes. assert_bridge_not_collapsed() assert_no_guerrilla_war() assert_if_no_side-effects() fail_if_bridge_collapsed() fail_if_guerrilla_war() fail_if_side_effects() Speaking for myself, the last three are far more natural to me. I'll also point out that in science, success is often considered the opposite of failure. You design your experiments to disprove the theory, to fail, and if they don't fail, the theory is considered successful. A theory is considered "correct" when it has failed to fail. Some philosophers of science, like the late Karl Popper, consider this falsification to be the defining characteristic of science. [...] > In other words, if you express a requirement, you intent to say how > the implementation under test is supposed to behave for it to be > considered successful, not the conditions under which its behaviour > constitutes a failure. Please don't tell me what my intent is. Unless you are a mind-reader, you have no way of telling what my intent is. When I write tests, my intent is often to specify the conditions that constitute a failure. I don't want to negate it to specify a success just to satisfy you. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AMD64-W2k8 buildbot wedged
Nick Coghlan wrote: > The compilation step on this buildbot is failing because it can't delete > or overwrite any of the Python DLLs [1]. Is there any way to fix this > remotely, or at least to tell why kill_python isn't doing the trick? That is in the log: TerminateProcess failed: 5 where 5 is ERROR_ACCESS_DENIED. Now, *why* the system is refusing to terminate the process is difficult to say. It's a general Windows problem: the system doesn't support forced process termination in a reliable manner. In any case, Trent seems to have fixed the problem. > The number of 64-bit safeness > warnings being emitted by the current trunk is also fairly worrying) Do you have a specific one in mind? The ones truncating size_t/ssize_t should only matter when you actually do have data larger than 2GiB. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update bz2 library?
> I just noticed that the bz2lib version was updated to 1.0.5 in December > of 2007, for security reasons. I suspect it would be good to be sure > to ship this with 2.6 or 3.0. Python 2.6b1 shipped with bzip2 1.0.5. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
> On Mon, 14 Jul 2008 12:45:58 am Michael Foord wrote: > > > I tend to think of testing as action followed by assertion - > > I do this and this should have happened. Your tests usually define > > 'expected behaviour' rather than defining how your code won't fail... > > Who is the "your" that you are speaking for there? It isn't me. Although Michael unfortunately chose to use "Your", it is clear to me that the context implies he actually meant "My" (as in, his) > I resent having to turn the condition around into > a "assert if not" test just to satisfy others who are never going to > read my code. I wish people would go find another bike shed to > interfere with. Oh please, just get over it, and try to stick to the issue at hand rather than trying to score points or acting under the assumption that everyone is out to give you cause to "resent" things... As Steve said, this is getting silly... Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unquote - Unicode issues
* Matt Giuca wrote: > > This POV is way too browser-centric... > > This is but one example. Note that I found web forms to be the least > clear-cut example of choosing an encoding. Most of the time applications > seem to be using UTF-8, and all the standards I have read are moving > towards specifying UTF-8 (from being unspecified). I've never seen a > standard specify or even recommend Latin-1. Ahem. The HTTP standard does ;-) > Where web forms are concerned, basically setting the form accept-charset > or the page charset is the *maximum amount* of control you have over the > encoding. As you say, it can be encoded by another page or the user can > override their settings. Then what can you do as the server? Nothing ... Guessing works pretty well in most of the cases. > Exactly. This is exactly my point - Latin-1 is arbitrary from a standards > point of view. It's just one of the many legacy encodings we'd like to > forget. The UTFs are the only options which support all languages, and > UTF-8 is the only ASCII-compatible (and therefore URI-compatible) > encoding. So we should aim to support that as the default. Latin-1 is not exactly arbitray. Besides being a charset - it maps one-to-one to octet values, hence it's commonly used to encode octets and is therefore a better fallback than every other encoding. > I agree. However if there *was* a proper standard we wouldn't have to > argue! "Most proper" and "should do" is the most confident we can be when > dealing with this standard, as there is no correct encoding. Well, the standard says, there are octets to be encoded. I find that proper enough. > Does anyone have a suggestion which will be more compatible with the rest > of the world than allowing the user to select an encoding, and defaulting > to "utf-8"? Default to latin-1 for decoding and utf-8 for encoding. This might be confusing though, so maybe you've asked the wrong question ;) nd -- Real programmers confuse Christmas and Halloween because DEC 25 = OCT 31. -- Unknown (found in ssl_engine_mutex.c) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Antoine Pitrou wrote:
Ben Finney benfinney.id.au> writes:
That would better be written (preferring PEP 8 names)
"fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
That's another reason to avoid "assert" in the name: these methods
*don't* necessarily use the 'assert' statement.
But all those constructs (assert, assertEqual, etc.) raise the same exception
type named AssertionError which, if you care for naming consistency, is more
important than whether or not they are implemented in terms of each other. :-)
Regarding: "all those constructs ... raise the same exception type named
AssertionError.."
As an experiment a while back (out of frustration), I created some tests
that used more specific (local unittest module only) exceptions. The
clarity of the failed errors and the mental effort to debug the problems
was much improved for me.
I sub-classed unittest.TestCase, and added two new methods and a few local
and unique test-only exceptions.
* test -> a test function to call
* ref -> addition helpful debug info
assertTestReturns(test, expect, ref="")
raises on failure:
Wrong_Result_Returned
Unexpected_Exception_Raised
assertTestRaises(test, expect, ref="")
raises on failure:
No_Exception_Raised
Wrong_Exception_Raised
These more specific exceptions (over plain AssertionError), allowed for
more specific error reports.
A testcase with an error would produce a standard python exception so you
know instantly that you need to fix the test rather than the code being tested.
Also the more specific exception code can better handle some cases where a
wrong traceback would be returned. ie.. the test code traceback rather
than the code being tested traceback.
Is there any interest in going in this direction with unittests?
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A proposed solution for Issue 502236: Asyncrhonousexceptions between threads
Andy, You had an idea, and it was a pretty good idea, but the practical considerations made it a nonstarter. That's ok, it happens all the time, among both new and seasoned Python developers alike. Search for "a case for top and bottom values" on Google for a bit of a laugh ;) . - Josiah On Sun, Jul 13, 2008 at 8:28 AM, Andy Scott <[EMAIL PROTECTED]> wrote: > Thanks Guys > > So it seems as if I've made some pretty basic newbie mistakes then :-$ > > 1. Posting to the wrong list > 2. Posting about something that already has a work around > > oh well never mind - better luck next time ;-) > > Only one thing comes to my mind about the comments made saying that this is > no longer an issue: > > All of the solutions presented rely on the use of a third party library to > control the threading. It appears as if there have been no basic changes to > the thread package that ships with Python to resolve this. While it is > possible to set and read global variables &c to do something close - it > doesn't strike me as a nice solution as Python offers in so many other > places. > > However, I am willing to concede that as the issue has been dormant (or > appears to be) now for ~2years that it can not be a particularly burning > issue. So I'll go back and trawl the open issues for something else to help > my favourite language get better :-) > > > Andy > - > Brain chemistry is not just for Christmas > > [snipped the replies to cut down on re-quote spam - cos I kind of hate that] > > > > > Get fish-slapping on Messenger! Play Now ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asser ts vs. failIf/Unlesses
Steve Holden holdenweb.com> writes: > But Guido said: > > > I like using only the assertKeyword variants, removing assert_, fail*, > > and assertEquals. > > So we are now no longer discussing what color to paint the bike shed, we > are discussing how to describe the color. Let's stop. This is getting silly. It's certainly getting silly - the language is named Python after all! However, the whole thread started by someone opposing Guido's statement above, which at least explains (if not justifies) the origins of this particular instance of silliness... (and I've probably made my point explicitly enough, so I won't insist, even if I sometimes enjoy arguing on my spare time ;-)) cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unquote - Unicode issues
> Ah there may be some confusion here. We're only dealing with str->str > transformations (which in Python 3 means Unicode strings). You can't put a > bytes in or get a bytes out of either of these functions. I suggested a > "quote_raw" and "unquote_raw" function which would let you do this. Ah, well, that's a problem. Clearly the unquote is str->bytes, while the quote is (bytes OR str)->str. You can't pass a Unicode string back as the result of unquote *without* passing in an encoding specifier, because the character set is application-specific. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Exception tracebacks
I do not know where cleanup_traceback (in run.py) is called, or really anything about the inner workings of python, but there is a problem with sys.tracebacklimit. If it is set to one or zero, "** IDLE Internal Exception" is printed in the traceback for any exception, not internal ones. I think tracebacklimit is applied to the traceback before cleanup_traceback is called, but should be applied after. I imagine the solution is not that simple, and you may already be aware of the problem, but thanks anyway. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception tracebacks
On Sun, Jul 13, 2008, Tom Mullins wrote: > > I do not know where cleanup_traceback (in run.py) is called, or really > anything about the inner workings of python, but there is a problem with > sys.tracebacklimit. If it is set to one or zero, "** IDLE Internal > Exception" is printed in the traceback for any exception, not internal ones. > I think tracebacklimit is applied to the traceback before cleanup_traceback > is called, but should be applied after. I imagine the solution is not that > simple, and you may already be aware of the problem, but thanks anyway. If you care about this issue, please file a report at bugs.python.org -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ I support the RKAB ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AMD64-W2k8 buildbot wedged
Martin v. Löwis wrote: Nick Coghlan wrote: The number of 64-bit safeness warnings being emitted by the current trunk is also fairly worrying) Do you have a specific one in mind? The ones truncating size_t/ssize_t should only matter when you actually do have data larger than 2GiB. Nothing specific, I just don't think I've ever actually looked at the output of a 64-bit build before and was a little surprised at the number of such warnings. I guess they were mostly in modules which are probably going to struggle with handling 2+ GiB chunks of data anyway. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8 conformance of unittest (was: unittest's redundant assertions: asserts vs. failIf/Unlesses)
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Same here; let's tread carefully here and not change this with 3.0.
> Starting to deprecate in 3.1 and killing in 3.3 would be soon enough.
> I like using only the assertKeyword variants, removing assert_, fail*,
> and assertEquals.
Are we to interpret the above ("… using only the assertKeyword
variants, removing assert_, …") as "we should actively remove names
that are PEP 8 compatible from 'unittest', instead preferring names
that go against PEP 8?
I really hope I'm misinterpreting this and that there's another
explanation. Preferably one that includes "we have a plan to make
'unittest' conform with the existing PEP 8".
--
\“Pinky, are you pondering what I'm pondering?” “Umm, I think |
`\ so, Brain, but three men in a tub? Ooh, that's unsanitary!” |
_o__) —_Pinky and The Brain_ |
Ben Finney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 conformance of unittest
Ben Finney wrote:
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
Same here; let's tread carefully here and not change this with 3.0.
Starting to deprecate in 3.1 and killing in 3.3 would be soon enough.
I like using only the assertKeyword variants, removing assert_, fail*,
and assertEquals.
Are we to interpret the above ("… using only the assertKeyword
variants, removing assert_, …") as "we should actively remove names
that are PEP 8 compatible from 'unittest', instead preferring names
that go against PEP 8?
I really hope I'm misinterpreting this and that there's another
explanation. Preferably one that includes "we have a plan to make
'unittest' conform with the existing PEP 8".
"we have a plan to make 'unittest' conform with the existing PEP 8" -
that was the outcome of the discussion. PEP 8'ification to begin in 2.7
/ 3.1 with the deprecation of non-PEP8 compliant method names.
There was some added functionality discussed, but it is too late to get
this into 2.6 / 3.0.
I volunteered to take it on, and have a record of the whole discussion.
Unfortunately my writing commitment is going to keep me occupied until
August - after which it will be one of my highest priorities.
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 conformance of unittest
Michael Foord <[EMAIL PROTECTED]> writes: > "we have a plan to make 'unittest' conform with the existing PEP 8" > - that was the outcome of the discussion. PEP 8'ification to begin > in 2.7 / 3.1 with the deprecation of non-PEP8 compliant method > names. Thanks, that's exactly the reassurance I was hoping for :-) > I volunteered to take it on, and have a record of the whole > discussion. Unfortunately my writing commitment is going to keep me > occupied until August - after which it will be one of my highest > priorities. I've contacted you yesterday regarding this, but to reiterate: This issue is of interest to me, and I'd like to help with it if I can. Please contact me privately if I can be of assistance, especially if I can help during your busy period. -- \ “The trouble with the rat race is that even if you win, you're | `\ still a rat.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Ben Finney wrote: Howdy Michael, I'm interested in the changes you're proposing for Python's 'unittest' module. I am (like, I suspect, many Python coders) maintaining my own set of extensions to the module across many projects, so I'd really like to see many of the improvements you discuss actually in the standard library. What assistance can I offer to help on this issue? I intend to start working on them in August, after I have finished my current writing commitments. The full list of changes proposed (feel free to start - but ping me or the list) and not shot down was something like: Documenting that the assert method names are to be preferred over the 'FailUnless' names (this stirred up some controversy this weekend so should probably not happen). Adding the following new asserts: assertIn(member, container, msg=None) assertNotIn (member, container, msg=None) assertIs (first, second, msg=None) assertNotIs (first, second, msg=None) assertRaisesWithMessage(exc_class, message, callable, *args, **keywargs) A simple 'RunTests' function that takes a collection of modules, test suites or test cases and runs them with TextTestRunner - passing on keyword arguments to the test runner. This makes running a test suite easier - once you have collected all your test cases together you can just pass them to this function so long as you are happy with the default runner (possibly allowing an alternative runner class to be provided as a keyword argument). Make the error messages for "assertEquals" and "assertNotEquals" more useful - showing the objects that compare incorrectly even if an explicit message is passed in. Additionally, when comparing lists and tuples that are the same length show the members (and indices?) that were different. Possibly even providing a diff in the case of comparing strings (we have an implementation of this at work). assertLessThan assertGreaterThan assertLessThanOrEquals assertGreaterThanOrEquals Guido suggested various variants on assertEquals: assertListEqual(self, list1, list2, msg=None): assertDictEqual(self, d1, d2, msg=None): assertMultiLineEqual(self, first, second, msg=Non In my opinion these can all be provided by improving the messages from assertEquals and don't require new methods. assertSameElements(self, expected_seq, actual_seq, msg=None): I usually achieve this with: assertEquals(set(actual), set(expected)) A convenience method might be nice, but I'm worried about the API growing in an unbounded way. Other suggestions that weren't controversial but I might not get to: assertRaisesWithMessage taking a regex to match the error message expect methods that collect failures and report at the end of the test (allowing an individual test method to raise several errors without stopping) assertIsInstance and assertIsSubclass Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Michael Foord <[EMAIL PROTECTED]> writes: > Adding the following new asserts: > >assertIn(member, container, msg=None) >assertNotIn (member, container, msg=None) >assertIs (first, second, msg=None) >assertNotIs (first, second, msg=None) >assertRaisesWithMessage(exc_class, message, callable, *args, > **keywargs) […] >assertLessThan >assertGreaterThan >assertLessThanOrEquals >assertGreaterThanOrEquals […] >assertListEqual(self, list1, list2, msg=None): >assertDictEqual(self, d1, d2, msg=None): >assertMultiLineEqual(self, first, second, msg=Non […] >assertSameElements(self, expected_seq, actual_seq, msg=None): All these are new, so there is no existing expectation of these names from users of the standard library 'unittest' module (i.e. no backward-compatibility concern since these are new methods). If we're planning to deprecate the existing non-PEP-8 names in 2.7 and 3.1, why would we introduce new names that are non-PEP-8? Wouldn't it be better to add these as PEP-8 compatible names in the first instance? -- \ “You've got the brain of a four-year-old boy, and I'll bet he | `\ was glad to get rid of it.” —Groucho Marx | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Michael Foord wrote: Ben Finney wrote: Howdy Michael, I'm interested in the changes you're proposing for Python's 'unittest' module. I am (like, I suspect, many Python coders) maintaining my own set of extensions to the module across many projects, so I'd really like to see many of the improvements you discuss actually in the standard library. What assistance can I offer to help on this issue? I intend to start working on them in August, after I have finished my current writing commitments. The full list of changes proposed (feel free to start - but ping me or the list) and not shot down was something like: Documenting that the assert method names are to be preferred over the 'FailUnless' names (this stirred up some controversy this weekend so should probably not happen). Adding the following new asserts: assertIn(member, container, msg=None) assertNotIn (member, container, msg=None) assertIs (first, second, msg=None) assertNotIs (first, second, msg=None) Please, let's call this one "assertIsNot". I know it's valid Python to say if a not is b: but it's a much less natural way of expressing the condition, and (for all I know) might even introduce an extra negation operation. "is not" is, I believe, treated as a single operator. > [...] regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Steve Holden writes: > "Fail" isn't a negative. As Guido said, it's a description of the test > behavior under particular circumstances. This is not true, however. "Fail" is a description of a potentailly very large class of behaviors. Knowing that the test failed does not tell you which of the failure behaviors occurred, only that the success behavior did not occur. The analogy to the fact that True != not not 10 is telling, I think. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Mon, 14 Jul 2008 04:19:57 am Mark Hammond wrote: > try to stick to the issue at hand I'm sorry, did I reply to the wrong message? I thought this was part of a thread titled "unittest's redundant assertions: asserts vs. failIf/Unlesses". What *is* the issue at hand if not the question of positive assertions versus fail if/unless? > As Steve said, this is getting silly... It certainly is. Python may be Guido's language, and if he wants to use his dictatorial powers to say that tests must be written as positive assertions because that's the way he likes it, that's his prerogative. But let's not pretend that this particular bike shed colour has any objectively rational reason, or that the change won't force some people to have to change the way they think about tests. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Steven D'Aprano wrote: On Mon, 14 Jul 2008 04:19:57 am Mark Hammond wrote: try to stick to the issue at hand I'm sorry, did I reply to the wrong message? I thought this was part of a thread titled "unittest's redundant assertions: asserts vs. failIf/Unlesses". What *is* the issue at hand if not the question of positive assertions versus fail if/unless? As Steve said, this is getting silly... It certainly is. Python may be Guido's language, and if he wants to use his dictatorial powers to say that tests must be written as positive assertions because that's the way he likes it, that's his prerogative. But let's not pretend that this particular bike shed colour has any objectively rational reason, or that the change won't force some people to have to change the way they think about tests. But sometimes even the wrong decision is better than no decision, and I suspect most if us can agree that it's better if everyone thinks about tests the same way. Otherwise test code is difficult to understand for some of its user population. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Steve Holden <[EMAIL PROTECTED]> writes: > Michael Foord wrote: > > Adding the following new asserts: > > > >assertIn(member, container, msg=None) > >assertNotIn (member, container, msg=None) > >assertIs (first, second, msg=None) > >assertNotIs (first, second, msg=None) > > Please, let's call this one "assertIsNot". I know it's valid Python > to say > > if a not is b: > > but it's a much less natural way of expressing the condition, and > (for all I know) might even introduce an extra negation operation. > "is not" is, I believe, treated as a single operator. Dang. You're exactly right. The problem is, that makes it quite inconsistent with other "not" uses (such as "assert_not_equal", "assert_not_in", etc.) I would really prefer that all these "not" uses be gramatically consistent for predictability. Is this a case where "assert_is_not" should exist alongside "assert_not_is"? I know that part of the goal here is to have "preferably only one obvious way to do it", but I can see *both* those names as "the obvious way to do it". Is this an instance where the "preferably" clause must be exercised in the negative? -- \“Every sentence I utter must be understood not as an | `\ affirmation, but as a question.” —Niels Bohr | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
* Stephen J. Turnbull <[EMAIL PROTECTED]> [2008-07-14 08:51:27 +0900]: > The analogy to the fact that True != not not 10 is telling, I think. What? >>> True == (not not 10) True -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
[Michael Foord] >> ... >> Adding the following new asserts: >> >> ... >> assertNotIs (first, second, msg=None) [Steve Holden] > Please, let's call this one "assertIsNot". +1 > I know it's valid Python to say > > if a not is b: Nope, that's a syntax error. > but it's a much less natural way of expressing the condition, and (for all I > know) might even introduce an extra negation operation. "is not" is, I > believe, treated as a single operator. "is not" and "not in" are both binary infix operators, not to be confused with the distinct use of "not" on its own as a unary prefix operator. "not is" and "in not" are both gibberish. >>> 1 is not 2 True >>> 1 is (not 2) False >>> 1 not is 2 SyntaxError: invalid syntax >>> 1 not in [2] True >>> 1 in not [2] SyntaxError: invalid syntax >>> 1 in (not [2]) Traceback (most recent call last): ... TypeError: argument of type 'bool' is not iterable ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
On Sun, 13 Jul 2008 23:51:44 +0100, Michael Foord <[EMAIL PROTECTED]> wrote: Ben Finney wrote: Howdy Michael, I'm interested in the changes you're proposing for Python's 'unittest' module. I am (like, I suspect, many Python coders) maintaining my own set of extensions to the module across many projects, so I'd really like to see many of the improvements you discuss actually in the standard library. What assistance can I offer to help on this issue? I intend to start working on them in August, after I have finished my current writing commitments. The full list of changes proposed (feel free to start - but ping me or the list) and not shot down was something like: Documenting that the assert method names are to be preferred over the 'FailUnless' names (this stirred up some controversy this weekend so should probably not happen). Adding the following new asserts: assertIn(member, container, msg=None) assertNotIn (member, container, msg=None) assertIs (first, second, msg=None) assertNotIs (first, second, msg=None) assertRaisesWithMessage(exc_class, message, callable, *args, **keywargs) Several of these are implemented in other libraries (Twisted, at least). You might save some time by grabbing them and their unit tests, rather than re-implementing them. Twisted calls `assertIs´ `assertIdentical´, by the way. [snip] Other suggestions that weren't controversial but I might not get to: assertRaisesWithMessage taking a regex to match the error message Actually, I remember that someone raised an object to this as being not as flexible as some might want - an objection I agree with. Perhaps that was overruled, but I didn't want this to slip by as "not controversial". expect methods that collect failures and report at the end of the test (allowing an individual test method to raise several errors without stopping) assertIsInstance and assertIsSubclass The former of these is also in Twisted already, if you want to copy it. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed unittest changes
Tim Peters wrote: [Michael Foord] ... Adding the following new asserts: ... assertNotIs (first, second, msg=None) [Steve Holden] Please, let's call this one "assertIsNot". +1 I know it's valid Python to say if a not is b: Nope, that's a syntax error. Rats, naturally I was thinking of "if not (a is b):" but it's a much less natural way of expressing the condition, and (for all I know) might even introduce an extra negation operation. "is not" is, I believe, treated as a single operator. "is not" and "not in" are both binary infix operators, not to be confused with the distinct use of "not" on its own as a unary prefix operator. "not is" and "in not" are both gibberish. 1 is not 2 True 1 is (not 2) False 1 not is 2 SyntaxError: invalid syntax 1 not in [2] True 1 in not [2] SyntaxError: invalid syntax 1 in (not [2]) Traceback (most recent call last): ... TypeError: argument of type 'bool' is not iterable regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Ben Finney wrote: That's another reason to avoid "assert" in the name: these methods *don't* necessarily use the 'assert' statement. Avoiding the implication that they do use that is a good thing. Perhaps some positive alternative such as "verify" could be used instead. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Steve Holden wrote: "Fail" isn't a negative. That depends on what you're trying to find out by reading the code. If you're trying to find out under what conditions the test succeeds, then it succeeds if it doesn't fail, so you have a negative. Whichever convention is chosen, there will be situations in which you want to mentally negate it. If you start with a positive, the mental negation produces a single negative. If you start with a negative, the mental negation produces a double negative. Therefore it is less confusing overall to start with as few negatives as possible. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unquote - Unicode issues
On Mon, Jul 14, 2008 at 4:54 AM, André Malo <[EMAIL PROTECTED]> wrote:
>
> Ahem. The HTTP standard does ;-)
>
Really? Can you include a quotation please? The HTTP standard talks a lot
about ISO-8859-1 (Latin-1) in terms of actually raw encoded bytes, but not
in terms of URI percent-encoding (a different issue) as far as I can tell.
>
> > Where web forms are concerned, basically setting the form accept-charset
> > or the page charset is the *maximum amount* of control you have over the
> > encoding. As you say, it can be encoded by another page or the user can
> > override their settings. Then what can you do as the server? Nothing ...
>
> Guessing works pretty well in most of the cases.
>
Are you suggesting that urllib.unquote guess the encoding? It could do that
but it would make things rather unpredictable. I think if this was an
application (such as a web browser), then guessing is OK. But this is a
library function. Library functions should not make arbitrary decisions;
they should be well-specified.
Latin-1 is not exactly arbitray. Besides being a charset - it maps
> one-to-one to octet values, hence it's commonly used to encode octets and
> is therefore a better fallback than every other encoding.
>
True. So the only advantage I see to the current implementation is that if
you really want to, you can take the Latin-1-decoded URI (from unquote) and
explicitly encode it as Latin-1 and then decode it again as whatever
encoding you want. But that would be a hack, would it not? I'd prefer if the
library didn't require a hack just to get the extremely common use case
(UTF-8).
>
> > I agree. However if there *was* a proper standard we wouldn't have to
> > argue! "Most proper" and "should do" is the most confident we can be when
> > dealing with this standard, as there is no correct encoding.
>
> Well, the standard says, there are octets to be encoded. I find that proper
> enough.
Yes but unfortunately we aren't talking about octets any more in Python 3,
but characters. If we're going to follow the standard and encode octets,
then we should be accepting (for quote) and returning (for unquote) bytes
objects, not strings. But as that's going to break most existing code and be
extremely confusing, I think it's best we try and solve this problem for
Unicode strings.
> > Does anyone have a suggestion which will be more compatible with the rest
> > of the world than allowing the user to select an encoding, and defaulting
> > to "utf-8"?
>
> Default to latin-1 for decoding and utf-8 for encoding. This might be
> confusing though, so maybe you've asked the wrong question ;)
>
:o that would break so so much existing code, not to mention being horribly
inconsistent and confusing. Having said that, that's almost what the current
behaviour is (quote uses Latin-1 for characters < 256, and UTF-8 for
characters above; unquote uses Latin-1).
Again I bring up the http server example. If you go to a directory, create a
file with a name such as '漢字', and then run this code in Python 3.0 from
that directory:
import http.server
s = http.server.HTTPServer(('',8000),
http.server.SimpleHTTPRequestHandler)
s.serve_forever()
You'll see the file in the directory listing - its HTML will be 漢字. But if you click it, you get a 404 because
the server will look for the file named unquote("%E6%BC%A2%E5%AD%97") =
'æ¼¢å\xad\x97'.
If you apply my patch (patch5) *everything* *just* *works*.
On Mon, Jul 14, 2008 at 6:36 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Ah there may be some confusion here. We're only dealing with str->str
> > transformations (which in Python 3 means Unicode strings). You can't put
> a
> > bytes in or get a bytes out of either of these functions. I suggested a
> > "quote_raw" and "unquote_raw" function which would let you do this.
>
> Ah, well, that's a problem. Clearly the unquote is str->bytes, while
> the quote is (bytes OR str)->str.
>
OK so for quote, you're suggesting that we accept either a bytes or a str
object. That sounds quite reasonable (though neither the unpatched or
patched versions accept a bytes at the moment). I'd simply change the code
in quote (from patch5) to do this:
if isinstance(s, str):
s = s.encode(encoding, errors)
res = map(quoter, s)
Now you get this behaviour by default (which may appear confusing but I'd
argue correct given the different semantics of 'h\xfcllo' and b'h\xfcllo'):
>>> urllib.parse.quote(b'h\xfcllo')
'h%FCllo' # Directly-encoded octets
>>> urllib.parse.quote('h\xfcllo')
'h%C3%BCllo' # UTF-8 encoded string, then encoded octets
Clearly the unquote is str->bytes, You can't pass a Unicode string
> back
> as the result of unquote *without* passing in an encoding specifier,
> because the character set is application-specific.
>
So for unquote you're suggesting that it always return a bytes object UNLESS
an encoding is specified? As in:
>>> urllib.parse.unquote('h%C3%BCllo')
b'h\xc3\xbcllo'
I would object to that on tw
Re: [Python-Dev] AMD64-W2k8 buildbot wedged
On Sun, Jul 13, 2008 at 6:35 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: >> The compilation step on this buildbot is failing because it can't delete >> or overwrite any of the Python DLLs [1]. Is there any way to fix this >> remotely, or at least to tell why kill_python isn't doing the trick? > > That is in the log: > > TerminateProcess failed: 5 > > where 5 is ERROR_ACCESS_DENIED. Now, *why* the system is refusing to > terminate the process is difficult to say. It's a general Windows > problem: the system doesn't support forced process termination in a > reliable manner. > > In any case, Trent seems to have fixed the problem. > >> The number of 64-bit safeness >> warnings being emitted by the current trunk is also fairly worrying) > > Do you have a specific one in mind? The ones truncating size_t/ssize_t > should only matter when you actually do have data larger than 2GiB. > http://bugs.python.org/issue3026 comes to mind. And I would rather use a little bit different wording: The ones truncating size_t/ssize_t do matter, unless you know in advance that you will always deal with data lesser than 2GiB. Regards, - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AMD64-W2k8 buildbot wedged
> http://bugs.python.org/issue3026 comes to mind. > > And I would rather use a little bit different wording: The ones > truncating size_t/ssize_t do matter, unless you know in advance that > you will always deal with data lesser than 2GiB. I thought Nick's comment was in the context of the buildbots hanging in the multiprocessing tests, which I know has only data smaller than 2GiB. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Tristan Seligmann writes: > * Stephen J. Turnbull <[EMAIL PROTECTED]> [2008-07-14 08:51:27 +0900]: > > > The analogy to the fact that True != not not 10 is telling, I think. > > What? > > >>> True == (not not 10) > True FWIW, I meant 10 != not not 10. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
