A more pythonic way of writting

[eric]

Hi,

I've got this two pieces of code that works together, and fine

def testit():
for vals in [[i&mask==mask for mask in [1<<j for j in range(6)] ]
for i in range(1<<6)]:
print vals, '->', flag(*vals)

def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
filtered = map( lambda m:m[1],filter( lambda m: m[0], zip(vals,
'iLmsux')))
return '?'+''.join( filtered )

testit()

but I'm not proud of the way it is written. I dont find it very
pythonic.
I have to multiplex (using zip) bool and value, filter using only the
bool, and demultiplex later using map

the first simply parses all the possible combination of 6 boolean
(can't hardly be made simpler)

the second function, should simply return a string based on the
boolean value
i, L, m, s, u, x,
True, False, False, True, True, False
= ?isu

that's should take only one line, shouldn't it?

any idea ?

 

[Mark Tolonen]

def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
filtered = map( lambda m:m[1],filter( lambda m: m[0],
zip(vals,'iLmsux')))
return '?'+''.join( filtered )

filtered = [c for c,v in zip('iLmsux',vals) if v]

-Mark

 

[Gerard flanagan]

Hi,

I've got this two pieces of code that works together, and fine

def testit():
for vals in [[i&mask==mask for mask in [1<<j for j in range(6)] ]
for i in range(1<<6)]:
print vals, '->', flag(*vals)

def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
filtered = map( lambda m:m[1],filter( lambda m: m[0], zip(vals,
'iLmsux')))
return '?'+''.join( filtered )

testit()

but I'm not proud of the way it is written. I dont find it very
pythonic.
I have to multiplex (using zip) bool and value, filter using only the
bool, and demultiplex later using map

the first simply parses all the possible combination of 6 boolean
(can't hardly be made simpler)

the second function, should simply return a string based on the
boolean value
i, L, m, s, u, x,
True, False, False, True, True, False
= ?isu

that's should take only one line, shouldn't it?

any idea ?

#after Paul Rubin (c.l.py)
def hypercube(ndims):
if ndims == 0:
yield ()
return
for h in 1, 0:
for y in hypercube(ndims-1):
yield (h,)+y

#after Mark Tolonen
for item in hypercube(6):
print ''.join(c for c,v in zip('iLmsux', item) if v)

 

[eric]

def flag(IGNORECASE=False, LOCALE=False, MULTILINE=False,
DOTALL=False, UNICODE=False, VERBOSE=False):
   vals = [IGNORECASE, LOCALE, MULTILINE, DOTALL, UNICODE, VERBOSE]
   filtered = map( lambda m:m[1],filter( lambda m: m[0],
zip(vals,'iLmsux')))
   return '?'+''.join( filtered  )

    filtered = [c for c,v in zip('iLmsux',vals) if v]

-Mark

thank you very much ! great !

I can't get used to this late 'if' syntax !

@Gerard
nice hypercube function. But I'll keep with my implementation :
I like to believe that the less the 'debug pointer' stands in the
python code, the fastest the code is (or is potentially)

I keep thinking that
def hypercube(ndims) :
for i in range(1<<ndims):
yield [i&mask==mask for mask in [1<<j for j in range(ndims)] ]

but thanks for you proposition, it's interesting anyway

 

[Steven D'Aprano]

I like to believe that the less the 'debug pointer' stands in the python
code, the fastest the code is (or is potentially)

What's a debug pointer?

Pre-mature optimization is the root of evil in programming. Unless you
have actually *measured* the speed of the code, how do you know you
aren't making it slower instead of faster?

Experience with other languages often is misleading when programming with
Python. If you are used to programming in C, for example, then you will
tend to program one way because comparisons are fast and moving records
is slow. But in Python, comparisons can be slow and moving records is
fast, so the C programmer's intuitions about "fast code" are often
pessimations instead of optimizations.

 

[eric]

What's a debug pointer?

Pre-mature optimization is the root of evil in programming. Unless you
have actually *measured* the speed of the code, how do you know you
aren't making it slower instead of faster?

Experience with other languages often is misleading when programming with
Python. If you are used to programming in C, for example, then you will
tend to program one way because comparisons are fast and moving records
is slow. But in Python, comparisons can be slow and moving records is
fast, so the C programmer's intuitions about "fast code" are often
pessimations instead of optimizations.

you are right about premature optimization. I cannot disagree.

My 'rule of thumb' was more about that:
1/ keep the code the more descriptive and the less procedural as
possible.
2/ the less instructions you write, the more optimization you'll get
from the others

the hypercube function is cool, and I would use it, if I weren't in
charge of maintaining the code.


I've done some 'timeit'

import timeit

t1 = timeit.Timer(
"""
h1 = hypercube(6)
""",
"""def hypercube(ndims):
return [[i&mask==mask for mask in [1<<j for j
in range(ndims)] ] for i in range(1<<ndims)]""")

t2 = timeit.Timer(
"""
h2 = [h for h in hypercube(6)]
""",
"""def hypercube(ndims):
if ndims == 0:
yield ()
return
for h in False,True:
for y in hypercube(ndims-1):
yield (h,)+y""")

M= 100000
array_method = t1.timeit(M)
recursion_method = t2.timeit(M)

print "array method %s"%array_method
print "recursion method %s"%recursion_method

print "recursion is %s%% slower"%( (recursion_method - array_method)/
recursion_method*100)

"""
console result
array method 41.2270488739
recursion method 48.3009829521
recursion is 14.6455281981% slower
"""

well, nothing drastic here.