Re: [Tutor] Functional Programming in Python
On Sat, Apr 04, 2015 at 09:53:28PM -0400, WolfRage wrote: > > 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): .
Re: [Tutor] Functional Programming in Python
On 04/04/2015 09:53 PM, WolfRage wrote: (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 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
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 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
On Thu, Apr 02, 2015 at 03:36:17PM -0400, WolfRage wrote: > On 04/02/2015 02:07 PM, Steven D'Aprano wrote: > > >>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
* WolfRage [150402 11:45]: > On 04/02/2015 03:08 PM, Tim Johnson wrote: > > > 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 04/02/2015 03:08 PM, Tim Johnson wrote: 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: 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: 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. - 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. 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: 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. 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 [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
>> 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. Arbitrary lambdas are unconstrained in what they do. They are raw material for computation. You can do pretty much anything with them. That aspect is often heralded as a positive. But that means that we often need to do more work to make lambdas do things that we'd otherwise do with other built-in features of the language. 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. 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. ___ 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. It is true that Python is not a purely functional language, like Haskell, but that does not stop you from writing code in a functional style. > Questions: > 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. * Where possible, write your functions and methods in a functional style. That means: - Avoid global variables. - Avoid side-effects where possible. - 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). - In Python 3, zip(), map() and filter() are lazy iterator functions; in Python 2 they are eager, but there are lazy versions in the itertools module. - In Python 3, reduce() is moved to the functools module. - Many uses of map() and filter() are better written as generator expressions; e.g. instead of: 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. > 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! > 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. What do you mean? Can you show an example? -- 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 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
Re: [Tutor] Functional Programming
> Also, much as I like python, it's not really suited to functional > programming I'd modify that to say its not ideally suited to FP, but an FP style is certainly possible. Pyhon is adequate to learn the principles but it would be nearly impossible to write a real world solution using pure FP in Python. > That said, functional programming is fun, and these days probably > the best > introductions are either SML books or Haskell. Or good old Lisp. And there are lots of good introductory tutorials for Lisp whereas the FP material tends to be very math oriented, if you don't have a strong math background it simply won't make much sense. > I also think that having an understanding of functional programming > will > generally improve someone's code, but I would suggest that learning > the ideas > in a language where functional programming is the norm rather the > exception > is a good idea. The come back to python, and learn to undo your > recursive > instincts! This is good advice if you want more than just an appreciation of the concepts. If you want to try writing a real world application using FP then definitely try Lisp, ML or Haskell. But be prepared for a completely different division of your time over the project, much more time up front thinking about the specification of the problem, much less time debugging the functionality (the same amount of time debugging the detailed code though!) Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming
On Friday 07 July 2006 00:39, Terry Carroll wrote: > Neither of these is particularly directed to Python, though. Also, much as I like python, it's not really suited to functional programming approaches, given recursion isn't tail optimised, lambda is by comparison crippled, some aspects of pythons approach to closures aren't as robust as I'd like, mutablity of values, and things like currying aren't as simple as they could be. That said, functional programming is fun, and these days probably the best introductions are either SML books or Haskell. I also think that having an understanding of functional programming will generally improve someone's code, but I would suggest that learning the ideas in a language where functional programming is the norm rather the exception is a good idea. The come back to python, and learn to undo your recursive instincts! Michael ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming
On Thu, 6 Jul 2006, Steve Nelson wrote: > I know there's a section in Alan's tutorial on FP too, but can anyone > else recommend some good references? I happened upon this column a few days ago, whic I found a good read to explain the basic idea, for non-FPers like me: http://www.defmacro.org/ramblings/fp.html Also, while trying to re-find the above URL, I found Simon Thompson's "Type Theory and Functional Programming," which looks like an interesting 378-page read and can be found online at http://www.cs.kent.ac.uk/people/staff/sjt/TTFP/ Neither of these is particularly directed to Python, though. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming
Steve Nelson wrote: > Hi All, > > I've just today starting thinking more about programming in a more > functional style, and came across the following article which I > thought was really good: > > http://www.amk.ca/python/writing/functional > > I know there's a section in Alan's tutorial on FP too, but can anyone > else recommend some good references? It is all a very new approach > for me, but it is also fascinating, and rather fun! For more examples of using the tools in AMK's article, the Python Cookbook is a good place to look. David Mertz writes Python in an extreme functional style. Take a look at some of his Charming Python columns for examples - three columns from 2001 are specifically about functional programming. http://www-128.ibm.com/developerworks/views/linux/libraryview.jsp?search_by=charming+python: Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Functional Programming
On Thu, 6 Jul 2006, Steve Nelson wrote: > I've just today starting thinking more about programming in a more > functional style, and came across the following article which I thought > was really good: > > http://www.amk.ca/python/writing/functional Hi Steve, The references on the bottom are sparse, but solid; Structure and Interpretation of Computer Programs can't be recommended enough. I would add to that list another textbook: How to Design Programs http://htdp.org It goes slower than Structure and Interpretation of Computer Programs, but is also a very good text. I have to admit I felt sorta sleepy on the first few sections, but starting around Section 9 things picked up quite a bit and I woke up. Best of wishes! ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor