Re: [Tutor] Functional Programming in Python
SNIP
So I was surprised I did not get more feedback on my abused coroutine,
maybe that is good or bad, not sure.
Any ways I am on to trying to make that coroutine act more like the
State Pattern from Gang of Four. And well reading this:
http://gameprogrammingpatterns.com/state.html
I am not sure how to do this:
class Heroine
{
public:
virtual void handleInput(Input input)
{
state_-handleInput(*this, input);
}
virtual void update()
{
state_-update(*this);
}
// Other methods...
private:
HeroineState* state_;
};
(Pointing to the different classes. Since C++ has virtual methods but
Python does not?) in Python? Do I just reference the new method? Because
state_ will always be the correct object?
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On Thu, Apr 02, 2015 at 12:18:28PM -0400, WolfRage wrote: These are just some questions that I have regarding the topic of Functional Programming. I am working towards a more functional approach to programming but acknowledge that it is far from Functional, especially since this is mostly impossible in Python. You might like to read this: https://codewords.recurse.com/issues/one/an-introduction-to-functional-programming I'm not sure whether I agree with the author, but it's worth reading. -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On 04/04/2015 09:53 PM, WolfRage wrote: SNIP (Pointing to the different classes. Since C++ has virtual methods but Python does not?) I'd say that all methods in Python are virtual, except for those which are classmethod or staticmethod. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On Sat, Apr 04, 2015 at 09:53:28PM -0400, WolfRage wrote:
SNIP
So I was surprised I did not get more feedback on my abused coroutine,
maybe that is good or bad, not sure.
Perhaps people didn't understand it. Or see it :-)
Any ways I am on to trying to make that coroutine act more like the
State Pattern from Gang of Four. And well reading this:
http://gameprogrammingpatterns.com/state.html
Now you're fighting the paradigm. Functional programming works best for
code that avoids side-effects. But changes of state are naturally a
side-effect! I was sitting, now I am walking. It's still me, but my
state is different.
Now of course you can emulate state changes using purely functional
code, but its harder and less efficient.
I am not sure how to do this:
class Heroine
{
public:
virtual void handleInput(Input input)
{
state_-handleInput(*this, input);
}
virtual void update()
{
state_-update(*this);
}
// Other methods...
private:
HeroineState* state_;
};
(Pointing to the different classes. Since C++ has virtual methods but
Python does not?) in Python? Do I just reference the new method? Because
state_ will always be the correct object?
Hmmm, I'm not sure, but I think that we would say that *all* Python
methods are virtual in C++ terms. They are all resolved at runtime.
There are a few ways we might do this in Python.
class Heroine:
def __init__(self):
self.state = standing # Or use an Enum in Python 3.4
def jump(self):
if self.state == standing:
self.state = jumping
...
elif self.state == jumping:
pass
# Dispatch table of keys to actions.
KEYMAP = {'b': jump,
'd': duck,
'f': run,
...
}
def handle_keypress(self, key):
method = self.KEYMAP.get(key, None)
if method:
method(self)
We look up the key press, and get a reference to the method itself, not
the name of the method. (Or None.) We then call that method by providing
self as the first argument. Nice and easy. It's so easy that I'm not
sure if it's even worth discussing alternatives.
Another alternative might be to use delegation, or object composition.
Give the Heroine class all the methods which don't change. For the
methods which do change, create a separate FooState class for each
state:
class JumpingState:
def jump(self):
pass
def duck(self):
...
class RunningState:
...
class Heroine:
def __init__(self):
self.state = StandingState()
# Dispatch table of keys to method names.
KEYMAP = {'b': 'jump',
'd': 'duck',
'f': 'run',
...
}
def handle_keypress(self, key):
name = self.KEYMAP.get(key, None)
if name:
newstate = getattr(self.state, name)()
if newstate:
self.state = newstate()
Methods of the state object can signal a change of state by returning
the class representing the new state. Otherwise, they can return None to
signal no change of state.
Here is how we might do this using inheritence instead of composition.
Start with a base class and a bunch of default methods which
conditionally raise:
class BaseHeroine:
def jump(self):
if self.__class__ is BaseHeroine:
raise RuntimeError
def run(self):
if self.__class__ is BaseHeroine:
raise RuntimeError
def duck(self):
if self.__class__ is BaseHeroine:
raise RuntimeError
# Dispatch table of keys to method names.
KEYMAP = {'b': 'jump',
'd': 'duck',
'f': 'run',
...
}
def handle_keypress(self, key):
name = self.KEYMAP.get(key, None)
if name:
getattr(self.state, name)()
Now have a bunch of subclasses, one for each state. Override only the
methods you need. (Remember, the default behaviour for each method is to
do nothing, if called from a subclass. They only raise if called from
the base class.)
class JumpHeroine(BaseHeroine): ...
class StandHeroine(BaseHeroine): ...
class RunHeroine(BaseHeroine): ...
Now create an instance, and set its state:
heroine = BaseHeroine()
heroine.__class__ = StandHeroine
State transitions are managed by *changing the instance's class*.
Methods can do that themselves:
def spam(self):
self.__class__ = RunHeroine # Don't instantiate the class.
print(Spam spam spam lovery spam)
Now, I haven't tested any of the above code, but here is a short and
simple demonstration showing that it does work:
py class X:
... def display(self):
... print(in X)
... def method(self):
... self.display()
... print(self, type(self), self.__class__)
...
py class Y(X):
... def display(self):
... print(in Y)
...
py
Re: [Tutor] Functional Programming in Python
On 04/02/2015 03:08 PM, Tim Johnson wrote: SNIP You have already received valuable replies from two advanced python experts. If you are looking for a book (available digitally for kindle) I would recommend Guide To: Functional Python Comprehension Constructs by Matt Harrison Thanks I will look into this book. I have been reading a lot of articles on the topic lately. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On 04/02/2015 02:52 PM, Danny Yoo wrote: SNIP This is not to say that closures are bad. It's just to point out that just because functional programs use closures quite a lot, doesn't automatically mean closures are the most appropriate tool for everything. If there are parts of the language that already do the sort of thing you're trying to accomplish, it might be good to reuse those parts, rather than reinvent the universe. I agree that closures are not the best tool for every job. And in the case of a callback based GUI they simply do not work, since execution needs to leave a function in order to run the GUI's main loop. Thus I abused a coroutine. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On 04/02/2015 02:07 PM, Steven D'Aprano wrote: SNIP What are the best practices to create more Functional Python? Best practices: * Don't force your code to use one style exclusively. Use the most natural style for the task. Python makes it easy to mix functional, procedural, imperative and object oriented code in the one application. Use whatever is most natural for your task. Good point, but still trying to understand how this is best determined beyond trial and error, and to make sure that my assumptions are correct about this decision. * Where possible, write your functions and methods in a functional style. That means: - Avoid global variables. I have got this down. - Avoid side-effects where possible. Now getting better at this. - Separate the logic of your algorithm from the display of results (e.g. don't have a method that calculates a result AND prints it; have the method calculate the result, and then have the caller print it). Need to always do this and do it first rather than during re-factoring. SNIP - Many uses of map() and filter() are better written as generator expressions; e.g. instead of: I now understand generators and I am now using them whenever I see the opportunity. filter(lambda s: s.lower().startswith(a), map(str, mylist)) you can use: (str(x) for x in mylist if s.lower().startswith(a)) - Where useful, write your code to take advantage of pipelining style, e.g. using lazy iterators rather than lists. You can then chain iterators together to get the desired result. Yes I have started to do this since seeing the power of pipe-lining. SNIP What do you mean? Can you show an example? I added an example in the reply to Alan. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On 04/02/2015 01:07 PM, Alan Gauld wrote:
SNIP
I'm not sure what you mean is impossible? The specific issues
you are having or the general FP paradigm?
I mean achieving truely functional code, atleast to the extent of some
of the things that I have read. But in general I do not need nor want
any of those special features. I.E. single assignment, optimized tail
call, etc.
Python has fairly good support for FP, much better than
most non-FP-specific languages.
I agree.
SNIP
Everything goes in functions which do not change their inputs and return
outputs.
I am getting better at this.
Use tools like itertools and functools to avoid explicit loops.
I am beginning to use them more.
What are your thoughts on Functional in Python?
It's good enough to use where the problem suits FP. It's no
more a pure FP language than it is a pure OOP language.
But in both cases you can get close enough for practical
purposes. What is your problem scenario that makes FP seem
like the best idiom?
Since I am making a game, three things got out of control.
1. Managing transitions and instances of objects between transitions.
Like loading the Main Menu then starting a Game, then returning to the
Menu and Starting a New Game, the old game was still hanging around in
memory which becomes a problem on Phones.
2. Side effects have gotten out of hand, and so adding a feature often
meant adding bugs.
3. Duplication of code got out of hand. Several functions doing similar
things but slightly different. I turned this into pipe-lining to reduce
out the different cases and eliminate the duplication.
But since it is a game the amount of state does make FP seem very
difficult and thus the game is a mixture of OOP and FP, which I am glad
to see people saying mix as needed.
Currently I am re-writing functions to reduce their side effects.
Good, nearly always the best way.
I am also removing the state from objects and putting it into a closure
type function.
That may or may not be a good idea. FP object handling can
get awfully messy and awfully inefficient.
However with callback based systems (GUI) this seemed impossible, so
instead I am abusing a coroutine to maintain the state of the
application.
Trying to force a non-FP framework(eg a GUI)_ to work in an FP
way is usually an exercise in frustration.
Yeah, it took me awhile to think about what to do in this case. Thus I
decided it was best to accept that the interface between the GUI and my
code had to be more OOP.
But is it abuse or does it seem like a good way to handle the callback
system? The benefit to me at this time is limited, but any errors in
state are confined to a single location, which is nice.
That should be true in an OOP based system too. The whole point
of OOP is to contain and hide state (as opposed to eliminating it)
I think since I am mostly self taught I perhaps failed to learn this
containment of state until recently. So before now it was fairly common
for my state to be spread out amongst several objects. It seems hard for
me to contain state in a OOP manor, just because it is so easy to use self.
What do you think about using a coroutine to handle state, how would you
do it better in a callback based system.
Without seeing how you are doing it we can't comment on *better*.
We need a baseline. Your approach may be brilliant, or it may
be awful, we can't tell.
Yeah probably not brilliant. More like hopefully not completely stupid.
But remember that there is no such thing as the perfect paradigm.
FP has many strengths but it has many weaknesses too. As does OOP.
Even procedural programming has advantages over OOP and FP in
some circumstances. By all means learn the paradigms, but don't get hung
up on any one. They all play a part.
Agreed. I am still trying to learn the right mixture.
The GUI is Kivy, but I could probably apply the same concept to QT.
Example of my Abused coroutine:
def coroutine(func):
# A decorator function that takes care of starting a coroutine
# automatically on call.
def start(*args, **kwargs):
cr = func(*args, **kwargs)
cr.send(None)
return cr
return start
@coroutine
def app_state(APP):
# APP = kivy.app.App.get_running_app() # So you know what APP is.
while True:
signal = yield
# Pass if signal is None or less than 1.
if signal = 0 and signal 1:
pass # Ignore this range
elif signal = 1 and signal 2:
if signal == 1.01: # Load Main Menu
print('Load File for Displaying Main Menu')
# This acts as a callback with the benefit of yielding
# to Kivy's main loop.
kivy.clock.Clock.schedule_once(APP.signal, 0)
yield 1.02
print('Add Main Menu to ScreenManager.')
kivy.clock.Clock.schedule_once(APP.signal, 0)
yield 1.03
print('Start Music for Main Menu')
Re: [Tutor] Functional Programming in Python
* WolfRage wolfrage8...@gmail.com [150402 11:45]: On 04/02/2015 03:08 PM, Tim Johnson wrote: SNIP You have already received valuable replies from two advanced python experts. If you are looking for a book (available digitally for kindle) I would recommend Guide To: Functional Python Comprehension Constructs by Matt Harrison Thanks I will look into this book. I have been reading a lot of articles on the topic lately. Harrison really focuses on List Comprehension as the idiomatic pythonist approach. He's very clear and concise as this eternal noob can readily understand him. I hope you find it edifying. -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On Thu, Apr 02, 2015 at 03:36:17PM -0400, WolfRage wrote: On 04/02/2015 02:07 PM, Steven D'Aprano wrote: SNIP What are the best practices to create more Functional Python? Best practices: * Don't force your code to use one style exclusively. Use the most natural style for the task. Python makes it easy to mix functional, procedural, imperative and object oriented code in the one application. Use whatever is most natural for your task. Good point, but still trying to understand how this is best determined beyond trial and error, and to make sure that my assumptions are correct about this decision. Practice and experience! * Where possible, write your functions and methods in a functional style. That means: - Avoid global variables. I have got this down. Just for the record, not all use of globals is bad. In my previous reply to Danny, I gave an example of late binding for a default parameter. In general, global constants, or near constants (e.g. you write to the variable once when your application starts up, perhaps after reading the value from a config file) are acceptable. - Avoid side-effects where possible. Now getting better at this. In object-oriented code, side-effects of course refers to side-effects outside of the object itself. An object is allowed to manipulate its own state. However, even in OO code, it is very useful to avoid side-effects. For example, the object might be immutable, so once it is initialised it cannot be changed. Even if your object is mutable, you should cleanly separate mutator methods which can modify the object from side-effect free methods which do not. E.g. it is okay for list.sort() to mutate the list, but list.index() should not! -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On Thu, Apr 02, 2015 at 11:52:40AM -0700, Danny Yoo wrote:
What are your thoughts on Functional in Python?
Currently I am re-writing functions to reduce their side effects.
I am also removing the state from objects and putting it into a closure
type function.
That doesn't remove state, it just moves it to a different place.
However, encapsulating state inside a closure, or an object, it often
the most effective and natural way to deal with a problem. Better than
passing around long and confusing numbers of variables!
Theoretically, I'd agree with this. But engineering-wise, I'd
recommend explicit structures or objects if possible when representing
state.
Yes, I agree! Hence my comment about encapsulating state inside a
closure *or an object* rather than keeping your application state in
your head, passing around vast numbers of variables only because some
other part of your application needs them...
[...]
Let's make this concrete. If we want to represent a coordinate, a
pair of numbers, we could use raw closures for this...
def pair(x, y):
def dispatch(msg):
if msg == 'x':
return x
if msg == 'y':
return y
return dispatch
p = pair(3, 4)
print p('x')
print p('y')
And this works!
But there's already a feature in the language that does this kind of
aggregation.
class pair(object):
def __init__(self, x, y):
self.x, self.y = x, y
p = pair(3, 4)
print p.x
print p.y
#
This is something that folks expect and is well supported and understood.
Precisely. I was thinking more along the idea of using closures, or
functools.partial, for encapsulating state in this way. Suppose we start
with two global variables:
def greet():
print %s, %s! % (greeting, name)
greeting = Salutations
name = Danny
greet()
Yuck. The obvious fix is to turn the globals into parameters:
def greet(greeting, name):
print %s, %s! % (greeting, name)
and pass in the greeting and name you need. And for many purposes that
is exactly the solution you need.
But... sometimes you don't want to have to manually keep track of this
greeting variable just for the sake of passing it on to the greet()
function. There are lots of solutions to that problem:
# Early binding default value.
def greet(name, greeting=Salutations):
print %s, %s! % (greeting, name)
# Late binding default value.
GREETING = Salutations
def greet(name, greeting=None):
if greeting is None:
greeting = GREETING
print %s, %s! % (greeting, name)
# An object is overkill, but let's do it anyway
class Greeter:
def __init__(self, greeting):
self.greeting = greeting
def greet(self, name):
print %s, %s! % (self.greeting, name)
mygreeter = Greeter(Salutations)
mygreeter.greet(Danny)
Or we can use a closure:
def make_greeter(greeting):
def greet(name):
print %s, %s! % (greeting, name)
return greet
greet = make_greeter(Salutations)
greet(Danny)
This is not to say that closures are bad. It's just to point out that
just because functional programs use closures quite a lot, doesn't
automatically mean closures are the most appropriate tool for
everything. If there are parts of the language that already do the
sort of thing you're trying to accomplish, it might be good to reuse
those parts, rather than reinvent the universe.
Agreed.
That's the beauty of Python: you can mix paradigms in the one piece of
code. The downside of this is that it reduces the opportunities for many
compile-time optimizations (e.g. the compiler cannot know for sure that
any function is free of side-effects) but that's often an acceptable
price to pay.
--
Steve
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
* WolfRage wolfrage8...@gmail.com [150402 08:25]: These are just some questions that I have regarding the topic of Functional Programming. I am working towards a more functional approach to programming but acknowledge that it is far from Functional, especially since this is mostly impossible in Python. Questions: What are the best practices to create more Functional Python? What are your thoughts on Functional in Python? Currently I am re-writing functions to reduce their side effects. I am also removing the state from objects and putting it into a closure type function. However with callback based systems (GUI) this seemed impossible, so instead I am abusing a coroutine to maintain the state of the application. But is it abuse or does it seem like a good way to handle the callback system? The benefit to me at this time is limited, but any errors in state are confined to a single location, which is nice. What do you think about using a coroutine to handle state, how would you do it better in a callback based system. Thank you for your insights. You have already received valuable replies from two advanced python experts. If you are looking for a book (available digitally for kindle) I would recommend Guide To: Functional Python Comprehension Constructs by Matt Harrison -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com, http://www.tj49.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming in Python
On 02/04/15 17:18, WolfRage wrote: to programming but acknowledge that it is far from Functional, especially since this is mostly impossible in Python. I'm not sure what you mean is impossible? The specific issues you are having or the general FP paradigm? Python has fairly good support for FP, much better than most non-FP-specific languages. Questions: What are the best practices to create more Functional Python? Everything goes in functions which do not change their inputs and return outputs. Use tools like itertools and functools to avoid explicit loops. What are your thoughts on Functional in Python? It's good enough to use where the problem suits FP. It's no more a pure FP language than it is a pure OOP language. But in both cases you can get close enough for practical purposes. What is your problem scenario that makes FP seem like the best idiom? Currently I am re-writing functions to reduce their side effects. Good, nearly always the best way. I am also removing the state from objects and putting it into a closure type function. That may or may not be a good idea. FP object handling can get awfully messy and awfully inefficient. However with callback based systems (GUI) this seemed impossible, so instead I am abusing a coroutine to maintain the state of the application. Trying to force a non-FP framework(eg a GUI)_ to work in an FP way is usually an exercise in frustration. But is it abuse or does it seem like a good way to handle the callback system? The benefit to me at this time is limited, but any errors in state are confined to a single location, which is nice. That should be true in an OOP based system too. The whole point of OOP is to contain and hide state (as opposed to eliminating it) What do you think about using a coroutine to handle state, how would you do it better in a callback based system. Without seeing how you are doing it we can't comment on *better*. We need a baseline. Your approach may be brilliant, or it may be awful, we can't tell. But remember that there is no such thing as the perfect paradigm. FP has many strengths but it has many weaknesses too. As does OOP. Even procedural programming has advantages over OOP and FP in some circumstances. By all means learn the paradigms, but don't get hung up on any one. They all play a part. HTH -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
