Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87953 > unrolled thread

Supply condition in function call

Back to article view | Back to comp.lang.python

Contents

  Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-25 18:29 +0100
    Re: Supply condition in function call Joel Goldstick <joel.goldstick@gmail.com> - 2015-03-25 13:41 -0400
      Re: Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-25 18:51 +0100
        Re: Supply condition in function call Joel Goldstick <joel.goldstick@gmail.com> - 2015-03-25 14:17 -0400
        Re: Supply condition in function call Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-25 12:22 -0600
        Re: Supply condition in function call Joel Goldstick <joel.goldstick@gmail.com> - 2015-03-25 14:42 -0400
    Re: Supply condition in function call Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-25 11:44 -0600
      Re: Supply condition in function call Grant Edwards <invalid@invalid.invalid> - 2015-03-25 19:53 +0000
        Re: Supply condition in function call Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-25 14:49 -0600
          Re: Supply condition in function call Grant Edwards <invalid@invalid.invalid> - 2015-03-26 15:41 +0000
    Re: Supply condition in function call Terry Reedy <tjreedy@udel.edu> - 2015-03-25 14:50 -0400
    Re: Supply condition in function call Gary Herron <gherron@digipen.edu> - 2015-03-25 12:13 -0700
      Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-25 21:02 -0700
        Re: Supply condition in function call Chris Angelico <rosuav@gmail.com> - 2015-03-26 17:00 +1100
          Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-26 18:41 -0700
            Re: Supply condition in function call Chris Angelico <rosuav@gmail.com> - 2015-03-27 12:56 +1100
              Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-26 19:21 -0700
                Re: Supply condition in function call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-27 15:34 +1100
                  Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-27 06:48 -0700
                    Re: Supply condition in function call Chris Angelico <rosuav@gmail.com> - 2015-03-28 01:17 +1100
                    Re: Supply condition in function call Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-27 16:00 +0000
                    Re: Supply condition in function call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 18:32 +1100
                      Re: Supply condition in function call Chris Angelico <rosuav@gmail.com> - 2015-03-28 18:45 +1100
              Re: Supply condition in function call Larry Hudson <orgnut@yahoo.com> - 2015-03-27 17:26 -0700
                Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-27 18:27 -0700
                Re: Supply condition in function call Marko Rauhamaa <marko@pacujo.net> - 2015-03-28 09:50 +0200
                  Re: Supply condition in function call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 20:17 +1100
                  Re: Supply condition in function call Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-28 03:19 -0600
                    Re: Supply condition in function call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 20:57 +1100
                      Re: Supply condition in function call Cameron Simpson <cs@zip.com.au> - 2015-03-30 09:35 +1100
                        Re: Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-30 00:46 +0200
            Re: Supply condition in function call Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-26 20:25 -0600
              Re: Supply condition in function call Rustom Mody <rustompmody@gmail.com> - 2015-03-26 19:46 -0700
      Re: Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-26 07:27 +0100
        Re: Supply condition in function call Cameron Simpson <cs@zip.com.au> - 2015-03-26 18:06 +1100
          Re: Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-27 21:02 +0100
            Re: Supply condition in function call Cameron Simpson <cs@zip.com.au> - 2015-03-28 09:55 +1100
        Re: Supply condition in function call Peter Otten <__peter__@web.de> - 2015-03-26 10:03 +0100
          Re: Supply condition in function call Manuel Graune <manuel.graune@koeln.de> - 2015-03-27 20:46 +0100
            Re: Supply condition in function call Peter Otten <__peter__@web.de> - 2015-03-27 21:38 +0100
    Re: Supply condition in function call smap <askme.first@thankyouverymuch.invalid> - 2015-03-28 08:58 +0000

Page 1 of 3  [1] 2 3  Next page →

#87953 — Supply condition in function call

Hi,

I'm looking for a way to supply a condition to an if-statement inside a
function body when calling the function. I can sort of get what I want
with using eval (see code below) but I would like to achieve this in a
safer way. If there is a solution which is safer while being
less flexible, that would be fine. Also, supplying the condition as a
string is not necessary. What I want to do is basically like this:

def test1(a, b, condition="True"):
    for i,j in zip(a,b):
        c=i+j
        if eval(condition):
           print("Foo")

test1([0,1,2,3],[1,2,3,4],"i+j >4")
print("Bar")
test1([0,1,2,3],[1,2,3,4],"c >4")
print("Bar")
test1([0,1,2,3],[1,2,3,4],"a[i] >2")
print("Bar")
test1([0,1,2,3],[1,2,3,4])

