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.
_
> 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 build
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 i
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 di
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 sit
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
__
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 think
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 man
[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 wa
* 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
__
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=Non
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
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
p
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
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 impro
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
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 ac
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 w
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.
"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 inter
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 spe
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 tracebac
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 tra
> 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, w
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 i
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 S
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* n
* 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 specif
> 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
> 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 maili
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
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
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 (
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
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
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
somethin
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 "fai
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@p
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
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
behavio
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
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 th
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
sta
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. Wi
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 fo
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 func
"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
47 matches
Mail list logo
