On 02/10/16 02:46, boB Stepp wrote:
>> case. If I know that the result is always an int I can
>> use the first case if I know its always a tuple I can
>> use the second. But not knowing which is just plain
>> messy.
>
> So in which sorts of scenarios would you use argument unpacking?
Any time a
On Sat, Oct 1, 2016 at 7:19 PM, Alan Gauld via Tutor wrote:
> On 01/10/16 23:08, boB Stepp wrote:
>> On Sat, Oct 1, 2016 at 11:35 AM, Alan Gauld via Tutor
>> wrote:
>>
>>> ... Personally I don't like functions that
>>> sometimes return one and sometimes two results. I'd rather
>>> you returned a
On 01/10/16 23:08, boB Stepp wrote:
> On Sat, Oct 1, 2016 at 11:35 AM, Alan Gauld via Tutor
> wrote:
>
>> ... Personally I don't like functions that
>> sometimes return one and sometimes two results. I'd rather
>> you returned a None first argument in the first case
>> to make it consistent.
>
On Sat, Oct 1, 2016 at 11:35 AM, Alan Gauld via Tutor wrote:
> ... Personally I don't like functions that
> sometimes return one and sometimes two results. I'd rather
> you returned a None first argument in the first case
> to make it consistent.
Why don't you like doing this? What are the plus
On 01/10/16 16:12, boB Stepp wrote:
>>> This module will take a string and right justify it so that the last
>>> character
>>> of the line will fall in column 70 of the display. The results will be
>>> printed to stdout.'''
>>>
>> Do you need print_msgs()?
>> Won't it work the same with
>>
>>
On Sat, Oct 1, 2016 at 2:02 AM, Alan Gauld via Tutor wrote:
> Do you need print_msgs()?
> Won't it work the same with
>
>print(right_justify(input_string))
>
> You are only feeding one line at a time into the print msgs.
>
> You could do it all in a new print_msgs() like:
>
> def prin
On Sat, Oct 1, 2016 at 2:02 AM, Alan Gauld via Tutor wrote:
> On 01/10/16 05:24, boB Stepp wrote:
>
>> ===
>> '''Exerise 3.1 from "Think Python 2" by Allen Downey.
>>
>> This module will take a string and right justify it
On 01/10/16 05:24, boB Stepp wrote:
> ===
> '''Exerise 3.1 from "Think Python 2" by Allen Downey.
>
> This module will take a string and right justify it so that the last character
> of the line will fall in column 70 of
On Sat, Oct 1, 2016 at 12:12 AM, Richard Doksa wrote:
> unsubscibe please
If you wish to unsubscribe, go to the bottom of this page and follow
its instructions:
https://mail.python.org/mailman/listinfo/tutor
boB
___
Tutor maillist - Tutor@python.or
On Fri, Sep 30, 2016 at 5:07 AM, Steven D'Aprano wrote:
[snip]
> and preferably three:
>
> (1) function that does the calculation;
> (2) function that does the output;
> (3) function that calls (1) and then (2)
>
>
> If (1) and (2) are well-designed, then (3) is so trivial it needs no
> tests:
>
On Fri, Sep 30, 2016 at 5:07 AM, Steven D'Aprano wrote:
> On Thu, Sep 29, 2016 at 09:24:51PM -0500, boB Stepp wrote:
>> Second, it seems that prints are often intermingled with the main
>> logic of a function and only serve to pass on a message to the user.
>
> Yeah, you normally shouldn't do tha
On Thu, Sep 29, 2016 at 09:24:51PM -0500, boB Stepp wrote:
> Testing output of print functions (Py 3). First off, is it worth it to do so?
Unless you are writing tests for the Python language itself, you can
assume that print() itself is working.
You should test functions that call print: call
Testing output of print functions (Py 3). First off, is it worth it to do so?
Second, it seems that prints are often intermingled with the main
logic of a function and only serve to pass on a message to the user.
For example, in an earlier thread (
Questions as to how to run the same unit test m
13 matches
Mail list logo