Resulting in

Foo
Foo
Bar
Foo
Foo
Bar
Foo
Bar
Foo
Foo
Foo
Foo

Thanks for your help

Regards,

Manuel

-- 
A hundred men did the rational thing. The sum of those rational choices was
called panic. Neal Stephenson -- System of the world
http://www.graune.org/GnuPG_pubkey.asc
Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A  5828 5476 7E92 2DB4 3C99

[toc] | [next] | [standalone]

#87954

On Wed, Mar 25, 2015 at 1:29 PM, Manuel Graune <manuel.graune@koeln.de> wrote:
> Hi,
>
> I'm looking for a way to supply a condition to an if-statement inside a
> function body when calling the function. I can sort of get what I want
> with using eval (see code below) but I would like to achieve this in a
> safer way. If there is a solution which is safer while being
> less flexible, that would be fine. Also, supplying the condition as a
> string is not necessary. What I want to do is basically like this:
>
> def test1(a, b, condition="True"):
>     for i,j in zip(a,b):
>         c=i+j
>         if eval(condition):
>            print("Foo")
>
I'm not sure I understand your question, but condition will evaluate
to True or False regardless, so:
         if condition:
            print ("Foo")
         else:
            print ("Bar")

eval can be dangerous as someone could put some unknown command with
side effects in condition

> test1([0,1,2,3],[1,2,3,4],"i+j >4")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4],"c >4")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4],"a[i] >2")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4])
>
> Resulting in
>
> Foo
> Foo
> Bar
> Foo
> Foo
> Bar
> Foo
> Bar
> Foo
> Foo
> Foo
> Foo
>
> Thanks for your help
>
> Regards,
>
> Manuel
>
> --
> A hundred men did the rational thing. The sum of those rational choices was
> called panic. Neal Stephenson -- System of the world
> http://www.graune.org/GnuPG_pubkey.asc
> Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A  5828 5476 7E92 2DB4 3C99
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#87957

Joel Goldstick <joel.goldstick@gmail.com> writes:

> On Wed, Mar 25, 2015 at 1:29 PM, Manuel Graune <manuel.graune@koeln.de> wrote:
>>
>> def test1(a, b, condition="True"):
>>     for i,j in zip(a,b):
>>         c=i+j
>>         if eval(condition):
>>            print("Foo")
>>
> I'm not sure I understand your question, but condition will evaluate
> to True or False regardless, so:
>          if condition:
>             print ("Foo")
>          else:
>             print ("Bar")
>

The point is (see examples below) to specify the condition that is to be
evaluated when calling the function (as opposed to when stating the function). 

> eval can be dangerous as someone could put some unknown command with
> side effects in condition
>

I know that. That's why I'm looking for an alternative. ;-)

>> test1([0,1,2,3],[1,2,3,4],"i+j >4")
>> print("Bar")
>> test1([0,1,2,3],[1,2,3,4],"c >4")
>> print("Bar")
>> test1([0,1,2,3],[1,2,3,4],"a[i] >2")
>>
>> Resulting in
>>
>> Foo
>> Foo
>> Bar
>> Foo
>> Foo
>> Bar
>> Foo

Regards,

Manuel

-- 
A hundred men did the rational thing. The sum of those rational choices was
called panic. Neal Stephenson -- System of the world
http://www.graune.org/GnuPG_pubkey.asc
Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A  5828 5476 7E92 2DB4 3C99

[toc] | [prev] | [next] | [standalone]

#87959

On Wed, Mar 25, 2015 at 1:51 PM, Manuel Graune <manuel.graune@koeln.de> wrote:
> Joel Goldstick <joel.goldstick@gmail.com> writes:
>
>> On Wed, Mar 25, 2015 at 1:29 PM, Manuel Graune <manuel.graune@koeln.de> wrote:
>>>
>>> def test1(a, b, condition="True"):
>>>     for i,j in zip(a,b):
>>>         c=i+j
>>>         if eval(condition):
>>>            print("Foo")
>>>
>> I'm not sure I understand your question, but condition will evaluate
>> to True or False regardless, so:
>>          if condition:
>>             print ("Foo")
>>          else:
>>             print ("Bar")
>>
>
> The point is (see examples below) to specify the condition that is to be
> evaluated when calling the function (as opposed to when stating the function).
>
>> eval can be dangerous as someone could put some unknown command with
>> side effects in condition
>>
>
> I know that. That's why I'm looking for an alternative. ;-)

