fun with lambdas
Hello!
given the definition
def f(a,b): return a+b
With this code:
fs = [ lambda x: f(x,o) for o in [0,1,2]]
or this
fs = []
for o in [0,1,2]:
fs.append( lambda x: f(x,o) )
I'd expect that fs contains partial evaluated functions, i.e.
fs[0](0) == 0
fs[1](0) == 1
fs[2](0) == 2
But this is not the case :(
What is happening here?
Nevertheless, this code does work
fs = [ eval("lambda x: f(x,%d)" % o) for o in [0,1,2,3]]
Thanks.
Juan Pablo
--
http://mail.python.org/mailman/listinfo/python-list
Re: fun with lambdas
Thanks to all I settled with this: def partial1(f,b): return lambda a:f(a,b) def partial2(f,a): return lambda b:f(a,b) Juan Pablo 2005/10/20, Mike Meyer <[EMAIL PROTECTED]>: > Robert Kern <[EMAIL PROTECTED]> writes: > > Juan Pablo Romero wrote: > >> Hello! > >> > >> given the definition > >> > >> def f(a,b): return a+b > >> > >> With this code: > >> > >> fs = [ lambda x: f(x,o) for o in [0,1,2]] > >> > >> or this > >> > >> fs = [] > >> for o in [0,1,2]: > >> fs.append( lambda x: f(x,o) ) > >> > >> I'd expect that fs contains partial evaluated functions, i.e. > >> > >> fs[0](0) == 0 > >> fs[1](0) == 1 > >> fs[2](0) == 2 > >> > >> But this is not the case :( > >> > >> What is happening here? > > > > Namespaces. The functions are looking up o at runtime. In both cases, o > > is bound to the last object in [0,1,2] once the iteration is finished. > > > > Try this (although I'm sure there are better ways): > > > > In [4]: fs = [lambda x, o=o: f(x, o) for o in [0,1,2]] > > > > In [5]: fs[0](0) > > Out[5]: 0 > > > > In [6]: fs[0](1) > > Out[6]: 1 > > > > In [7]: fs[0](2) > > Out[7]: 2 > > Right explanation. Right solution. Wrong examples. He wanted to see: > > >>> fs[0](0) > 0 > >>> fs[1](0) > 1 > >>> fs[2](0) > 2 > >>> > > List comprehensions were purposely designed to mimic for loops, which > (unlike other languages) don't create a new variable for each pass > through the loop. ((They also "leak" the variable to the surrounding > namespace.) So you need to capture the current value of the loop index > somewhere. An alternative (and maybe slightly cleaner) method is: > > >>> def makef(a): > ... return lambda b: a + b > ... > >>> fs = [makef(o) for o in [0, 1, 2]] > >>> fs[0](0) > 0 > >>> fs[1](0) > 1 > >>> fs[2](0) > 2 > >>> > > Generator comprehensions have the same issue: > > >>> fs = list(lambda x: f(o, x) for o in [0, 1, 2]) > >>> fs[0](0) > 2 > >>> fs[1](0) > 2 > >>> fs[2](0) > 2 > >>> > >-- > Mike Meyer <[EMAIL PROTECTED]> > http://www.mired.org/home/mwm/ > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
What's the best way to minimize the need of run time checks?
Hello, In online forums sometimes people complain that they end up having to test constantly for None, or that a function's argument has a specific type / shape (which immediately brings the following aphorism to mind: "Any sufficiently large test suite contains an ad hoc, bug-ridden, slow implementation of half of Haskell's type system"). Some responses I've seen to that particular complaint is that they are doing it wrong. That they are trying to force a type system into a dynamic language (Clojure, Ruby, Python, Javascript, etc). Do you guys have any resources you like that addresses the following issue: What is the best way to use the dynamic features of Python to avoid having to write a poor's man type system? Thanks! Juan Pablo -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 12:06 GMT-07:00 Paul Rubin : > Juan Pablo Romero Méndez writes: > > In online forums sometimes people complain that they end up having to > > test constantly for None > > That's something of a style issue. You can code in a way that avoids a > lot of those tests (not all of them). > This is exactly what I'm looking for :). Do you have any resource (blog / book, etc) that discusses this style? > > > Do you guys have any resources you like that addresses the following > > issue: What is the best way to use the dynamic features of Python to > > avoid having to write a poor's man type system? > > In practice dynamically typed code often is monomorphic anyway. > Dynamism shows up in things like deserializers. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
What static checking can actually guarantee varies depending on the specific type system at hand (C# vs Haskell vs Idris for example). But most of them can guarantee simple stuff like: "I'm I allowed to invoke this function at this point?" If you don't have that, well you can rely on tests to show that certain code paths behave in a certain way when exercised with certain inputs. 2016-08-09 12:22 GMT-07:00 MRAB : > On 2016-08-09 19:57, Chris Angelico wrote: > >> On Wed, Aug 10, 2016 at 4:51 AM, Michael Selik >> wrote: >> >>> "File-like" is a good example. Rather than go through the frustration of >>> a >>> formal definition for what is file-like, stay productive and flexible >>> with >>> duck typing. Objects that don't have the appropriate methods or >>> attributes >>> will cause a TypeError or AttributeError. If you're passing in the wrong >>> kind of object, you'll find out almost as soon as you write the code >>> (because you test early and often), just as you would with a statically >>> analyzed type system. >>> >> >> It's slightly delayed; with Python, you have to actually execute the >> code path in question, whereas a static type system would detect it at >> the compilation stage. So it may depend on the quality of your >> testing. MyPy may be able to help there. >> >> Static checking won't tell you if, say, you're adding when you should be > subtracting, so you'd need to execute the code path in question anyway > during testing! > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 13:18 GMT-07:00 Rob Gaddi : > Juan Pablo Romero Méndez wrote: > > > 2016-08-09 12:06 GMT-07:00 Paul Rubin : > > > >> Juan Pablo Romero Méndez writes: > >> > In online forums sometimes people complain that they end up having to > >> > test constantly for None > >> > >> That's something of a style issue. You can code in a way that avoids a > >> lot of those tests (not all of them). > >> > > > > > > This is exactly what I'm looking for :). Do you have any resource (blog > / > > book, etc) that discusses this style? > > > > It's not a style, it's the absence of one. > > def add2list(lst, elem): > lst.extend([elem, elem]) > return lst > > I did all the type checking I needed to there; none whatsoever. If > passed a list, or something that behaves like one, that does the > expected thing. > > If passed an ExtensionLadder, it probably does the wrong thing, but that > is no way my problem. > So as the writer of the function you expect the user to read the function body to determine what is safe to pass or not? > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 14:01 GMT-07:00 Michael Selik : > On Tue, Aug 9, 2016 at 3:22 PM Juan Pablo Romero Méndez < > jpablo.rom...@gmail.com> wrote: > >> I'm actually looking for ways to minimize run time errors, so that would >> include TypeError and AttributeError. >> >> In your "File-like" example having type information would prevent me from >> even passing the wrong object, so I don't need to test for that particular >> problem. >> > > Let's clarify this discussion by using the word "check" for type-checks > that necessary for the application to behave as desired and using the word > "test" for checking application behavior under normal and edge cases, such > as unexpected types being passed. > > Are you saying you want to minimize type-checks during the execution of > your application? Or do you want to minimize the amount of testing code you > write? > My goal is determine if there is a style of writing code in a dynamic language that minimizes the occurrence of runtime errors AND avoids two things: 1) using runtime checks all over the place (either ad hoc or using tools like Valideer) 2) attempting to test for things that a type checker would normally do (not that this is completely possible anyway) (I'm not suggesting I want to avoid writing tests at all, since there are many things the type checker can't possible check). > > I don't check for file-likeness in the application code. If somehow a > non-file-like (file-unlike?) object makes its way into my function, I > expect (and hope) my program will immediately stop and print a nice > traceback for me. If I wanted some other behavior, I probably would already > have try/except surrounding the appropriate section to deal with not-found > or permissions errors. If I need to, I'll add TypeError and AttributeError > to that except statement. > > This is interesting. You are Ok having runtime errors? > I sometimes write tests for unexpected inputs, checking to ensure that > either a TypeError or AttributeError is raised. However, sometimes I'm not > worried about it. If the user gives me bizarre input, they should know to > expect (possibly) bizarre results. Who knows, maybe that's what they wanted. > > I would add type-checking or value-checking to my application if the > wrong type or value does not raise an error but instead causes an infinite > loop or corrupts data. Those situations are fairly rare. > > > > On Tue, Aug 9, 2016 at 4:52 PM Juan Pablo Romero Méndez < > jpablo.rom...@gmail.com> wrote: > >> So as the writer of the function you expect the user to read the function >> body to determine what is safe to pass or not? > > > No. But I usually expect them to not freak out when they see a traceback. > Or if they do freak out, I want them to freak out and send a bug report. > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 18:28 GMT-07:00 Steven D'Aprano :
> On Wed, 10 Aug 2016 04:29 am, Juan Pablo Romero Méndez wrote:
>
> > Hello,
> >
> > In online forums sometimes people complain that they end up having to
> test
> > constantly for None,
>
> Then don't return None to indicate an error. If you write this:
>
> def create_spam(arg):
> if condition:
> return Spam(arg)
> else:
> return None
>
>
> then you are doing it wrong. It sounds like they are writing C in Python,
> where they think that returning None (instead of a null pointer) is the way
> to indicate an error. Instead:
>
> def create_spam(arg):
> if condition:
> return Spam(arg)
> raise MyExceptionError('cannot create spam because reasons')
>
>
> Now you can decide on a error-handling scheme:
>
> - try...except and handle the exception exactly when it occurs;
>
> - wrap your entire application in a single try...except or
> exception handler, and catch the exception in a single place;
>
> - don't even bother catching the exception in the application at all,
> treat it as a debugging aid. Any time your tests generate that
> exception, that's a bug to be fixed.
>
>
> There's no reason why you can't decide on a combination of all three:
>
> - the app catches the exception, logs it as a bug, and exits;
>
> - but individual parts of your code base treat this exception as an
> EXPECTED error, wrapping that individual call in a try...except:
>
>
> try:
> myspam = create_spam(99)
> except MyExceptionError:
> # Only occurs when the server has hung
> reboot_server()
> myspam = create_spam(99)
>
>
> Only catch exceptions you expect, and can recover from.
>
> If your *data* could be None, well that's no different from any other
> sentinel or missing value. You have to deal with it somewhere. One way is
> to filter it early:
>
> # filter out None
> data = [obj for obj in data if data is not None]
>
> # or if you prefer
> data = filter(lambda obj: obj is not None, data)
>
>
> and now you can be sure that data doesn't contain None.
>
>
Ok, so you suggested 1) catching exceptions at the point where you care, 2)
preemptively check for certain runtime conditions to avoid exceptions 3)
write as many tests as possible 4) learn to live with runtime errors.
Is that a fair characterization?
>
> [...]
> > Do you guys have any resources you like that addresses the following
> > issue: What is the best way to use the dynamic features of Python to
> avoid
> > having to write a poor's man type system?
>
> This is an old, old, old debate that applies to Lisp, Perl, Javascript,
> Lua,
> Ruby and others, not just Python. Google for "dynamic typing versus static
> typing" for more. Also google for "duck typing".
>
> One useful perspective is that languages are converging on a mix of both:
> statically typed languages are growing dynamic features, and dynamically
> typed languages are growing static checkers.
>
>
> http://steve-yegge.blogspot.com.au/2008/05/dynamic-
> languages-strike-back.html
>
>
> And some background information on the debate:
>
> https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 23:47 GMT-07:00 Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info>: > On Wednesday 10 August 2016 15:20, Juan Pablo Romero Méndez wrote: > > > Ok, so you suggested 1) catching exceptions at the point where you care, > 2) > > preemptively check for certain runtime conditions to avoid exceptions 3) > > write as many tests as possible 4) learn to live with runtime errors. > > > > Is that a fair characterization? > > (1) Not quite. > > Only catch exceptions you expect and *can deal with*. By deal with, I mean > either recover from, or convert to a user-friendly error message (perhaps > displaying it in a dialog for GUI apps). > > Your script or application may want to use a top-level exception handler to > catch any *unexpected* exceptions, log them, perform any extra cleanup > needed, > and display a nice error message before exiting. But that counts as gold- > plating: for many applications or scripts, aimed at technical or > semi-technical > users, its acceptable to just let the traceback print and the interpreter > exit. > > (2) Sometimes. Its a judgement call whether it is better to "Look Before > You > Leap" or "Easier To Ask For Forgiveness Rather Than Permission". It > depends on > what you are doing, how often you expect an exceptional case, the > performance > implications, whether there is a risk of "Time Of Check To Time Of Use" > bug, > etc. In other words, that's usually a technical question, not a matter of > style. > > Google for LBYL versus EAFP for more discussion. > > Occasionally it comes down to both being equally good, in which case you > get to > pick whichever you like. > > (3) Yes, this is correct. > > Basically, with a dynamically-typed language like Python, you have to > write all > the tests you would write with a statically-typed language, plus some more. > There's no question that the cost of the freedom dynamic typing gives you > is > that you have to write extra tests. But not as many as you might think. > Exactly what kind of freedom do you have in mind? > > The major differences in mindset between dynamic/static typing are: > > - Where the compiler would detect a type error at compile time, you get the > same result with a small unit test that checks for TypeError or > AttributeError > instead. > > (Although see also the MyPy project, which brings an optional static type- > checker to Python.) > > - As much as possible, avoid thinking "I need a list", and instead think "I > need anything which offers the list interface". (Duck-typing.) > > That *especially* counts for writing library code, application code you > can be > a bit more strict about types because you're only limiting yourself, not > other > users. > > - A Python runtime exception is not like a segmentation fault. Its not > going to > overflow a buffer and execute random code. It's a controlled failure, not > an > uncontrolled one. > > (4) There's no necessary reason to expect that you'll get more runtime > errors > in a well-written and tested Python application than you get in a > well-written > and tested C application. > > Regardless of the language, you have to deal with runtime errors: > > - network is down; > - disk is full; > - user lacks permission to edit that file; > - database error; > - account not found; > > etc. Python is no different. And regardless of the language, the compiler > can't > check that "add_account" actually adds the account, you need a unit-test to > check that. So you have to write tests either way. > > Basically, just relax -- static type checks aren't useless, but they do > very > little that a runtime exception won't give you. So long as you have a good > suite of unit tests that exercises the whole program, you'll find your type > errors when they raise TypeError, then you fix them. > > You may be gathering from this that dynamic typing and Test Driven > Development > go hand in hand. That's exactly right. They complement each other very > well. > > > > -- > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 23:16 GMT-07:00 Gregory Ewing : > Juan Pablo Romero Méndez wrote: > > This is interesting. You are Ok having runtime errors? >> > > You're going to have runtime errors in any case, whether > they come from code you've put there yourself to check > types, or from somewhere deeper down. > You are correct. What I was trying to understand is if there is a much more relaxed attitude towards runtime errors in the Python community (even embracing it) than others* (and of course, how to handle those errors). (In certain communities people favor a design where exceptions / runtime errors only happen at program boundaries) > > The only difference is that checks you make yourself > *might* catch errors slightly sooner, and *might* be able > to provide better diagnostics. > > However, experience has shown that, the vast majority of > the time, type errors in Python are caught pretty much > immediately, and the stack trace provides more than > enough information to pin down the source of the problem. > So, putting in manual type checks is hardly ever worth > the effort, and can even be counterproductive, since it > interferes with duck typing. > > Occasionally there will be a situation where a type > error results in a corrupted data structure that leads > to problems later. But those cases are relatively rare > and best dealt with as they come up. > > -- > Greg > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-09 18:28 GMT-07:00 Steven D'Aprano :
> On Wed, 10 Aug 2016 04:29 am, Juan Pablo Romero Méndez wrote:
>
> > Hello,
> >
> > In online forums sometimes people complain that they end up having to
> test
> > constantly for None,
>
> Then don't return None to indicate an error. If you write this:
>
> def create_spam(arg):
> if condition:
> return Spam(arg)
> else:
> return None
>
>
> then you are doing it wrong. It sounds like they are writing C in Python,
> where they think that returning None (instead of a null pointer) is the way
> to indicate an error. Instead:
>
> def create_spam(arg):
> if condition:
> return Spam(arg)
> raise MyExceptionError('cannot create spam because reasons')
>
>
> Now you can decide on a error-handling scheme:
>
> - try...except and handle the exception exactly when it occurs;
>
> - wrap your entire application in a single try...except or
> exception handler, and catch the exception in a single place;
>
> - don't even bother catching the exception in the application at all,
> treat it as a debugging aid. Any time your tests generate that
> exception, that's a bug to be fixed.
>
>
> There's no reason why you can't decide on a combination of all three:
>
> - the app catches the exception, logs it as a bug, and exits;
>
> - but individual parts of your code base treat this exception as an
> EXPECTED error, wrapping that individual call in a try...except:
>
>
> try:
> myspam = create_spam(99)
> except MyExceptionError:
> # Only occurs when the server has hung
> reboot_server()
> myspam = create_spam(99)
>
>
> Only catch exceptions you expect, and can recover from.
>
> If your *data* could be None, well that's no different from any other
> sentinel or missing value. You have to deal with it somewhere. One way is
> to filter it early:
>
> # filter out None
> data = [obj for obj in data if data is not None]
>
> # or if you prefer
> data = filter(lambda obj: obj is not None, data)
>
>
> and now you can be sure that data doesn't contain None.
>
>
> [...]
> > Do you guys have any resources you like that addresses the following
> > issue: What is the best way to use the dynamic features of Python to
> avoid
> > having to write a poor's man type system?
>
> This is an old, old, old debate that applies to Lisp, Perl, Javascript,
> Lua,
> Ruby and others, not just Python. Google for "dynamic typing versus static
> typing" for more. Also google for "duck typing".
>
>
Yeah, I've been on both sides of the debate over my programming years ;)
What I find frustrating to be honest about this debate (and the reason it
will never die probably) is that your perspective on it really depends
mostly on anecdotal evidence, your own knowledge, experience, etc.
I've been trying to find (without success so far) an example of a situation
where the dynamic features of a language like Python provides a clear
advantage over languages with more than one type.
> One useful perspective is that languages are converging on a mix of both:
> statically typed languages are growing dynamic features, and dynamically
> typed languages are growing static checkers.
>
>
> http://steve-yegge.blogspot.com.au/2008/05/dynamic-
> languages-strike-back.html
>
>
> And some background information on the debate:
>
> https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
I've made my motives to start this conversation very clear: """ Determine if there is a style of writing code in a dynamic language that minimizes the occurrence of runtime errors AND avoids two things: 1) using runtime checks all over the place (either ad hoc or using tools like Valideer) 2) attempting to test for things that a type checker would normally do (not that this is completely possible anyway) """ And I really appreciate people taking their time to contribute! As to why I asked that, there are several reasons: I have a very concrete need right now to find pragmatic ways to increase code quality, reduce number of defects, etc. in a Python code base. But also I want to understand better the mind set and culture of Python's community. You make a good point that my last remark is unrelated to that goal, but please don't take it as an attack of any sort. Languages are not monolithically good / bad. They have features that can be individually evaluated in light of different goals (just to name a few: is it performant enough?, is it easy to learn?, is it easy to write? is it easy to make it correct? is it expressive? is it easy to refactor? is it easy to deploy?, does it have good documentation? etc etc etc. ). Also languages evolve, so features that were considered positive at some point can become out of fashion over the years. I'm honestly interested in finding good examples of cases where the dynamic features of some language are a better solution than static typing. This is of course more useful in languages that support both paradigms. Juan Pablo 2016-08-10 13:50 GMT-07:00 Michael Selik : > > > On Wed, Aug 10, 2016, 4:34 PM Juan Pablo Romero Méndez < > jpablo.rom...@gmail.com> wrote: > >> >> I've been trying to find (without success so far) an example of a >> situation >> where the dynamic features of a language like Python provides a clear >> advantage over languages with more than one type. >> > > Only one type? There are a great variety of types for Python objects. Even > Python classes have types. Further, you can modify types at runtime! It's a > typing bonanza! > > I suppose you could argue we're conflating types and classes. If so, it > sounds like you started this conversation with an ulterior motive and not > to learn about best practices for runtime type checking in Python. > >> -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-12 1:10 GMT-07:00 Lawrence D’Oliveiro : > On Thursday, August 11, 2016 at 8:33:41 AM UTC+12, Juan Pablo Romero > Méndez wrote: > > > I've been trying to find (without success so far) an example of a > situation > > where the dynamic features of a language like Python provides a clear > > advantage over languages with more than one type. > > I have used, and continue to use, both static and dynamic languages. > > With static languages, once a piece of code compiles without errors, you > have a slightly higher level of confidence in its correctness than with a > dynamic language. > > On the other hand, a dynamic language allows me to be much more > productive, because I have to write less code to begin with. > From your point of view, dynamic languages are more concise? > > The closest I can offer for an apples-to-apples comparison is PyCairo < > https://github.com/ldo/pycairo> versus Qahirah <https://github.com/ldo/ > qahirah>. Both are Python bindings for the Cairo graphics library; the > former is written in C as a Python extension module, the latter is done in > pure Python using ctypes. > > I didn’t write the former; I merely tried to rescue it from abandonment to > see if I could fill in a few more missing features. And what I found was, > it would be quicker to start again from scratch than to continue working on > it. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-14 7:29 GMT-07:00 Steven D'Aprano : > On Thu, 11 Aug 2016 06:33 am, Juan Pablo Romero Méndez wrote: > > > I've been trying to find (without success so far) an example of a > > situation where the dynamic features of a language like Python provides a > > clear advantage over languages with more than one type. > > Python has more than one type. Don't confuse dynamic typing with weak > typing > or untyped (typeless) languages. More on this below. > Sorry I was not clear, I was thinking in something along these lines: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ (Warning: his pov is very different from yours) > > I don't believe that you will find "an example of a situation..." as you > say > above. There is a clear situation in my mind: both Python and JavaScript (the dynamic langs I'm most familiar with) provide an easy to use `eval` function. None of the static langs I know provide such functionality (that I'm aware of). Personally I don't have any use for eval, so I was thinking in situations other than that. > It sounds like you are hope to find a clear example of "If you do > This, then dynamic languages are the Clear Winner". But I don't think you > will. Dynamic languages tend to produce clear productivity improvements > over statically typed languages, but of course this is only "typically" > true, not a guarantee that applies to every single programmer or project. > The very few research done on the subject seems to indicate otherwise (here's a link if you are interested in such topics https://www.functionalgeekery.com/episode-55-andreas-stefik/#t=18:14.448). > > Typically: > > - dynamic languages are less verbose; > - dynamic languages are faster to develop in; many organisations > prototype applications in Python (say) before re-writing it in > C++/Java/whatever; > - far less time spent fighting the compiler; > - dynamic languages often have fewer bugs, because it is easier to > reason about the code (no "undefined behaviour" like in C!) and > fewer lines of code to reason about; - but statically typed languages allow you to prove the absence > of certain types of bugs. > > The exception is if you try to write statically typed code in a dynamic > language. Then you get the worst of both styles of coding: the verbose, > heavyweight style of many static languages, but without the automated > correctness proofs, plus the performance costs of dynamic typing, but > without the rapid development. > > > > Regarding types and type systems, if you haven't already read this, you > should: > > https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ Thanks for the link. I don't have one to give back, but what I can suggest is this book: http://haskellbook.com/. It seems to me that many of your opinions come from using C++ / Java. If that's the case they are completely understandable. Despite their popularity they are by no means good representatives of languages with modern and powerful type systems. F# (dot.net), Haskell, Scala (JVM / Browser), or Elm (Browser) provide much better examples. > > > "Static typing" (e.g. Pascal, C, Java, Haskell) and "dynamic typing" (e.g. > Python, Javascript, Ruby, Lua) differ on when and how values are checked > for type-compatibility. > > "Strong" and "weak" typing are ends of a continuum. Nearly all languages > are > a little bit weak (they allow automatic coercions between numeric types) > but mostly strong (they don't automatically coerce integers to arrays). > Javascript, Perl and PHP are weaker than Python because they'll coerce > strings to numbers automatically and Python won't. > > I don't know many untyped languages apart from machine code or maybe > assembly. Perhaps Forth? (Maybe not -- some Forths include a separate > floating point stack as well as the usual stack.) Hypertalk treated > everything as strings. Tcl treats nearly everything as strings, although it > also has arrays. > > So, Python has types, and it is a mostly strong typed language. It will do > relatively few automatic coercions. > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the best way to minimize the need of run time checks?
2016-08-27 21:30 GMT-07:00 Steve D'Aprano : > On Sun, 28 Aug 2016 12:31 pm, Juan Pablo Romero Méndez wrote: > > > 2016-08-14 7:29 GMT-07:00 Steven D'Aprano : > > > >> On Thu, 11 Aug 2016 06:33 am, Juan Pablo Romero Méndez wrote: > >> > >> > I've been trying to find (without success so far) an example of a > >> > situation where the dynamic features of a language like Python > provides > >> > a clear advantage over languages with more than one type. > >> > >> Python has more than one type. Don't confuse dynamic typing with weak > >> typing or untyped (typeless) languages. More on this below. > >> > > > > > > Sorry I was not clear, I was thinking in something along these lines: > > > > > https://existentialtype.wordpress.com/2011/03/19/ > dynamic-languages-are-static-languages/ > > > > (Warning: his pov is very different from yours) > > It is a great example of somebody suffering from the problem that when the > only tool he has is a hammer, everything looks like an nail. > > He clearly is immersed in the world of formal type systems and understands > their power. But now he sees everything from that single perspective. > > Now it is true that speaking in full generality, classes and types refer to > different things. Or to be perhaps more accurate, *subclassing* and > *subtyping* are different things: > > http://c2.com/cgi/wiki?SubTypingAndSubClassing > > Many languages treat them the same, but fundamentally they are different. > > (Note: for veteran Python programmers who remember the language before > types > and classes where unified in version 2.2, this is not the same thing! Prior > to 2.2, both "types" and "classes" related to *subclassing*, albeit in a > negative way for the built-in types: they couldn't be subclassed.) > > But the author of this piece ignores that standard distinction and invents > his own non-standard one: to him, classes are merely different > representations of the same data. E.g. his example of complex numbers, > shown as Cartesian (x, y) values or polar (r, θ) values. These aren't two > different "kinds of things", but merely two different ways of representing > the same entity. > > That's not a good way to think about (say) Python lists and Python bools. > Lists and bools are in no way the same kind of entity (except in the most > general category of "they're both objects"). > > It's not even a very good way of thinking about complex numbers. > > Viewed from his perspective of type systems, the author makes what I call > the food processor error. Food processors, blenders and other similar > kitchen appliances are often advertised as having "five speeds", or ten > speeds, or however many the machine is capable of, usually labelled > as "chop", "dice", "whip", "puree", etc. And, far too often: "OFF". > > Since when is "off" a speed? If a blender that is turned off counts as a > blending speed, then a simple bowl is a "one speed blender". You put food > in the bowl, and it doesn't blend at all. That counts as "off" speed. > > The author is making the same mistake. He thinks that a language which > lacks > static typing counts as static typing. "Off" is a speed! "Bald" is a hair > colour! "Raw" is a way of cooking food! > > In truth though, static and dynamic typing are very different. The author > is > fooled because you can emulate *one* part of dynamic typing in a statically > typed system by adding one extra type, "Any", or "Duck Type", or whatever > you want to call it. The static checker can then ignore anything declared > as Any type. > > But deferring type checks to runtime is only part of dynamic typing. The > other fundamental difference is: > > - statically typed languages associate types to variables; > - dynamically typed languages associate types to values. > > This difference is more significant than the "run-time/compile-time" and > its > one which often confuses people. That's not surprising: if I say "x is an > int", that's ambiguous whether I'm referring to the variable x or the value > currently assigned to x. If you don't see the ambiguity, then you're seeing > it purely from the perspective of either static or dynamic typing. > > In static typing, I somehow associate the name "x" with a tag that > says "this may only be used with ints". Perhaps I have to declare it first, > like in C or
Re: What's the best way to minimize the need of run time checks?
2016-08-27 21:30 GMT-07:00 Steve D'Aprano :
> On Sun, 28 Aug 2016 12:31 pm, Juan Pablo Romero Méndez wrote:
>
> > 2016-08-14 7:29 GMT-07:00 Steven D'Aprano :
> >
> >> On Thu, 11 Aug 2016 06:33 am, Juan Pablo Romero Méndez wrote:
> >>
> >> > I've been trying to find (without success so far) an example of a
> >> > situation where the dynamic features of a language like Python
> provides
> >> > a clear advantage over languages with more than one type.
> >>
> >> Python has more than one type. Don't confuse dynamic typing with weak
> >> typing or untyped (typeless) languages. More on this below.
> >>
> >
> >
> > Sorry I was not clear, I was thinking in something along these lines:
> >
> >
> https://existentialtype.wordpress.com/2011/03/19/
> dynamic-languages-are-static-languages/
> >
> > (Warning: his pov is very different from yours)
>
> It is a great example of somebody suffering from the problem that when the
> only tool he has is a hammer, everything looks like an nail.
>
> He clearly is immersed in the world of formal type systems and understands
> their power. But now he sees everything from that single perspective.
>
> Now it is true that speaking in full generality, classes and types refer to
> different things. Or to be perhaps more accurate, *subclassing* and
> *subtyping* are different things:
>
> http://c2.com/cgi/wiki?SubTypingAndSubClassing
>
> Many languages treat them the same, but fundamentally they are different.
>
Oh, I don't think he is thinking in terms of OO "classes", I think he meant
two different "kinds" or "varieties" of values (although kind has a
technical meaning)
In TypeScript terms what he is saying can be described like this:
type Complex =
{ real: number, i: number }
| { r: number, φ: number}
const c1: Complex = { real: 1, i: 1 }
const c2: Complex = { r: 1, φ: 0.5 }
You have two values of the same type but different representation.
>
> (Note: for veteran Python programmers who remember the language before
> types
> and classes where unified in version 2.2, this is not the same thing! Prior
> to 2.2, both "types" and "classes" related to *subclassing*, albeit in a
> negative way for the built-in types: they couldn't be subclassed.)
>
> But the author of this piece ignores that standard distinction and invents
> his own non-standard one: to him, classes are merely different
> representations of the same data. E.g. his example of complex numbers,
> shown as Cartesian (x, y) values or polar (r, θ) values. These aren't two
> different "kinds of things", but merely two different ways of representing
> the same entity.
>
> That's not a good way to think about (say) Python lists and Python bools.
> Lists and bools are in no way the same kind of entity (except in the most
> general category of "they're both objects").
>
> It's not even a very good way of thinking about complex numbers.
>
> Viewed from his perspective of type systems, the author makes what I call
> the food processor error. Food processors, blenders and other similar
> kitchen appliances are often advertised as having "five speeds", or ten
> speeds, or however many the machine is capable of, usually labelled
> as "chop", "dice", "whip", "puree", etc. And, far too often: "OFF".
>
> Since when is "off" a speed? If a blender that is turned off counts as a
> blending speed, then a simple bowl is a "one speed blender". You put food
> in the bowl, and it doesn't blend at all. That counts as "off" speed.
>
> The author is making the same mistake. He thinks that a language which
> lacks
> static typing counts as static typing. "Off" is a speed! "Bald" is a hair
> colour! "Raw" is a way of cooking food!
>
> In truth though, static and dynamic typing are very different. The author
> is
> fooled because you can emulate *one* part of dynamic typing in a statically
> typed system by adding one extra type, "Any", or "Duck Type", or whatever
> you want to call it. The static checker can then ignore anything declared
> as Any type.
>
> But deferring type checks to runtime is only part of dynamic typing. The
> other fundamental difference is:
>
> - statically typed languages associate types to variables;
> - dynamically typed languages associate types to values.
>
> This difference is more significant than the "run-time/compile-time" and
> its
> one which often confuses people. That's not surpri
Re: What's the best way to minimize the need of run time checks?
2016-08-28 0:04 GMT-07:00 Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info>:
> On Sunday 28 August 2016 15:56, Juan Pablo Romero Méndez wrote:
>
> > 2016-08-27 21:30 GMT-07:00 Steve D'Aprano :
> [...]
> >> Now it is true that speaking in full generality, classes and types
> refer to
> >> different things. Or to be perhaps more accurate, *subclassing* and
> >> *subtyping* are different things:
> >>
> >> http://c2.com/cgi/wiki?SubTypingAndSubClassing
> >>
> >> Many languages treat them the same, but fundamentally they are
> different.
> >
> > Oh, I don't think he is thinking in terms of OO "classes", I think he
> meant
> > two different "kinds" or "varieties" of values (although kind has a
> > technical meaning)
>
> That's not quite right either. "Two different kinds or varieties" is what
> both
> subclassing and subtyping aim to describe, in different ways: e.g. dogs and
> cats are two different kinds of mammal.
>
> What you are describing here:
>
> > In TypeScript terms what he is saying can be described like this:
> >
> > type Complex =
> > { real: number, i: number }
> > | { r: number, φ: number}
> >
> > const c1: Complex = { real: 1, i: 1 }
> > const c2: Complex = { r: 1, φ: 0.5 }
> >
> > You have two values of the same type but different representation.
>
> seems to be more like what is called "variant record" in Pascal.
>
> http://www.freepascal.org/docs-html/ref/refsu16.html
>
>
> I'm not familiar with TypeScript. How does this work? If I say:
>
> const c1: Complex = {real: 1, imag: 1 }
>
> print c1.r
> print c1.φ
>
> what do I get? If r and φ are merely alternative names for "real" and
> "imag",
> that's not good enough. Given real=1, imag=1, then we need to get
> r=1.414213
> and φ = pi/4 without any extra effort on the part of the user.
>
>
Here's a more complete example:
type CartesianC = { real: number, i: number }
type PolarC = { r: number, φ: number}
type Complex = PolarC | CartesianC
const c1: Complex = { real: 1, i: 1 };
const c2: Complex = { r: 1, φ: 0.5 };
// This is called a Type Guard
function isCartesian(c: Complex): c is CartesianC {
return ( c).real !== undefined;
}
if(isCartesian(c1)) {
// c1 is a CartesianC here
c1.real
} else {
// and a PolarC here. Using c1.real is a compile error
c1.r
}
TypeScript doesn't support pattern matching so there's some boilerplate
involved: you need to define a TypeGuard so that inside the if branch TS
allows you to treat c1 as a CartesianC; within the else branch it is
treated as a PolarC.
>
> The point is, the complex number (1, 1) in Cartesian coordinates and
> (sqrt(2),
> pi/4) in polar coordinates aren't two different kinds of things, they are
> two
> different ways of writing the same value. Like writing 1A in hex and 26 in
> decimal. Somebody may choose to implement this as two different classes
> ("CartesianComplex" and "PolarComplex") but that's a limitation of their
> code,
> or of their language, it doesn't reflect a real difference between two
> different kinds of things.
>
Well conceptually you might think of c1 as the abstract representation of a
complex number but at runtime they have very different constitutions.
>
> Another way to put it:
>
> If you were programming a first person shooter game, you might choose each
> of
> the enemies as an object. Let's say you have an enemy called the Grue. You
> can
> view the Grue from the front or from the back, depending on which way it is
> standing when you see it. Would you implement this as two different
> classes?
>
> GrueSeenFromFront
>
> GrueSeenFromBack
>
> I should hope not. It's the same object, the same Grue, it just looks
> different
> depending on which way you approach it.
>
>
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
What do you guys think about adding a method "to_json"
Hello, What do you guys think about adding a method "to_json" to dictionaries and sequence types? Perhaps through a module import? Regards, Juan Pablo -- http://mail.python.org/mailman/listinfo/python-list
Compiling and installing python 2.5.2 with Visual C++ 2008
Hello all, I need to compile python myself because of a module (pivy). So I downloaded MS Visual C++ 2008 express edition. It apparently compiled fine but I don't know how to install it to recreate the standard distribution. In linux i'd take "make install", but on windows? Regards, Juan Pablo -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling and installing python 2.5.2 with Visual C++ 2008
Thanks! I'm having trouble with msi.py, so I'll better try python 2.6 The problem is with Pivy (openinventor bindings to python), it refuses to compile. It says: - ... error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing "-c mingw32" to setup.py. - And because I've been compiling everything needed by pivy (Coin, Qt, SoQt, PyQt) with visual c++ 8, I decided to recompile python itself. Juan Pablo 2008/12/9 Gabriel Genellina <[EMAIL PROTECTED]>: > En Tue, 09 Dec 2008 11:32:46 -0200, Juan Pablo Romero Méndez > <[EMAIL PROTECTED]> escribió: > >> I need to compile python myself because of a module (pivy). So I >> downloaded MS Visual C++ 2008 express edition. It apparently compiled >> fine but I don't know how to install it to recreate the standard >> distribution. In linux i'd take "make install", but on windows? > > See Tools/msi/README.txt > BTW, do you really have to recompile Python? Unless the project requires > some specific compiler flags incompatible with the standard build, usually > there is no need to recompile Python just because of an extension. > > -- > Gabriel Genellina > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Mathematica 7 compares to other languages
In R:
norm = function(v) v/sqrt(sum(v^2))
:)
Juan Pablo
2008/12/10 Arnaud Delobelle <[EMAIL PROTECTED]>:
> "Dotan Cohen" <[EMAIL PROTECTED]> writes:
>
>> 2008/12/10 <[EMAIL PROTECTED]>:
>>> On Dec 5, 9:51 am, Xah Lee <[EMAIL PROTECTED]> wrote:
For those of you who don't know linear algebra but knows coding, this
means, we want a function whose input is a list of 3 elements say
{x,y,z}, and output is also a list of 3 elements, say {a,b,c}, with
the condition that
a = x/Sqrt[x^2+y^2+z^2]
b = y/Sqrt[x^2+y^2+z^2]
c = z/Sqrt[x^2+y^2+z^2]
>>>
In lisp, python, perl, etc, you'll have 10 or so lines. In C or Java,
you'll have 50 or hundreds lines.
>>>
>>> Ruby:
>>>
>>> def norm a
>>> s = Math.sqrt(a.map{|x|x*x}.inject{|x,y|x+y})
>>> a.map{|x| x/s}
>>> end
>>
>> If someone doesn't counter with a Python one-liner then I'm going to
>> port that to brainfuck.
>
> def unit(v):
>return map((sum(map(lambda x:x*x, v))**0.5).__rdiv__, v)
>
> The hard bit was to make it less readable than the Ruby version ;)
>
> --
> Arnaud
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compiling and installing python 2.5.2 with Visual C++ 2008
Finally installed Python 2.6, which is compiled with visual C++ 2008, and all my problems went away. Thanks to all, Juan Pablo 2008/12/10 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> - >> ... >> error: Python was built with Visual Studio 2003; >> extensions must be built with a compiler than can generate compatible >> binaries. >> Visual Studio 2003 was not found on this system. If you have Cygwin >> installed, >> you can try compiling with MingW32, by passing "-c mingw32" to setup.py. >> - >> >> And because I've been compiling everything needed by pivy (Coin, Qt, >> SoQt, PyQt) with visual c++ 8, I decided to recompile python itself. > > There isn't a real installation procedure. You just copy the files by > hand into the places where they belong. In the specific case, > overwriting all .exe, .dll, and .pyd files in an installed directory > should be sufficient. > > Regards, > Martin > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
eval() and global variables
Hello,
Suppose this function is given:
def f(x,y):
return x+y+k
Is it possible to somehow assign a value to k without resorting to
making k global?
I'm thinking something like this:
eval("f(1,1)", {"f":f, "k":1})
Or even better, something like:
def g(k):
return f
g(1)(1,1) ==> 3
Regards,
Juan Pablo
--
http://mail.python.org/mailman/listinfo/python-list
Re: eval() and global variables
P
2008/12/16 :
> Quoth "=?ISO-8859-1?Q?Juan_Pablo_Romero_M=E9ndez?=" :
>> Hello,
>>
>> Suppose this function is given:
>>
>> def f(x,y):
>> return x+y+k
>>
>> Is it possible to somehow assign a value to k without resorting to
>> making k global?
>>
>> I'm thinking something like this:
>>
>> eval("f(1,1)", {"f":f, "k":1})
>>
>> Or even better, something like:
>>
>> def g(k):
>> return f
>>
>> g(1)(1,1) ==> 3
>
>>>> def g(k):
>... def f(x,y):
>... return x+y+k
>... return f
>...
>>>> g(1)(1,1)
>3
>
> But what's the use case? The above might not satisfy it.
I'm making a 3D plotting library (yet another!), but with facilities
to graph "parametrized" surfaces. The current code is used like this:
...
m = Mesh((-1,1),(-1,1))
m.addQuad( lambda v,w, x, y: (x, y, - w * x**2 - v * y**2 ) )
m.addParameter(('v',0,1))
m.addParameter(('w',0,1))
...
Which plots the surface using OpenInventor and add sliders for each
parameter. I'm using QTimeLine, so the slider can be animated, and on
each step the mesh is recalculated, thus deforming the mesh on real
time.
What I'd like to do is something like this:
...
m = Mesh((-1,1),(-1,1))
m.addQuad( lambda x, y: (x, y, - w * x**2 - v * y**2 ) )
...
and have the code automatically figure out that w and v are free
variables and generate the right code.
Right now I can catch w and v (using NameError), but can't figure out
how to get python to assign values to w and v (other than declaring
them globals).
My code needs a function g(x,y) which does not depend on w and v.
Given this function:
func = lambda v,w, x, y: (x, y, - w * x**2 - v * y**2 )
I use functools.partial, as:
g = partial(func,1,1)
and then use g to actually generate the mesh for each value of v and w.
Juan Pablo
>
> --RDM
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: eval() and global variables
The hack given by Peter works fine, except in this case: >>> def (fn): ... f2 = lambda x,y:(x,y,fn(x,y)) ... function = type(f2) ... f3 = function(f2.func_code,dict()) ... print f3 ... >>> (lambda x,y:x+y) Traceback (most recent call last): File "", line 1, in File "", line 4, in TypeError: arg 5 (closure) must be tuple >>> Strange... 2008/12/17 Peter Otten <__pete...@web.de>: > Juan Pablo Romero Méndez wrote: > >> Suppose this function is given: >> >> def f(x,y): >> return x+y+k >> >> >> Is it possible to somehow assign a value to k without resorting to >> making k global? > > You can replace the function's global dictionary: > >>>> def f(x, y): > ... return x+y+k > ... >>>> function = type(f) >>>> function(f.func_code, dict(k=1))(2, 3) > 6 >>>> k > Traceback (most recent call last): > File "", line 1, in > NameError: name 'k' is not defined > > This is a hack, of course. > > Peter > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing GUI applications
PyQt: http://www.riverbankcomputing.co.uk/software/pyqt/intro All the benefits of Qt: multiplataform, excellent documentation, great API, visual widget designer, etc, etc. For the coding itself, I use netbeans + python plugin. Regards, Juan Pablo 2009/6/21 Chris Rebert : > On Sat, Jun 20, 2009 at 6:37 PM, Grant Ito wrote: >> Hi everyone. >> >> I'm looking to find out what people are using for an open source wysiwyg GUI >> developer. I'm running both Linux and Windows but prefer to do my >> development in Linux. I've got the most experience with Tkinter but am >> willing to look at wxPython and Tix as well. > > GTK: Glade - http://glade.gnome.org/ > WxPython: Boa Constructor - http://boa-constructor.sourceforge.net/ > > Cheers, > Chris > -- > http://blog.rebertia.com > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt GUI
I use OpenInventor (Coin3d) which have a python binding called "pivy". It works great. http://pivy.coin3d.org/ Juan Pablo 2009/7/8 Helvin : > Hi experts! > > I'm developing a GUI for a software using PyQT, and need 3D > visualization. Should I use PyOpenGL or VTK? > I understand that the PyQt package comes with a opengl module. What > else would I need? I think I need to download opengl. but how? where? > I have VTK and pyVTK installed, but I don't know how to use it in my > code, as when I run it, an error says it can't find the vtk module. > > Help would be so appreciated! > Helvin > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
