On 05/18/2016 05:43 PM, Steven D'Aprano wrote:
On Thu, 19 May 2016 09:30 am, Ethan Furman wrote:
On 05/18/2016 03:52 PM, Gregory Ewing wrote:
Ned Batchelder wrote:
I'm not sure how
the test runner could determine that it was empty. I guess it could
introspect the test function to see if it
On Thu, 19 May 2016 09:30 am, Ethan Furman wrote:
> On 05/18/2016 03:52 PM, Gregory Ewing wrote:
>> Ned Batchelder wrote:
>
>>> I'm not sure how
>>> the test runner could determine that it was empty. I guess it could
>>> introspect the test function to see if it had any real code in it,
>>
>> Th
On 05/18/2016 03:52 PM, Gregory Ewing wrote:
Ned Batchelder wrote:
I'm not sure how
the test runner could determine that it was empty. I guess it could
introspect the test function to see if it had any real code in it,
Then people would just get clever at putting dummy code
in the test that
Ned Batchelder wrote:
I'm not sure how
the test runner could determine that it was empty. I guess it could
introspect the test function to see if it had any real code in it,
Then people would just get clever at putting dummy code
in the test that fools the test runner but doesn't really
test a
On Thu, 19 May 2016 02:05 am, Ethan Furman wrote:
> On 05/18/2016 08:35 AM, Thomas Mlynarczyk wrote:
>> On 18/05/16 17:21, Ned Batchelder wrote:
>
>>> Ideally, an empty test wouldn't be a success, but I'm not sure how
>>> the test runner could determine that it was empty. I guess it could
>>> in
On 05/18/2016 08:35 AM, Thomas Mlynarczyk wrote:
On 18/05/16 17:21, Ned Batchelder wrote:
Ideally, an empty test wouldn't be a success, but I'm not sure how
the test runner could determine that it was empty. I guess it could
introspect the test function to see if it had any real code in it,
b
On Wednesday, May 18, 2016 at 11:36:03 AM UTC-4, Thomas Mlynarczyk wrote:
> On 18/05/16 17:21, Ned Batchelder wrote:
> > Ideally, an empty test wouldn't be a success, but I'm not sure how
> > the test runner could determine that it was empty. I guess it could
> > introspect the test function to se
On 18/05/16 17:21, Ned Batchelder wrote:
> Ideally, an empty test wouldn't be a success, but I'm not sure how
> the test runner could determine that it was empty. I guess it could
> introspect the test function to see if it had any real code in it,
> but I don't know of a test runner that does tha
On Wednesday, May 18, 2016 at 8:06:11 AM UTC-4, Thomas Mlynarczyk wrote:
> On 17/05/16 12:39, Cem Karan wrote:
> > Just downloaded and used a library that came with unit tests, which all
> > passed.
> > [...]
> > I discovered they had commented out the bodies of some of the unit
> tests...
>
> Sh
On Wed, May 18, 2016 at 10:05 PM, Thomas Mlynarczyk
wrote:
> On 17/05/16 12:39, Cem Karan wrote:
>> Just downloaded and used a library that came with unit tests, which all
>> passed.
>> [...]
>> I discovered they had commented out the bodies of some of the unit
> tests...
>
> Shouldn't the unit t
On 17/05/16 12:39, Cem Karan wrote:
> Just downloaded and used a library that came with unit tests, which all
> passed.
> [...]
> I discovered they had commented out the bodies of some of the unit
tests...
Shouldn't the unit test framework have those "empty" tests reported as
"todo"/"incomplete"
Michael Torrie :
> On 05/17/2016 08:27 AM, Paul Rudin wrote:
>> Marko Rauhamaa writes:
>>> That's a long time to be without a product to sell.
>>
>> But you do have the option of building a kernel incorporating your fix
>> and using that.
>
> Sure as an individual end user that may be the best o
On 05/17/2016 08:27 AM, Paul Rudin wrote:
> Marko Rauhamaa writes:
>> That's a long time to be without a product to sell.
>
> But you do have the option of building a kernel incorporating your fix
> and using that.
Sure as an individual end user that may be the best option. But not
necessarily f
Marko Rauhamaa writes:
> Paul Rudin :
>
>> Marko Rauhamaa writes:
>>> The feeling of powerlessness can be crushing when you depend on a
>>> third-party component that is broken with no fix in sight.
>>
>> Presumably it depends on whether you have the source for the third
>> party component...
>
Paul Rudin :
> Marko Rauhamaa writes:
>> The feeling of powerlessness can be crushing when you depend on a
>> third-party component that is broken with no fix in sight.
>
> Presumably it depends on whether you have the source for the third
> party component...
Just having such an experience. The
On Tue, May 17, 2016 at 7:54 PM, Paul Rudin wrote:
>> Also:
>>
>>With a third party solution I don't need to fix the bugs.
>>
>>But with an in-house solution I at least *can* fix the bugs.
>>
>> The feeling of powerlessness can be crushing when you depend on a
>> third-party component that
On May 17, 2016, at 4:30 AM, Marko Rauhamaa wrote:
> Radek Holý :
>
>> 2016-05-17 9:50 GMT+02:00 Steven D'Aprano <
>> steve+comp.lang.pyt...@pearwood.info>:
>>
>>> Overhead in the office today:
>>>
>>> "I don't have time to learn an existing library - much faster to make
>>> my own mistakes!"
Marko Rauhamaa writes:
> Radek Holý :
>
>> 2016-05-17 9:50 GMT+02:00 Steven D'Aprano <
>> steve+comp.lang.pyt...@pearwood.info>:
>>
>>> Overhead in the office today:
>>>
>>> "I don't have time to learn an existing library - much faster to make
>>> my own mistakes!"
>>
>> *THUMBS UP* At least they
But isn't that counter wise to batteries included? :)
On Tue, May 17, 2016 at 11:30 AM, Marko Rauhamaa wrote:
> Radek Holý :
>
> > 2016-05-17 9:50 GMT+02:00 Steven D'Aprano <
> > steve+comp.lang.pyt...@pearwood.info>:
> >
> >> Overhead in the office today:
> >>
> >> "I don't have time to learn a
Radek Holý :
> 2016-05-17 9:50 GMT+02:00 Steven D'Aprano <
> steve+comp.lang.pyt...@pearwood.info>:
>
>> Overhead in the office today:
>>
>> "I don't have time to learn an existing library - much faster to make
>> my own mistakes!"
>
> *THUMBS UP* At least they are aware of that "own mistakes" par
2016-05-17 9:50 GMT+02:00 Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info>:
> Overhead in the office today:
>
>
> "I don't have time to learn an existing library - much faster to make my
> own
> mistakes!"
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
*
Overhead in the office today:
"I don't have time to learn an existing library - much faster to make my own
mistakes!"
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
22 matches
Mail list logo