Oh, now I see.  Do you know about this:
https://docs.python.org/2/library/ast.html#ast.literal_eval


>
>>> test1([0,1,2,3],[1,2,3,4],"i+j >4")
>>> print("Bar")
>>> test1([0,1,2,3],[1,2,3,4],"c >4")
>>> print("Bar")
>>> test1([0,1,2,3],[1,2,3,4],"a[i] >2")
>>>
>>> Resulting in
>>>
>>> Foo
>>> Foo
>>> Bar
>>> Foo
>>> Foo
>>> Bar
>>> Foo
>
> Regards,
>
> Manuel
>
> --
> A hundred men did the rational thing. The sum of those rational choices was
> called panic. Neal Stephenson -- System of the world
> http://www.graune.org/GnuPG_pubkey.asc
> Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A  5828 5476 7E92 2DB4 3C99
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#87960

On Wed, Mar 25, 2015 at 12:17 PM, Joel Goldstick
<joel.goldstick@gmail.com> wrote:
> Oh, now I see.  Do you know about this:
> https://docs.python.org/2/library/ast.html#ast.literal_eval

As the name suggests, that only evals literals. It won't work for
complex expressions like "i + j > 4"

[toc] | [prev] | [next] | [standalone]

#87961

On Wed, Mar 25, 2015 at 2:22 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Mar 25, 2015 at 12:17 PM, Joel Goldstick
> <joel.goldstick@gmail.com> wrote:
>> Oh, now I see.  Do you know about this:
>> https://docs.python.org/2/library/ast.html#ast.literal_eval
>
> As the name suggests, that only evals literals. It won't work for
> complex expressions like "i + j > 4"
> --
Thanks Ian, sorry for the misdirection ...
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#87956

On Wed, Mar 25, 2015 at 11:29 AM, Manuel Graune <manuel.graune@koeln.de> wrote:
> Hi,
>
> I'm looking for a way to supply a condition to an if-statement inside a
> function body when calling the function. I can sort of get what I want
> with using eval (see code below) but I would like to achieve this in a
> safer way. If there is a solution which is safer while being
> less flexible, that would be fine. Also, supplying the condition as a
> string is not necessary. What I want to do is basically like this:
>
> def test1(a, b, condition="True"):
>     for i,j in zip(a,b):
>         c=i+j
>         if eval(condition):
>            print("Foo")

Pass the condition as a function.

def test1(a, b, condition=lambda i, j: True):
    for i,j in zip(a,b):
        c=i+j
        if condition(i, j):
            print("Foo")

test1([0,1,2,3],[1,2,3,4], lambda i, j: i+j > 4)
# etc.

If you find lambdas confusing and prefer named functions, those will
work just as well.

def i_plus_j_gt_4(i, j):
    return i + j > 4

test1([0,1,2,3],[1,2,3,4], i_plus_j_gt_4)

[toc] | [prev] | [next] | [standalone]

#87973

On 2015-03-25, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Mar 25, 2015 at 11:29 AM, Manuel Graune <manuel.graune@koeln.de> wrote:
>
>> I'm looking for a way to supply a condition to an if-statement inside a
>> function body when calling the function. I can sort of get what I want
>> with using eval [...]
>
> Pass the condition as a function.
>
> def test1(a, b, condition=lambda i, j: True):
>     for i,j in zip(a,b):
>         c=i+j
>         if condition(i, j):
>             print("Foo")
>
> test1([0,1,2,3],[1,2,3,4], lambda i, j: i+j > 4)
> # etc.

FWIW, back in the day such a function was referred to as a "thunk"
(particularly if it was auto-generated by a compiler that used
pass-by-name instead of pass-by-value or pass-by-reference):

  http://en.wikipedia.org/wiki/Thunk

Dunno if people still use that term or not.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm RELIGIOUS!!
                                  at               I love a man with
                              gmail.com            a HAIRPIECE!!  Equip me
                                                   with MISSILES!!

[toc] | [prev] | [next] | [standalone]

#87982

On Wed, Mar 25, 2015 at 1:53 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2015-03-25, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Wed, Mar 25, 2015 at 11:29 AM, Manuel Graune <manuel.graune@koeln.de> wrote:
>>
>>> I'm looking for a way to supply a condition to an if-statement inside a
>>> function body when calling the function. I can sort of get what I want
>>> with using eval [...]
>>
>> Pass the condition as a function.
>>
>> def test1(a, b, condition=lambda i, j: True):
>>     for i,j in zip(a,b):
>>         c=i+j
>>         if condition(i, j):
>>             print("Foo")
>>
>> test1([0,1,2,3],[1,2,3,4], lambda i, j: i+j > 4)
>> # etc.
>
> FWIW, back in the day such a function was referred to as a "thunk"
> (particularly if it was auto-generated by a compiler that used
> pass-by-name instead of pass-by-value or pass-by-reference):
>
>   http://en.wikipedia.org/wiki/Thunk
>
> Dunno if people still use that term or not.

I've heard the term (though not since my college days, I think), but
I've always understood thunks to be parameterless (hence the use as a
form of pass-by-name).

[toc] | [prev] | [next] | [standalone]

#88070

On 2015-03-25, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Wed, Mar 25, 2015 at 1:53 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2015-03-25, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> On Wed, Mar 25, 2015 at 11:29 AM, Manuel Graune <manuel.graune@koeln.de> wrote:
>>>
>>>> I'm looking for a way to supply a condition to an if-statement inside a
>>>> function body when calling the function. I can sort of get what I want
>>>> with using eval [...]
>>>
>>> Pass the condition as a function.
>>>
>>> def test1(a, b, condition=lambda i, j: True):
>>>     for i,j in zip(a,b):
>>>         c=i+j
>>>         if condition(i, j):
>>>             print("Foo")
>>>
>>> test1([0,1,2,3],[1,2,3,4], lambda i, j: i+j > 4)
>>> # etc.
>>
>> FWIW, back in the day such a function was referred to as a "thunk"
>> (particularly if it was auto-generated by a compiler that used
>> pass-by-name instead of pass-by-value or pass-by-reference):
>>
>>   http://en.wikipedia.org/wiki/Thunk
>>
>> Dunno if people still use that term or not.
>
> I've heard the term (though not since my college days, I think), but
> I've always understood thunks to be parameterless (hence the use as a
> form of pass-by-name).

You're right -- I misread the example. Somehow I skipped the "for i,j"
line completely, and was thinking that i and j were defined in the
caller's context. Thus the OP was trying to implment something akin to
call by name.

-- 
Grant Edwards               grant.b.edwards        Yow! Here I am in the
                                  at               POSTERIOR OLFACTORY LOBULE
                              gmail.com            but I don't see CARL SAGAN
                                                   anywhere!!

[toc] | [prev] | [next] | [standalone]

#87965

On 3/25/2015 1:29 PM, Manuel Graune wrote:
> Hi,
>
> I'm looking for a way to supply a condition to an if-statement inside a
> function body when calling the function. I can sort of get what I want
> with using eval (see code below) but I would like to achieve this in a
> safer way. If there is a solution which is safer while being
> less flexible, that would be fine. Also, supplying the condition as a
> string is not necessary. What I want to do is basically like this:
>
> def test1(a, b, condition="True"):
>      for i,j in zip(a,b):
>          c=i+j
>          if eval(condition):
>             print("Foo")

The standard solution to the above is to have a boolean parameter, such 
as print_wanted=False.

> test1([0,1,2,3],[1,2,3,4],"i+j >4")
> print("Bar")

For this, follow Ian's suggestion of passing a predicate function.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#87967

On 03/25/2015 10:29 AM, Manuel Graune wrote:
> Hi,
>
> I'm looking for a way to supply a condition to an if-statement inside a
> function body when calling the function. I can sort of get what I want
> with using eval (see code below) but I would like to achieve this in a
> safer way. If there is a solution which is safer while being
> less flexible, that would be fine. Also, supplying the condition as a
> string is not necessary. What I want to do is basically like this:
>
> def test1(a, b, condition="True"):
>      for i,j in zip(a,b):
>          c=i+j
>          if eval(condition):
>             print("Foo")
>
> test1([0,1,2,3],[1,2,3,4],"i+j >4")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4],"c >4")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4],"a[i] >2")
> print("Bar")
> test1([0,1,2,3],[1,2,3,4])
>
>

This is nicely done with lambda expressions:

To pass in a condition as a function:
    test1([0,1,2,3],[1,2,3,4], lambda i,j: i+j<4)

To check the condition in the function:
     if condition(i,j):

To get the full range of conditions, you will need to include all the variables needed by any condition you can imagine.  So the above suggestions may need to be expanded to:
  ... lambda i,j,a,b: ... or whatever

and
   ... condition(i,j,a,b) ... or whatever

If any of your conditions gets too long/complex for a lambda (or you just don't like Python's lambda expressions), then just create a function for your condition:

   def cond1(i,j,a,b):
       return i+j>4

and do
    test1(..., cond1)
and
     if condition(i,j,a,b):




-- 
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

[toc] | [prev] | [next] | [standalone]

#88020

On Thursday, March 26, 2015 at 12:44:03 AM UTC+5:30, Gary Herron wrote:
> On 03/25/2015 10:29 AM, Manuel Graune wrote:
> > Hi,
> >
> > I'm looking for a way to supply a condition to an if-statement inside a
> > function body when calling the function. I can sort of get what I want
> > with using eval (see code below) but I would like to achieve this in a
> > safer way. If there is a solution which is safer while being
> > less flexible, that would be fine. Also, supplying the condition as a
> > string is not necessary. What I want to do is basically like this:
> >
> > def test1(a, b, condition="True"):
> >      for i,j in zip(a,b):
> >          c=i+j
> >          if eval(condition):
> >             print("Foo")
> >
> > test1([0,1,2,3],[1,2,3,4],"i+j >4")
> > print("Bar")
> > test1([0,1,2,3],[1,2,3,4],"c >4")
> > print("Bar")
> > test1([0,1,2,3],[1,2,3,4],"a[i] >2")
> > print("Bar")
> > test1([0,1,2,3],[1,2,3,4])
> >
> >
> 
> This is nicely done with lambda expressions:

The builtin function filter is for this (more or less).
Comprehensions are usually better than filter.

[And BTW
help(filter) in python2 is much better documention than in python3
]

[toc] | [prev] | [next] | [standalone]

#88028

On Thu, Mar 26, 2015 at 3:02 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> [And BTW
> help(filter) in python2 is much better documention than in python3
> ]

Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2

filter(...)
    filter(function or None, sequence) -> list, tuple, or string

    Return those items of sequence for which function(item) is true.  If
    function is None, return the items that are true.  If sequence is a tuple
    or string, return the same type, else return a list.

Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
[GCC 4.7.2] on linux

class filter(object)
 |  filter(function or None, iterable) --> filter object
 |
 |  Return an iterator yielding those items of iterable for which function(item)
 |  is true. If function is None, return the items that are true.
 |
 |  Methods defined here:
(chomp a handful of method details)

Looks pretty comparable to me. Py2 clearly stipulates that it's a
function that returns a tuple, string, or list. Py3 defines it as a
class, and then describes what it does (it's an iterator) and then its
methods.

ChrisA

[toc] | [prev] | [next] | [standalone]

#88116

On Thursday, March 26, 2015 at 11:30:57 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Mar 26, 2015 at 3:02 PM, Rustom Mody  wrote:
> > [And BTW
> > help(filter) in python2 is much better documention than in python3
> > ]
> 
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
> 
> filter(...)
>     filter(function or None, sequence) -> list, tuple, or string
> 
>     Return those items of sequence for which function(item) is true.  If
>     function is None, return the items that are true.  If sequence is a tuple
>     or string, return the same type, else return a list.
> 
> Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
> [GCC 4.7.2] on linux
> 
> class filter(object)
>  |  filter(function or None, iterable) --> filter object
>  |
>  |  Return an iterator yielding those items of iterable for which function(item)
>  |  is true. If function is None, return the items that are true.
>  |
>  |  Methods defined here:
> (chomp a handful of method details)

Sackful may be more accurate :-)

On a different note... I wonder how you do it:
Look at 300 lines of code and notice exactly those 3 that... um... cause 
a lot of trouble :-)
[My eyes just glaze over]

On a more specific note, its the 1st line:

class filter(object)

which knocks me off.
If a more restricted type from the ABC was shown which exactly captures all
the iterator-specific stuff like __iter__, __next__ it would sure help (me)

On a 3rd note: I think Ive found a little buglet while trying to post this message, can you confirm?
[Linux Debian Xfce]

After selecting the line above [inside python inside help(filter) ]for
cut-pasting here, by mistake I pressed Ctrl-C rather than Ctrl-Shift-C
An exception was thrown and the terminal remained in some sort of raw mode
even after exiting python

[toc] | [prev] | [next] | [standalone]

#88121

On Fri, Mar 27, 2015 at 12:41 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, March 26, 2015 at 11:30:57 AM UTC+5:30, Chris Angelico wrote:
>> On Thu, Mar 26, 2015 at 3:02 PM, Rustom Mody  wrote:
>> > [And BTW
>> > help(filter) in python2 is much better documention than in python3
>> > ]
>>
>> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
>> [GCC 4.7.2] on linux2
>>
>> filter(...)
>>     filter(function or None, sequence) -> list, tuple, or string
>>
>>     Return those items of sequence for which function(item) is true.  If
>>     function is None, return the items that are true.  If sequence is a tuple
>>     or string, return the same type, else return a list.
>>
>> Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
>> [GCC 4.7.2] on linux
>>
>> class filter(object)
>>  |  filter(function or None, iterable) --> filter object
>>  |
>>  |  Return an iterator yielding those items of iterable for which function(item)
>>  |  is true. If function is None, return the items that are true.
>>  |
>>  |  Methods defined here:
>> (chomp a handful of method details)
>
> Sackful may be more accurate :-)

Not really. Here's the entire help(filter) text:

Help on class filter in module builtins:

class filter(object)
 |  filter(function or None, iterable) --> filter object
 |
 |  Return an iterator yielding those items of iterable for which function(item)
 |  is true. If function is None, return the items that are true.
 |
 |  Methods defined here:
 |
 |  __getattribute__(self, name, /)
 |      Return getattr(self, name).
 |
 |  __iter__(self, /)
 |      Implement iter(self).
 |
 |  __new__(*args, **kwargs) from builtins.type
 |      Create and return a new object.  See help(type) for accurate signature.
 |
 |  __next__(self, /)
 |      Implement next(self).
 |
 |  __reduce__(...)
 |      Return state information for pickling.


> On a different note... I wonder how you do it:
> Look at 300 lines of code and notice exactly those 3 that... um... cause
> a lot of trouble :-)
> [My eyes just glaze over]

That's called experience. It's an intrinsic part of being a programmer.

> On a more specific note, its the 1st line:
>
> class filter(object)
>
> which knocks me off.
> If a more restricted type from the ABC was shown which exactly captures all
> the iterator-specific stuff like __iter__, __next__ it would sure help (me)

But there's no point in subclassing for everything. In this case,
filter doesn't subclass anything but object, so there's no value in
stating anything else. You want to know if it's iterable? Check for an
__iter__ method. Etcetera.

> On a 3rd note: I think Ive found a little buglet while trying to post this message, can you confirm?
> [Linux Debian Xfce]
>
> After selecting the line above [inside python inside help(filter) ]for
> cut-pasting here, by mistake I pressed Ctrl-C rather than Ctrl-Shift-C
> An exception was thrown and the terminal remained in some sort of raw mode
> even after exiting python

Yes, confirmed. It'll be something to do with what happens when you
have 'less' and readline working together, probably.

Tip: Use Ctrl-Insert rather than Ctrl-Shift-C. It's the more standard
keystroke anyway.

ChrisA

[toc] | [prev] | [next] | [standalone]

#88130

On Friday, March 27, 2015 at 7:26:54 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Mar 27, 2015 at 12:41 PM, Rustom Mody  wrote:
> > On a more specific note, its the 1st line:
> >
> > class filter(object)
> >
> > which knocks me off.
> > If a more restricted type from the ABC was shown which exactly captures all
> > the iterator-specific stuff like __iter__, __next__ it would sure help (me)
> 
> But there's no point in subclassing for everything. In this case,
> filter doesn't subclass anything but object, so there's no value in
> stating anything else. You want to know if it's iterable? Check for an
> __iter__ method. Etcetera.

Well maybe... I dont the ABC thing very well in python.
[It does seem to be underutilized]

Anyway my point is that in python (after 2.2??) saying something is an object 
is a bit of a tautology -- ie verbiage without information.


Note: We are not talking of the *fact* that something -- in this case filter --
subclasses object, but the output of help(filter)

[toc] | [prev] | [next] | [standalone]

#88133

On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote:

> Anyway my point is that in python (after 2.2??) saying something is an
> object is a bit of a tautology -- ie verbiage without information.


Er, it's *always* been a tautology. Every value in Python is an object,
including classes, and that has been always the case.

However, just because it's a tautology doesn't mean it isn't useful to know.
(Tautologies are also known as *facts* and knowing facts is usually a good
thing.) For the majority of programming languages, it is not the case that
all values are objects, and not all people reading the documentation should
be expected to know that this applies to Python.

Besides, "object" in Python circles is ambiguous. It can also mean:

* the Python type "object";

* an instance of the Python type "object";

* any non-class instance of any old-style class (Python 2 only) 
  or type (new-style class);

* "boxed" values in object-oriented languages;

and possibly others as well. Personally, I dislike using object as a synonym
for "instance", as it fails to account for classes which are instances. But
other than that, all those meanings are valid and have to be distinguished
from context.





-- 
Steven

[toc] | [prev] | [next] | [standalone]

#88157

On Friday, March 27, 2015 at 10:05:21 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote:
> 
> > Anyway my point is that in python (after 2.2??) saying something is an
> > object is a bit of a tautology -- ie verbiage without information.
> 
> 
> Er, it's *always* been a tautology. Every value in Python is an object,
> including classes, and that has been always the case.
> 
> However, just because it's a tautology doesn't mean it isn't useful to know.
> (Tautologies are also known as *facts* and knowing facts is usually a good
> thing.) For the majority of programming languages, it is not the case that
> all values are objects, and not all people reading the documentation should
> be expected to know that this applies to Python.

I am making a point of pedagogy not semantics.
This is help(filter) for python 2 and 3.

Python2:
Help on built-in function filter in module __builtin__:

filter(...)
    filter(function or None, sequence) -> list, tuple, or string
    
    Return those items of sequence for which function(item) is true.  If
    function is None, return the items that are true.  If sequence is a tuple
    or string, return the same type, else return a list.
--------------------------

Python 3
Help on class filter in module builtins:

class filter(object)
 |  filter(function or None, iterable) --> filter object
 |  
 |  Return an iterator yielding those items of iterable for which function(item)
 |  is true. If function is None, return the items that are true.
 |  
 |  Methods defined here:
 |  
 |  __getattribute__(self, name, /)
 |      Return getattr(self, name).
 |  
 |  __iter__(self, /)
 |      Implement iter(self).
 |  
 |  __new__(*args, **kwargs) from builtins.type
 |      Create and return a new object.  See help(type) for accurate signature.
 |  
 |  __next__(self, /)
 |      Implement next(self).
 |  
 |  __reduce__(...)
 |      Return state information for pickling.
------------------------

Try and put yourself in the place of a noob:

Knows some C, not much else.
Starts studying python.
Good until a point.
Then suddenly hit... map, filter, and the worst of all lambda.
More he reads less he understands.
Tries help... Gets the above.

So which do you think helps him more python 2 or 3?

[toc] | [prev] | [next] | [standalone]

#88164

On Sat, Mar 28, 2015 at 12:48 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Knows some C, not much else.
> Starts studying python.
> Good until a point.
> Then suddenly hit... map, filter, and the worst of all lambda.
> More he reads less he understands.
> Tries help... Gets the above.
>
> So which do you think helps him more python 2 or 3?

Python 3, because scaring someone off filter() might push him towards
comprehensions instead :)

No, seriously: I wouldn't expect anyone to be using help(filter) in
that way. Someone who knows C and not much Python is simply not going
to stumble upon filter, but will have a task/problem in mind. From
there, either the online documentation or a Q&A forum like this or
Stack Overflow will be the next port of call, not the help for one
particular function.

And frankly, if someone says "what you want is filter()" and doesn't
explain what it does, why it's useful, and why it's better than a list
comp/genexp, is doing a poor job of helping. The most common case of
filter can be trivially converted into a genexp:

filter(lambda x: some_expression, some_iterable)
(x for x in some_iterable if some_expression)

Unlike map(), filter() doesn't accept multiple iterables, so you don't
even need to worry about zip(). The only time you really need filter()
is when you're using a pre-existing function, and even then, a genexp
is often not much worse:

filter(int, list_of_strings)
(s for s in list_of_strings if int(s))

Instead of building up more and more complex nestings of map, filter,
etc, just go straight to a genexp (or a list comp, if you're about to
wrap it in list()) and add the complexity you need. Teaching a new
Python programmer about comprehensions is MUCH more useful than
teaching him/her about map and filter.

So, no. I don't think the help() difference between Py2 and Py3 is
going to be much of a problem to a new programmer who knows only C.
Maybe one who knows only LISP, but not one who knows C.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web