Re: Encapsulation, inheritance and polymorphism
On Tuesday, July 17, 2012 12:39:53 PM UTC-7, Mark Lawrence wrote: I would like to spend more time on this thread, but unfortunately the 44 ton artic carrying Java in a Nutshell Volume 1 Part 1 Chapter 1 Paragraph 1 Sentence 1 has just arrived outside my abode and needs unloading :-) That reminds me of a remark I made nearly 10 years ago: Well, I followed one friend's advice and investigated Java, perhaps a little too quickly. I purchased Ivor Horton's _Beginning_Java_2_ book. It is reasonably well-written. But how many pages did I have to read before I got through everything I needed to know, in order to read and write files? Four hundred! I need to keep straight detailed information about objects, inheritance, exceptions, buffers, and streams, just to read data from a text file??? I haven't actually sat down to program in Java yet. But at first glance, it would seem to be a step backwards even from the procedural C programming that I was doing a decade ago. I was willing to accept the complexity of the Windows GUI, and program with manuals open on my lap. It is a lot harder for me to accept that I will need to do this in order to process plain old text, perhaps without even any screen output. https://groups.google.com/d/topic/bionet.software/kk-EGGTHN1M/discussion Some things never change! :^) -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/08/2012 06:21, Robert Miles wrote: On 7/23/2012 11:18 AM, Albert van der Horst wrote: In article 5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: SNIP. Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Example from recipee's: Stirr until the egg white is stiff. Alternative: Stirr egg white for half an hour, but if the egg white is stiff keep your spoon still. (Cooking is not my field of expertise, so the wording may not be quite appropriate. ) -- Steven Groetjes Albert Note that you forgot applying enough heat to do the cooking. Surely the first check is your filing system to make sure that you've paid the utilties bills so you've got gas and or electricity to apply the heat. Either that or you hire Ray Mears to produce the spark needed to light the fire :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/08/12 09:55, Mark Lawrence wrote: On 19/08/2012 06:21, Robert Miles wrote: On 7/23/2012 11:18 AM, Albert van der Horst wrote: In article 5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: [snip] that functions must only have one exit? [snip[ Surely the first check is your filing system to make sure that you've paid the utilties bills so you've got gas and or electricity to apply the heat. Either that or you hire Ray Mears to produce the spark needed to light the fire :) I was wondering how long it would be ... lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/08/2012 12:50, lipska the kat wrote: On 19/08/12 09:55, Mark Lawrence wrote: On 19/08/2012 06:21, Robert Miles wrote: On 7/23/2012 11:18 AM, Albert van der Horst wrote: In article 5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: [snip] that functions must only have one exit? [snip[ Surely the first check is your filing system to make sure that you've paid the utilties bills so you've got gas and or electricity to apply the heat. Either that or you hire Ray Mears to produce the spark needed to light the fire :) I was wondering how long it would be ... lipska Six days shalt thou labour... :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/23/2012 11:18 AM, Albert van der Horst wrote: In article 5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: SNIP. Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Example from recipee's: Stirr until the egg white is stiff. Alternative: Stirr egg white for half an hour, but if the egg white is stiff keep your spoon still. (Cooking is not my field of expertise, so the wording may not be quite appropriate. ) -- Steven Groetjes Albert Note that you forgot applying enough heat to do the cooking. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In article 5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: SNIP. Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Example from recipee's: Stirr until the egg white is stiff. Alternative: Stirr egg white for half an hour, but if the egg white is stiff keep your spoon still. (Cooking is not my field of expertise, so the wording may not be quite appropriate. ) -- Steven Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, Jul 24, 2012 at 2:18 AM, Albert van der Horst alb...@spenarnc.xs4all.nl wrote: Example from recipee's: Stirr until the egg white is stiff. Alternative: Stirr egg white for half an hour, but if the egg white is stiff keep your spoon still. (Cooking is not my field of expertise, so the wording may not be quite appropriate. ) Method. Take egg white from refrigerator. Put egg white into mixing bowl. Stir for 30 minutes. Stir the egg white. Stir the egg white until stirred. That's valid code, incidentally. Not Python code, but it is executable. And it includes a useless count-down-to-zero loop. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In article oc-dnuqkg91pgpbnnz2dnuvz5vgdn...@giganews.com, Erik Max Francis m...@alcyone.com wrote: SNIP Anything's trivial to write down. Just say the number such that ... and you've written it down. Even numbers that aren't really numbers, such as transfinite cardinals! Now it isn't trivial to write down. It has been proven (of course in an anti-intuitionistic 1] , Cantor-universe) that there is always a larger cardinal, and that there is no consistent way to write them down. In other ways, you have to keep inventing new notations, hardly a trivial matter. See also Hofstaedter: Goedel, Escher, Bach. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ Groetjes Albert 1] The likes of Brouwer found these silly exercises.) -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/20/2012 02:05 AM, Virgil Stokes wrote: On 20-Jul-2012 10:27, Steven D'Aprano wrote: The fellow looked relived and said Oh thank god, I thought you said *million*! How does this relate to the python list? It's also a seriously old joke. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Jabber erikmaxfrancis She's your moon, she's your sun / She could even be the one -- Nik Kershaw -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/20/2012 03:28 AM, BartC wrote: Erik Max Francis m...@alcyone.com wrote in message news:gskdnwoqpkoovztnnz2dnuvz5s2dn...@giganews.com... On 07/20/2012 01:11 AM, Steven D'Aprano wrote: On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote: I'm reminded of Graham's Number, which is so large that there aren't enough molecules in the universe to write it out as a power tower a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the provable upper bound to a question to which experts in the field thought the most likely answer was ... six. (The bounds have since been reduced: the lower bound is now 13, and the upper bound is *much* smaller than Graham's Number but still inconceivably ginormous.) You don't even need to go that high. Even a run-of-the-mill googol (10^100) is far larger than the total number of elementary particles in the observable Universe. But you can write it down, even as a straightforward number, without any problem. Perhaps a googolplex (10^10^100 iirc) would be difficult to write it down in full, but I have just represented it as an exponent with little difficulty. These bigger numbers can't be written down, because there will never be enough material, even using multiple systems of exponents. But that's true for precisely the same reason as what I said. If you're going to write a number down in standard format (whatever the base), then the number of digits needed scales as the logarithm of the number (again, whatever the base). log_10 10^100 is trivially 100, so a rough order of magnitude in that form is easy to write down. But the log_10 10^10^100 is 10^100 = a googol, which is already more than the number of elementary particles in the observable Universe. (A few years ago the biggest number I'd heard of was Skewes' Number (something like 10^10^10^34), but even that is trivial to write using conventional exponents as I've just shown. Graham's Number is in a different class altogether.) Anything's trivial to write down. Just say the number such that ... and you've written it down. Even numbers that aren't really numbers, such as transfinite cardinals! -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Jabber erikmaxfrancis She's your moon, she's your sun / She could even be the one -- Nik Kershaw -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, 19 Jul 2012 09:06:45 -0400, Roy Smith wrote: Heh. This reminds me of one of my current pet peeves. I've run across documentation for more than one Python project (django is the one that comes to mind, but I'm sure there's others) which misuse words like set and list. They're often used in the generic sense of a collection of things, but they're also the names of specific Python data types. It can sometimes get confusing trying to figure out which meaning they intended. Now that is confusing! Writing good documentation is *hard*. I often end up writing more documentation than code, sometimes by a factor of two. Fortunately I love to write. As may be obvious. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 3:01 PM, John Gordon gor...@panix.com wrote: In mailman.2317.1342730879.4697.python-l...@python.org Dennis Lee Bieber wlfr...@ix.netcom.com writes: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. Actually actually it means *uniformity* of heat, i.e. that the entire universe is in thermodynamic equilibrium and so it is impossible to perform work. So heat death is expected regardless of whether the universe ultimately collapses or expands indefinitely. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 5:01 PM, John Gordon gor...@panix.com wrote: Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. But it doesn't mean low temperature! The term is agnostic as to what the temperature of the universe will be. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote: On 07/19/12 13:28, Chris Angelico wrote: On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase python.l...@tim.thechases.com wrote: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) I'd be more worried about the heat death of your computer, it's likely to be sooner. How many people have access to a computer that'll still be running in ten years, much less a thousand? Just putting a maximum bound on the problem, providing a time-frame in which I can be fairly certain that the program will have terminated. :-) I'm reminded of Graham's Number, which is so large that there aren't enough molecules in the universe to write it out as a power tower a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the provable upper bound to a question to which experts in the field thought the most likely answer was ... six. (The bounds have since been reduced: the lower bound is now 13, and the upper bound is *much* smaller than Graham's Number but still inconceivably ginormous.) http://en.wikipedia.org/wiki/Graham%27s_number -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote: Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. The second law of thermodynamics states that energy tends to go from higher states to lower, with heat being the very lowest. It's possible to do work using (say) kinetic energy, and in the process, some of that energy becomes heat. It's also possible to do work with any difference in temperature (eg Stirling engines), so the state of the universe in which it's no longer possible to do any work will be one in which all energy is heat and everything's at the same temperature. That doesn't mean a lack of heat; in fact, it implies that there'll be rather more heat than there now is, because we currently have a whole lot of chemical energy available to be used. Yes, but the point is, that heat will be *incredibly* diffuse, essentially spread over the entire universe, which will be MUCH bigger than it is now, and hence the temperature will be low even though the total amount of heat will be high. The average temperature of the universe now is about 2.7 degrees above absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual hotspots reaching into millions of degrees or higher. By the time the last of the stars burn out, the average temperature will be a minuscule fraction of a degree above absolute zero, and the only hotspots will be the slowly cooling neutron stars. But in any case, that's a long way off... I once went to an astronomy lecture where the lecturer was talking about the eventual death of the sun. He said, In about 10 billion years, the sun will consume almost all of its fuel. It will cool and expand into a red giant, and the earth will be engulfed by the expanded sun and destroyed. This fellow sitting next to me got all agitated, stood up and cried out, Does the government know about this? We have to do something! The lecturer said Don't worry sir, there's no need to panic, this won't happen for billions of years. The fellow looked relived and said Oh thank god, I thought you said *million*! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/07/2012 22:13, Ian Kelly wrote: On Thu, Jul 19, 2012 at 3:01 PM, John Gordon gor...@panix.com wrote: In mailman.2317.1342730879.4697.python-l...@python.org Dennis Lee Bieber wlfr...@ix.netcom.com writes: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. Actually actually it means *uniformity* of heat, i.e. that the entire universe is in thermodynamic equilibrium and so it is impossible to perform work. So heat death is expected regardless of whether the universe ultimately collapses or expands indefinitely. All of this will pale into complete insignificance provided that England beat South Africa in the current cricket test match series and retain their world no.1 ranking. Of course if they lose the universe will collapse immediately or expand so far that it tears itself to tiny little pieces. Even The Ashes won't survive, something I should perhaps take up with the MCC. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/20/2012 01:11 AM, Steven D'Aprano wrote: On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote: On 07/19/12 13:28, Chris Angelico wrote: On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase python.l...@tim.thechases.com wrote: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) I'd be more worried about the heat death of your computer, it's likely to be sooner. How many people have access to a computer that'll still be running in ten years, much less a thousand? Just putting a maximum bound on the problem, providing a time-frame in which I can be fairly certain that the program will have terminated. :-) I'm reminded of Graham's Number, which is so large that there aren't enough molecules in the universe to write it out as a power tower a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the provable upper bound to a question to which experts in the field thought the most likely answer was ... six. (The bounds have since been reduced: the lower bound is now 13, and the upper bound is *much* smaller than Graham's Number but still inconceivably ginormous.) You don't even need to go that high. Even a run-of-the-mill googol (10^100) is far larger than the total number of elementary particles in the observable Universe. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Jabber erikmaxfrancis I think it is safe to say that no one understands quantum mechanics. -- Richard P. Feynman -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 20-Jul-2012 10:27, Steven D'Aprano wrote: On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote: Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. The second law of thermodynamics states that energy tends to go from higher states to lower, with heat being the very lowest. It's possible to do work using (say) kinetic energy, and in the process, some of that energy becomes heat. It's also possible to do work with any difference in temperature (eg Stirling engines), so the state of the universe in which it's no longer possible to do any work will be one in which all energy is heat and everything's at the same temperature. That doesn't mean a lack of heat; in fact, it implies that there'll be rather more heat than there now is, because we currently have a whole lot of chemical energy available to be used. Yes, but the point is, that heat will be *incredibly* diffuse, essentially spread over the entire universe, which will be MUCH bigger than it is now, and hence the temperature will be low even though the total amount of heat will be high. The average temperature of the universe now is about 2.7 degrees above absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual hotspots reaching into millions of degrees or higher. By the time the last of the stars burn out, the average temperature will be a minuscule fraction of a degree above absolute zero, and the only hotspots will be the slowly cooling neutron stars. But in any case, that's a long way off... I once went to an astronomy lecture where the lecturer was talking about the eventual death of the sun. He said, In about 10 billion years, the sun will consume almost all of its fuel. It will cool and expand into a red giant, and the earth will be engulfed by the expanded sun and destroyed. This fellow sitting next to me got all agitated, stood up and cried out, Does the government know about this? We have to do something! The lecturer said Don't worry sir, there's no need to panic, this won't happen for billions of years. The fellow looked relived and said Oh thank god, I thought you said *million*! How does this relate to the python list? This mailing list is a general discussion list for the Python programming language. --- from http://mail.python.org/mailman/listinfo/python-list/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Erik Max Francis m...@alcyone.com wrote in message news:gskdnwoqpkoovztnnz2dnuvz5s2dn...@giganews.com... On 07/20/2012 01:11 AM, Steven D'Aprano wrote: On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote: I'm reminded of Graham's Number, which is so large that there aren't enough molecules in the universe to write it out as a power tower a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the provable upper bound to a question to which experts in the field thought the most likely answer was ... six. (The bounds have since been reduced: the lower bound is now 13, and the upper bound is *much* smaller than Graham's Number but still inconceivably ginormous.) You don't even need to go that high. Even a run-of-the-mill googol (10^100) is far larger than the total number of elementary particles in the observable Universe. But you can write it down, even as a straightforward number, without any problem. Perhaps a googolplex (10^10^100 iirc) would be difficult to write it down in full, but I have just represented it as an exponent with little difficulty. These bigger numbers can't be written down, because there will never be enough material, even using multiple systems of exponents. (A few years ago the biggest number I'd heard of was Skewes' Number (something like 10^10^10^34), but even that is trivial to write using conventional exponents as I've just shown. Graham's Number is in a different class altogether.) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 20/07/12 11:05:09, Virgil Stokes wrote: On 20-Jul-2012 10:27, Steven D'Aprano wrote: On Fri, 20 Jul 2012 08:20:57 +1000, Chris Angelico wrote: Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. The second law of thermodynamics states that energy tends to go from higher states to lower, with heat being the very lowest. It's possible to do work using (say) kinetic energy, and in the process, some of that energy becomes heat. It's also possible to do work with any difference in temperature (eg Stirling engines), so the state of the universe in which it's no longer possible to do any work will be one in which all energy is heat and everything's at the same temperature. That doesn't mean a lack of heat; in fact, it implies that there'll be rather more heat than there now is, because we currently have a whole lot of chemical energy available to be used. Yes, but the point is, that heat will be *incredibly* diffuse, essentially spread over the entire universe, which will be MUCH bigger than it is now, and hence the temperature will be low even though the total amount of heat will be high. The average temperature of the universe now is about 2.7 degrees above absolute zero (i.e. 2.7 K, -270.45 C or -454.81 F), with individual hotspots reaching into millions of degrees or higher. By the time the last of the stars burn out, the average temperature will be a minuscule fraction of a degree above absolute zero, and the only hotspots will be the slowly cooling neutron stars. But in any case, that's a long way off... I once went to an astronomy lecture where the lecturer was talking about the eventual death of the sun. He said, In about 10 billion years, the sun will consume almost all of its fuel. It will cool and expand into a red giant, and the earth will be engulfed by the expanded sun and destroyed. This fellow sitting next to me got all agitated, stood up and cried out, Does the government know about this? We have to do something! The lecturer said Don't worry sir, there's no need to panic, this won't happen for billions of years. The fellow looked relived and said Oh thank god, I thought you said *million*! How does this relate to the python list? This thread is as coherent as a typical episode of Monty Python's Flying Circus :-) -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Jul 19, 6:34 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote: Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. Um, yes? Its not so much a question of language as in programming as language as in layman-speak. One characteristic with our field is that we take ordinary words and then distort them so much the original meaning is completely lost. Take 'computer' for example. For Turing a computer was a mathematician doing a computation with a pen and paper. He then showed how to de-skill the mathematician so much that a machine could do what he was doing. In trying that he also hit upon the limits of such 'de-skilling' -- human-computers routinely detect infinite loops, whereas machine-computers can never do so (in full generality). Ironically the important lesson is lost and today 'computer' is synonymous with machine. Here is Dijkstra on similar distortions with 'user' and 'intelligent': http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html 'Object' (and OO) are similar messes. In layman-speak and object is well, a thing. - subject to space-laws like can only exist at one place at a time, there cannot be two objects at the same place and time etc. - subject to time-laws like coming into existence at some time and going out at some other - connotes inanimateness unlike other 'creatures' or 'beings'. When this metaphor works (for example as in guis and simulation) then we have success-stories like smalltalk and simula. When it doesn't the success is poorer. eg a programmer writing math software in/on a OO system may for example 'clone' a matrix. This may be good science-fiction; its bad math. And one of the most pervasive (and stupidist) metaphors is the parent- child relation of classes. Just for the record, in the normal world 'creatures/beings' reproduce and therefore inherit. Objects dont. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/18/2012 10:40 AM, Lipska the Kat wrote:
fact ... and I have never been forced to admit that I don't know what I
wrote six months ago.
That is an explicit objective of Python's design.
Python looks like an interesting language and I will certainly spend
time getting to know it but at the moment it seems to me that calling it
an Object Oriented language is just plain misleading.
I just call it object-based and let be done with it, as I have no
interest in arguing 'Object Oriented'.
What perhaps *you* need to know, given your background, is that nearly
all syntax and most builtin callables wrap special method calls that can
be defined on user classes.
'a + b' is executed as something like
try:
return a.__add__(b) # or the C type slot equivalent
except: # not sure what is actually caught
try:
return b.__radd__(a) # r(everse)add
except: # ditto
raise TypeError(unsupported operand type(s) for +: {} and
{}.format(a, b))
[Syntax exceptions: =, and, or]
'len(x)' calls x.__len__ and checks that the return value can be
interpreted as an integer (I believe that means that it is an int or has
an __index__ method, so that it can be used as a sequence index) and
that its value is = 0.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/07/12 07:09, rusi wrote: On Jul 19, 6:34 am, Steven D'Apranosteve +comp.lang.pyt...@pearwood.info wrote: On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote: Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. Um, yes? Its not so much a question of language as in programming as language as in layman-speak. One characteristic with our field is that we take ordinary words and then distort them so much the original meaning is completely lost. Take 'computer' for example. For Turing a computer was a mathematician doing a computation with a pen and paper. He then showed how to de-skill the mathematician so much that a machine could do what he was doing. In trying that he also hit upon the limits of such 'de-skilling' -- human-computers routinely detect infinite loops, whereas machine-computers can never do so (in full generality). Ironically the important lesson is lost and today 'computer' is synonymous with machine. Here is Dijkstra on similar distortions with 'user' and 'intelligent': http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html 'Object' (and OO) are similar messes. Well this is all very interesting. The terminology is quite concise if you allow it to be Take An Object is an instance of a Class A Class describes a human concept (be it concrete like a 'Parrot' or more abstract like a 'Session') an Object is an actual representation of that concept that exists in the memory of a computer (what else should we call it). Objects don't exist in the mind of a human, concepts do. A class is a way of representing that concept so that other humans can understand it. That's it, really, there is no more, anything else is implementation. In layman-speak and object is well, a thing. But we are not talking in 'layman-speak' we are discussing concepts that are familiar to us in the 'language of the domain' at least I though we were. Academic twiddling with the distorted meaning of words spun by vested interests is all very interesting I'm sure but doesn't really advance the discussion does it? - subject to space-laws like can only exist at one place at a time, there cannot be two objects at the same place and time etc. - subject to time-laws like coming into existence at some time and going out at some other - connotes inanimateness unlike other 'creatures' or 'beings'. Well here I have to agree with you. Anyone who invents a 'Person' Class should be dismissed forthwith. Parrots are OK though. When this metaphor works (for example as in guis and simulation) then we have success-stories like smalltalk and simula. When it doesn't the success is poorer. eg a programmer writing math software in/on a OO system may for example 'clone' a matrix. This may be good science-fiction; its bad math. And one of the most pervasive (and stupidist) metaphors is the parent- child relation of classes. Just for the record, in the normal world 'creatures/beings' reproduce and therefore inherit. But we are not talking about the 'real world' are we, we are talking about representing complex interacting human concepts in a way that can be understood by humans and translated into a form that can be executed on a binary machine Objects dont. Well they do, it's a fact, you can call a method on a sub class that only exists in the super class. What else would you call it. Well it's been fun but I have bills to pay so I suppose I'd better do some work. TTFN -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote: Its not so much a question of language as in programming as language as in layman-speak. One characteristic with our field is that we take ordinary words and then distort them so much the original meaning is completely lost. All technical fields have jargon. Those jargon terms are often more precise than the ordinary terms they are derived from, or have a slightly different meaning, or both. This is not unique to programming, nor is it anything to be disturbed by. Words change. What matters is whether the new meanings cause confusion or clarity. Take 'computer' for example. For Turing a computer was a mathematician doing a computation with a pen and paper. He then showed how to de-skill the mathematician so much that a machine could do what he was doing. In trying that he also hit upon the limits of such 'de-skilling' -- human-computers routinely detect infinite loops, whereas machine-computers can never do so (in full generality). Do they really? I doubt that. Human-computers *sometimes* detect infinite loops, but there's no evidence that they can detect ∞-loops in full generality, or even that they are better at it than electrical computers. In fact, the sheer number of accidental ∞-loops programmed by human beings suggests that people *cannot* routinely detect them, at least not without special training, and even then not *routinely*. Generally people detect ∞-loops with an extremely simple-minded heuristic: if the loop hasn't finished by now, it will never finish. The fact that we don't, as a general rule, program our computers to detect ∞-loops does not mean that they cannot do so at least as well as humans, and probably better, when we bother to program them to. For example, both ML and Haskell can, under some circumstances, report a type-error for an infinite loop, *at compile time*. http://static.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a If you think that people can routinely detect infinite loops, then perhaps you would care to tell me whether this is an infinite loop or not: i = 1 while not is_perfect(i): i += 2 print odd perfect number discovered where is_perfect() returns True if the integer argument is perfect, and False otherwise. http://mathworld.wolfram.com/PerfectNumber.html http://mathworld.wolfram.com/OddPerfectNumber.html [...] 'Object' (and OO) are similar messes. In layman-speak and object is well, a thing. Define thing. Is a cloud a thing? What about a fog bank? An ocean? A desert? The atmosphere? Is the paint on your car a thing? I have an axe that has been passed down for generations through my family, from my father, his father before him, and his father, and his father before him. Occasionally we replace the handle, or put on a new head, but that axe is almost as good as the day my great-great- grandfather made it. Is that axe a thing? Just because laymen toss around a word, doesn't mean that it is a well- defined, meaningful word. When it doesn't the success is poorer. eg a programmer writing math software in/on a OO system may for example 'clone' a matrix. This may be good science-fiction; its bad math. In what way is it bad maths? And one of the most pervasive (and stupidist) metaphors is the parent- child relation of classes. Just for the record, in the normal world 'creatures/beings' reproduce and therefore inherit. Incorrect. In the normal world, inherit is used for at least four senses: 1) to inherit wealth, property, a title, debts etc. from an ancestor upon their death; 2) to receive or take by birth, to have by nature, physical or mental qualities, e.g. he inherited his tendency to melancholy from his father; 3) to come into possession of, e.g. the meek shall inherit the earth; 4) to receive from a predecessor, e.g. the Prime Minister has inherited an economy in dire straits. It is clear that the sense of inheritance used in OO programming is sense #2, to have by nature. Objects dont. Irrelevant. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In article 500804cc$0$29978$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote: Its not so much a question of language as in programming as language as in layman-speak. One characteristic with our field is that we take ordinary words and then distort them so much the original meaning is completely lost. All technical fields have jargon. Those jargon terms are often more precise than the ordinary terms they are derived from, or have a slightly different meaning, or both. Heh. This reminds me of one of my current pet peeves. I've run across documentation for more than one Python project (django is the one that comes to mind, but I'm sure there's others) which misuse words like set and list. They're often used in the generic sense of a collection of things, but they're also the names of specific Python data types. It can sometimes get confusing trying to figure out which meaning they intended. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Jul 19, 1:56 pm, Lipska the Kat lip...@lipskathekat.com wrote: Academic twiddling with the distorted meaning of words spun by vested interests is all very interesting I'm sure but doesn't really advance the discussion does it? Well lets back up the discussion a bit. You coming from a Java background have one view of what OO means. Others coming from a python background have a different view. In particular you said: Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading. On 19/07/12 07:09, rusi wrote: In layman-speak and object is well, a thing. But we are not talking in 'layman-speak' we are discussing concepts that are familiar to us in the 'language of the domain' at least I though we were. And one of the most pervasive (and stupidist) metaphors is the parent- child relation of classes. Just for the record, in the normal world 'creatures/beings' reproduce and therefore inherit. But we are not talking about the 'real world' are we, we are talking about representing complex interacting human concepts in a way that can be understood by humans and translated into a form that can be executed on a binary machine So when multiple technical understandings are in conflict it seems reasonable to find a frame in which the different viewpoints could resolve. The ultimate such frame is the completely de-jargonized frame ie laymanspeak. [How far one can/should go toward that ultimate is another quesion] -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: For example, both ML and Haskell can, under some circumstances, report a type-error for an infinite loop, *at compile time*. ... and in Charity all programs are guaranteed to terminate. Of course it's not Turing complete. http://en.wikipedia.org/wiki/Charity_(programming_language) -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
If you think that people can routinely detect infinite loops, then perhaps you would care to tell me whether this is an infinite loop or not: i = 1 while not is_perfect(i): i += 2 print odd perfect number discovered where is_perfect() returns True if the integer argument is perfect, and False otherwise. Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase python.l...@tim.thechases.com wrote: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) I'd be more worried about the heat death of your computer, it's likely to be sooner. How many people have access to a computer that'll still be running in ten years, much less a thousand? And while a thousand years is extremely large, it still falls pitifully short of infinity[1], or even the heat death of the universe. ChrisA [1] http://tools.ietf.org/html/rfc2795 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/19/12 13:28, Chris Angelico wrote: On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase python.l...@tim.thechases.com wrote: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) I'd be more worried about the heat death of your computer, it's likely to be sooner. How many people have access to a computer that'll still be running in ten years, much less a thousand? Just putting a maximum bound on the problem, providing a time-frame in which I can be fairly certain that the program will have terminated. :-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In mailman.2317.1342730879.4697.python-l...@python.org Dennis Lee Bieber wlfr...@ix.netcom.com writes: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
MRAB wrote: Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. -- Georg Brandl Yes, and the Lord was Wrong. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Fri, Jul 20, 2012 at 7:01 AM, John Gordon gor...@panix.com wrote: In mailman.2317.1342730879.4697.python-l...@python.org Dennis Lee Bieber wlfr...@ix.netcom.com writes: Sure it terminates...If you don't run out of RAM to represent the number i in question, there's also this heat death of the universe limit I keep hearing about ;-) Since the current evidence indicates the universe will just keep expanding, it's more of a deep freeze death... Heat death means *lack* of heat. The second law of thermodynamics states that energy tends to go from higher states to lower, with heat being the very lowest. It's possible to do work using (say) kinetic energy, and in the process, some of that energy becomes heat. It's also possible to do work with any difference in temperature (eg Stirling engines), so the state of the universe in which it's no longer possible to do any work will be one in which all energy is heat and everything's at the same temperature. That doesn't mean a lack of heat; in fact, it implies that there'll be rather more heat than there now is, because we currently have a whole lot of chemical energy available to be used. But in any case, that's a long way off... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In mailman.2320.1342736459.4697.python-l...@python.org Chris Angelico ros...@gmail.com writes: The second law of thermodynamics states that energy tends to go from higher states to lower, with heat being the very lowest. It's possible to do work using (say) kinetic energy, and in the process, some of that energy becomes heat. It's also possible to do work with any difference in temperature (eg Stirling engines), so the state of the universe in which it's no longer possible to do any work will be one in which all energy is heat and everything's at the same temperature. That doesn't mean a lack of heat; in fact, it implies that there'll be rather more heat than there now is, because we currently have a whole lot of chemical energy available to be used. *mind blown* -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/17/2012 04:24 AM, Lipska the Kat wrote:
...
Thanks for your time and I'll try to do a bit better with the reading thing
before asking more
questions... not sure about this obsession with code indentation though :-|
I think it's inaccurate to call this indentation an obsession, it's part of Python's defined
syntax. It's used INSTEAD OF punctuation or keywords (like {} or BEGIN END). If you're already
used to indenting your code consistently, you'll be surprised at how quickly it becomes a
non-issue when you start using Python.
It's a bit dated, but you might find http://www.linuxjournal.com/article/3882 to be an
interesting read.
-=- Larry -=-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 18/07/12 01:46, Andrew Cooper wrote:
On 17/07/2012 19:36, Lipska the Kat wrote:
On 17/07/12 19:18, Mark Lawrence wrote:
On 17/07/2012 18:29, Ethan Furman wrote:
Terry Reedy wrote:
On 7/17/2012 10:23 AM, Lipska the Kat wrote:
snip
Take for example a Linux system call handler. The general form looks a
little like (substituting C for python style pseudocode)
if not (you are permitted to do this):
return -EPERM
if not (you've given me some valid data):
return -EFAULT
if not (you've given me some sensible data):
return -EINVAL
return actually_try_to_do_something_with(data)
How would you program this sort of logic with a single return statement?
This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.
Eeek! well if you insist (type bound)
someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING
//method
someType checkSomething(data){
someType result = -EINVAL //or your most likely or 'safest' result
if not (you are permitted to do this):
result = -EPERM
if not (you've given me some valid data):
result = -EFAULT
if not (you've given me some sensible data):
result = -EINVAL
else
result = -EDSOMETHING
return result
}
//cohesive, encapsulated, reusable and easy to read
//later
if(checkSomething(data) == EDOSOMETHING){
actually_try_to_do_something_with(data)
}
else{
//who knows
}
What do you think ?
~Andrew
P.S. like the sig.
thanks
--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17 July 2012 13:01, Lipska the Kat lip...@lipskathekat.com wrote:
Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text file
and outputs the stock list in ascending or descending order of quantity.
Please note I am NOT asking for solutions.
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Here's a Python translation that won't help :)
from sys import argv
print ''.join(sorted(open(argv[1]), key=lambda l:
-int(l.split('\t')[0]))[:10 if len(argv) 3 else int(argv[2])])
Who said Python was readabl'y yours,
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Am 18.07.2012 11:06, schrieb Lipska the Kat:
On 18/07/12 01:46, Andrew Cooper wrote:
Take for example a Linux system call handler. The general form looks a
little like (substituting C for python style pseudocode)
if not (you are permitted to do this):
return -EPERM
if not (you've given me some valid data):
return -EFAULT
if not (you've given me some sensible data):
return -EINVAL
return actually_try_to_do_something_with(data)
How would you program this sort of logic with a single return statement?
This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.
Eeek! well if you insist (type bound)
someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING
//method
someType checkSomething(data){
someType result = -EINVAL //or your most likely or 'safest' result
if not (you are permitted to do this):
result = -EPERM
if not (you've given me some valid data):
result = -EFAULT
if not (you've given me some sensible data):
result = -EINVAL
else
result = -EDSOMETHING
return result
}
//cohesive, encapsulated, reusable and easy to read
This is a classic discussion topic, whether single exit (SE) functions
should be used or not. There are two things I consider as problematic
with them:
1. In the presence of exceptions, every function has at least two
possible paths that can be taken out, one returns a value (or None, in
Python), the other throws an exception. For that reason, trying to
achieve SE is a dangerous illusion. The syscall handler above is C,
which doesn't have exceptions like Java, C++ or Python, so it doesn't
suffer those two paths.
2. The biggest problem with SE functions is that you often need to skip
over lots of code before you finally find out that the fault at the very
beginning causes nothing else to happen inside the function before it is
finally returned to the caller. A typical symptom is deeply nested
if-else structures. Another symptom is result variables that are checked
multiple times to skip over effectively the rest of the function, which
unrolls the nested if-else structures. Yet another symptom is a very
fine granularity of microscopic functions, which is effectively a
distributed nest of if-else structures.
Coming back to Python, this would look like this:
if not /you are permitted to do this/:
raise NotPermitted(go awai!)
if not /you've given me valid data/:
raise TypeError(unexpected input)
if not /you're given me sensible data/:
raise ValueError(invalid input)
# do stuff here...
If you shoehorn this into an SE function (which you can't do if
something in between might throw), then it probably looks like this:
error = None
if not /you are permitted to do this/:
error = NotPermitted(go awai!)
elif not /you've given me valid data/:
raise TypeError(unexpected input)
elif not /you're given me sensible data/:
raise ValueError(invalid input)
else:
# do stuff here...
if error:
raise error
else:
return result
//later
if(checkSomething(data) == EDOSOMETHING){
actually_try_to_do_something_with(data)
}
else{
//who knows
}
Interestingly, you suggest to divide the original function into one that
verifies some conditions and one that does the actual work. Using an
early return is to me like drawing a big red line inside a function by
which it can be split into two sections. This makes it IMHO equally
clear, even clearer since I don't have to locate and read that other
function. My bioware parses this so that if the first part succeeds, the
second part can be read independently thereof, which reduces the amount
of info to keep in mind at a time.
Also, when changing code, I don't have to locate other places where the
utility function (checkSomething) is called (Python allows local
functions, which can be very(!!) useful). Since the code is inline, I
know that only this one function is affected. Yes, this is in direct
contrast to the reusability you mentioned. Neither ease of change nor
reusability are goals in and of themselves though, so this is not a
black-or-white question and a compromise can be good enough. It's a
question of taste, experience, phase of the moon, coffeination levels etc.
:)
Uli
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, 17 Jul 2012 12:01:21 +0100, Lipska the Kat wrote: For the past 9 years I have been developing in Java [...] Anyway, I'm looking at Python as a rapid prototyping language. I have an idea and just want to get it down in basic outline code as quickly as possible before it departs my aging brain... A couple of good resources for you to read, written by a top Python developer who also knows Java backwards: http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/java-is-not-python-either.html You will occasionally (i.e. about sixteen times a day) read some Python programmer tossing out comments like Flat is better than nested, often in quotes. P.J. Eby does this at least twice in the first link above. What the hell are they talking about? They're talking about the Zen of Python, a list of a dozen or so slightly tongue in cheek mottoes meant to encapsulate the (often deliberately contradictory) coding philosophy that Python developers should aspire too. At the interactive Python prompt, enter import this (without the quotes) and be enlightened. Keeping the Zen in mind as an ideal is incredibly useful. Arguing over whose opinion is more true to the Zen is a waste of time. I'm not used to using variables without declaring their type ... (well I used to do Visual Basic many years ago) It just seems so weird, Compared to Java, or Haskell, or Ada, Python may seem like an incredibly sloppy language. A lot of that sloppiness comes from the lack of compile- time type-checking. And that's probably true: Haskell's type checker can detect infinite loops, by Jove! Python won't even warn you that you're about to blow away a built-in function. (Don't worry though, you can easily get it back again.) (But at least Python isn't Perl, or PHP.) While Python doesn't (can't!) check the type of data at compile-time, but it does check the type of data at run-time. This ain't assembly language, where there's only one type, bytes! I came from a Pascal background, and at first I found the lack of type declarations rather concerning. But soon I found it liberating. Especially once I started using Python interactively, at the REPL. Most arguments about which is better, compile-time type checking or run- time type checking, miss the point: both have advantages, and disadvantages. Which is better depends on what you want to do. Python is deliberately designed to be *fast to write*. It gives up a little bit of safety for that. But not as much as you might think. Type errors are less frequent than other errors (errors of logic, bad data, etc.). And so in the time it might take a Java programmer to satisfy the compiler's insistence on type correctness, a Python programmer has probably written the program *and* the unittests and given the customer the first iteration of the application. At least, that's the theory. But you probably already know that. After all, that's why Python is the rapid-application-development language, not Java. and what's this obsession with 'correct' indentation of code ??? Nearly everyone rights correctly indented code anyway. At least, those who don't, you don't want on your project. Python just takes it one step further, and makes correctly indented code mandatory rather than optional. The plus side is, no more style wars over where the braces go, no more hunting for lost braces. The downside is, if you paste code into a dumb application (like many email clients!) that strips whitespace, your code will break. So don't do that. http://stromberg.dnsalias.org/~strombrg/significant-whitespace.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:
you could write in Python:
# Type matching will get checked at run-time
def my_function(mpf, ot):
assert isinstance(mpf, MassivelyParallelFrobinator)
assert isinstance(ot, OtherThing)
Keep in mind that assertions are not guaranteed to run. Code like the
above is buggy, because if Python is run under the -O (optimize) flag,
assertions will be stripped out.
Assertions are mostly useful for two things:
1) This cannot possibly happen, but just in case it does...
If you've ever written something like this:
if x%2 == 0:
do_spam()
elif x%2 == 1:
do_ham()
else:
# This can't happen!
print(something unexpected happened)
sys.exit()
that is better written as:
if x%2 == 0:
do_spam()
else:
assert x%2 == 1, something unexpected happened
do_ham()
2) To check your internal reasoning in a function or method.
For example:
def foo(something):
n = len(something)
x = math.sqrt(x)
# We expect that x must be less than half of n.
# E.g. n=100 gives 10 50, which is correct.
assert x n//2
process(n, x)
Run with the -O flag, the (hopefully!) redundant test will be stripped
out; without the flag, the test will check your logic for you and fail if
the stated condition is not met.
For bonus points, can you see the mistake? The stated condition is wrong.
Without the assert, the process() code could go off and potentially
silently do the wrong thing, but the assert guards against that
possibility. And once I've had a bug report that my app raises an
AssertionError, I will go back and think more carefully about the
assertion that sqrt(n) is always less than half of n.
but that's just not the way people write code in Python.
Better is to use explicit type checks and raise an exception yourself:
if not isinstance(x, int):
raise TypeError('expected an int, got %r' % x)
Better still is to duck-type whenever you can.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote: Take for example a Linux system call handler. The general form looks a little like (substituting C for python style pseudocode) if not (you are permitted to do this): return -EPERM if not (you've given me some valid data): return -EFAULT if not (you've given me some sensible data): return -EINVAL return actually_try_to_do_something_with(data) How would you program this sort of logic with a single return statement? That's not terribly hard. if not (you are permitted to do this): result = -EPERM elif not (you've given me some valid data): result = -EFAULT elif not (you've given me some sensible data): result = -EINVAL else: result = actually_try_to_do_something_with(data) return result A better example would involve loops. I used to hate programming in some versions of Pascal without a break statement: I needed a guard variable to decide whether or not to do anything in the loop! # pseudo-code for i in 1 to 100: if not condition: do_something_useful() Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In article 5006b2e2$0$29978$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:
you could write in Python:
# Type matching will get checked at run-time
def my_function(mpf, ot):
assert isinstance(mpf, MassivelyParallelFrobinator)
assert isinstance(ot, OtherThing)
Keep in mind that assertions are not guaranteed to run. Code like the
above is buggy, because if Python is run under the -O (optimize) flag,
assertions will be stripped out.
One could equally say that code like the above is efficient, because if
Python is run under the -O (optimize) flag, assertions will be stripped
out :-)
Better is to use explicit type checks and raise an exception yourself:
if not isinstance(x, int):
raise TypeError('expected an int, got %r' % x)
Maybe, but that's two lines where one does just fine. If you're going
to go for type-bondage, you might as well be efficient and succinct
about it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 09:07:22 -0400, Roy Smith wrote:
Keep in mind that assertions are not guaranteed to run. Code like the
above is buggy, because if Python is run under the -O (optimize) flag,
assertions will be stripped out.
One could equally say that code like the above is efficient, because if
Python is run under the -O (optimize) flag, assertions will be stripped
out :-)
You seem to have missed my point. Asserts *should* be used for checks
which are optional. In this case, the fact that assert is optimized away
is a feature: you have the added safety of a guard against some
programming errors, while still being able to optimize that code on
request. This is what assert is for. You get no argument from me about
that -- my code is bulging with assertions.
But where you *need* an explicit check to run, assert is not suitable,
because you cannot control whether or not it will run. The caller, not
you, controls that, by passing -O to the python interpreter.
If you have a public function or method that can be called by any other
piece of code, and it has required pre-conditions that need to be checked
(not necessarily a type-check), then DO NOT USE ASSERT.
If you use assert, then sometimes that pre-condition will not happen, and
the caller can pass garbage into your function. The pre-condition will be
violated, and your function will silently go off and do the wrong thing
without warning.
If you're lucky, your program will fail somewhere else, probably far away
from where the error actually occurs, and you will merely have to spend
hours or days trying to debug it.
If you're unlucky, your program won't fail, it will just calculate
garbage, or otherwise do the wrong thing.
Besides, there is another reason not to use assert: it gives the wrong
exception. If the error is a type error, you should raise TypeError, not
ValueError, or ZeroDivisionError, or IndexError, or AssertionError. Using
assert because it saves a line of code is lazy, sloppy programming.
Better is to use explicit type checks and raise an exception yourself:
if not isinstance(x, int):
raise TypeError('expected an int, got %r' % x)
Maybe, but that's two lines where one does just fine.
But one line (assert) does *not* do just fine under the conditions I am
talking about.
If you need the check to run, then assert is not suitable, because it is
not guaranteed to run. It's as simple as that.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 2012-07-17, Lipska the Kat lip...@lipskathekat.com wrote: and what's this obsession with 'correct' indentation of code ??? If you can explain to us Java's obsession with 'correct' placemnt of curly-braces, then you've explained indentation in python. Unless you're asking about the tabs vs. spaces argument. In that case, people who use 4 spaces per level are 'correct'; people who use a different number of spaces are a bit less correct; people who use tabs are wrong; and people who mix spaces and tabs -- well, we don't talk about them in polite company. -- Grant Edwards grant.b.edwardsYow! NEWARK has been at REZONED!! DES MOINES has gmail.combeen REZONED!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 18/07/12 14:05, Steven D'Aprano wrote: On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote: Take for example a Linux system call handler. The general form looks a little like (substituting C for python style pseudocode) if not (you are permitted to do this): return -EPERM if not (you've given me some valid data): return -EFAULT if not (you've given me some sensible data): return -EINVAL return actually_try_to_do_something_with(data) I’m feeling a bit fed uI’m feeling a bit fed uI’m feeling a bit fed u How would you program this sort of logic with a single return statement? That's not terribly hard. if not (you are permitted to do this): result = -EPERM elif not (you've given me some valid data): result = -EFAULT elif not (you've given me some sensible data): result = -EINVAL else: result = actually_try_to_do_something_with(data) return result A better example would involve loops. I used to hate programming in some versions of Pascal without a break statement: I needed a guard variable to decide whether or not to do anything in the loop! # pseudo-code for i in 1 to 100: if not condition: do_something_useful() Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. OO was 'invented' to address the many problems that beset increasingly complex software systems. The main problem was maintainability. Encapsulating a concept in a clear and concise way makes the code easier to understand. Sometimes this means writing code that is not 'optimal' for the machine. Good code should be readable as well as efficient but I contend that it is better to write something that is clear, concise and well encapsulated than always go for the 'meanest dog in the scrapyard' approach where a developer is determined to write unreadable code that shows how jolly clever he is. More often than not he is forced to admit six months down the line that he has no idea what his code does as he 'forgot' to comment it. I speak from bitter experience. This approach works for me. I have thousands of lines of code operating every day 'in the wild', everything from flight booking systems to real time odds arbitrage. Any developer who 'gets' OO can read and modify my code and I am very proud of this fact ... and I have never been forced to admit that I don't know what I wrote six months ago. If you are writing embedded systems that must have a very limited memory footprint then there is a case for conciseness over readability but even then it has to be maintainable Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading. There, I've said it, trolls and flamers beware, I take no prisoners. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 18/07/12 15:34, Grant Edwards wrote: On 2012-07-17, Lipska the Katlip...@lipskathekat.com wrote: and what's this obsession with 'correct' indentation of code ??? If you can explain to us Java's obsession with 'correct' placemnt of curly-braces, then you've explained indentation in python. I'm not getting into the curly braces wars. Life is just too short. Unless you're asking about the tabs vs. spaces argument. In that case, people who use 4 spaces per level are 'correct'; people who use a different number of spaces are a bit less correct; people who use tabs are wrong; hmm, I've been using tabs ... still, why use one key press when you can use 4 ;-). Actually I quite like this aspect of Python, it's rapidly growing on me. Wonder if I could introduce this in a future release of Java ... nah, I'd be dead within a week %-( and people who mix spaces and tabs -- well, we don't talk about them in polite company. -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/18/2012 9:34 AM, Grant Edwards wrote: people who us tabs are wrong Don't make me get my flamethrower! and people who mix spaces and tabs -- well, we don't talk about them in polite company. Mixing can make sense, but not in Python. *hides* -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 12:40 AM, Lipska the Kat lip...@lipskathekat.com wrote: Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading. Python isn't object oriented in the way Java is (EVERYTHING has to be in a class! Look, it's all OO now!). It simply says that, well, what's the difference? That integer you're holding. That's an object. Your function is an object. The module you're in, your global scope, is an object too, and can be passed around. Python doesn't care about buzzwords, it cares about making code. Of course, the simplicity of Python's object model has its costs too. Every little integer has to be memory-managed and garbage-collected (eg in CPython, they're all refcounted). That has a performance hit. But not all that big a hit, and it is so handy when you want your function to be able to accept, and distinguish between, different types of object - you don't have to write one version that takes an integer and a different one that takes a heap object. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat lip...@lipskathekat.com wrote: hmm, I've been using tabs ... still, why use one key press when you can use 4 ;-). Actually I quite like this aspect of Python, it's rapidly growing on me. Wonder if I could introduce this in a future release of Java ... nah, I'd be dead within a week %-( First let's get Python working properly. The from __future__ import braces statement still doesn't work on any of the released versions. After that, we can consider fixing Java to do the converse. We must meet half way, you know. As to tab vs spaces: I'm a fan of tabs, myself. There was an argument over the matter last year at work, and we settled on tabs because the one guy who reckons 1-2 space indent is plenty was then able to just set his editor to two-space tabs, and the rest of us could use a more reasonable width. Using tab characters in the file gives this flexibility. It separates the lexical structure (this is three blocks in) from the visual display (draw these glyphs 35mm from the left margin). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Lipska the Kat wrote: On 18/07/12 14:05, Steven D'Aprano wrote: Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. I must admit I have no idea how we went from discussing Single Exit functions to the One True Purpose of Object Oriented Programming; are you saying that SE is one of the basic tenets of OO? OO was 'invented' to address the many problems that beset increasingly complex software systems. The main problem was maintainability. Encapsulating a concept in a clear and concise way makes the code easier to understand. Sometimes this means writing code that is not 'optimal' for the machine. Good code should be readable as well as efficient but I contend that it is better to write something that is clear, concise and well encapsulated than always go for the 'meanest dog in the scrapyard' approach where a developer is determined to write unreadable code that shows how jolly clever he is. More often than not he is forced to admit six months down the line that he has no idea what his code does as he 'forgot' to comment it. And one of the many reasons I love Python is that it is so easy to write clear, readable, and sometimes concise code (nested list comps are still a challenge for me). . . . Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading. Since *everything* in Python is an object, how can you /not/ call it an OO language? Sure, you don't have to use everything as an object -- plain functions exist -- kinda ;) Even functions live in some namespace: len() lives in __builtin__, any top level function lives in its module, etc. Oh, and namespaces are objects. It seems to me that Python is more about providing tools, and then staying out of your way. That works for me. Maybe it will work for you, too. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 18/07/12 16:09, Chris Angelico wrote: On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat lip...@lipskathekat.com wrote: hmm, I've been using tabs ... snip We must meet half way, you know. Seems reasonable to me, I'll let you suggest it ;-) As to tab vs spaces: I'm a fan of tabs, myself. There was an argument over the matter last year at work, and we settled on tabs because the one guy who reckons 1-2 space indent is plenty was then able to just set his editor to two-space tabs, and the rest of us could use a more reasonable width. Using tab characters in the file gives this flexibility. It separates the lexical structure (this is three blocks in) from the visual display (draw these glyphs 35mm from the left margin). OK, I'll set my tab to 4 spaces ... Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 18/07/12 16:32, Ethan Furman wrote: Lipska the Kat wrote: On 18/07/12 14:05, Steven D'Aprano wrote: Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. I must admit I have no idea how we went from discussing Single Exit functions to the One True Purpose of Object Oriented Programming; are you saying that SE is one of the basic tenets of OO? It's my fault, I get carried away sometimes. Maintainable code is one of the basic tenets of OO, it all seems so clear to me and I get frustrated when I think that others don't see the 'beauty' ... but then I come to my senses and realise that there is always another way to do things. Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading. Since *everything* in Python is an object, how can you /not/ call it an OO language? Obviously I can't. I can't make a call as I haven't studied the language yet. I just can't get my head around duck typing at the moment as it is just so ... different. Sure, you don't have to use everything as an object -- plain functions exist -- kinda ;) Even functions live in some namespace: len() lives in __builtin__, any top level function lives in its module, etc. Oh, and namespaces are objects. It seems to me that Python is more about providing tools, and then staying out of your way. That works for me. Maybe it will work for you, too. I hope so and thank you for being so calm and reasonable in your response. ~Ethan~ Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/18/2012 08:58 AM, Steven D'Aprano wrote: SNIP 2) To check your internal reasoning in a function or method. For example: def foo(something): n = len(something) x = math.sqrt(x) # We expect that x must be less than half of n. # E.g. n=100 gives 10 50, which is correct. assert x n//2 process(n, x) SNIP For bonus points, can you see the mistake? The stated condition is wrong. Without the assert, the process() code could go off and potentially silently do the wrong thing, but the assert guards against that possibility. And once I've had a bug report that my app raises an AssertionError, I will go back and think more carefully about the assertion that sqrt(n) is always less than half of n. There are actually two bugs in that function. One is in the assertion, but more importantly, there's a typo earlier. One that would give a traceback, so it would be caught quickly. UnboundLocalError: local variable 'x' referenced before assignment Once you change the argument of sqrt() to n, then you come to the problem you were expecting; if n has a value of 1, 2, or 3, 4, or 5 the assertion will fire. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Lipska the Kat lip...@lipskathekat.com wrote in message news:c76dnv778_sw4zvnnz2dnuvz8ukdn...@bt.com... On 18/07/12 01:46, Andrew Cooper wrote: if not (you are permitted to do this): return -EPERM if not (you've given me some valid data): return -EFAULT if not (you've given me some sensible data): return -EINVAL return actually_try_to_do_something_with(data) How would you program this sort of logic with a single return statement? This is very common logic for all routines for which there is even the remotest possibility that some data has come from an untrusted source. someType result = -EINVAL //or your most likely or 'safest' result if not (you are permitted to do this): result = -EPERM if not (you've given me some valid data): result = -EFAULT if not (you've given me some sensible data): result = -EINVAL else result = -EDSOMETHING return result } //cohesive, encapsulated, reusable and easy to read But, it works differently from the above. Perhaps replace some of those if statements with elif. The return version is handy because it provides a quick escape mechanism without cluttering up the rest of code with extra variables. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote: On 18/07/12 15:34, Grant Edwards wrote: Unless you're asking about the tabs vs. spaces argument. In that case, people who use 4 spaces per level are 'correct'; people who use a different number of spaces are a bit less correct; people who use tabs are wrong; hmm, I've been using tabs ... still, why use one key press when you can use 4 ;-). My editor lets me add four spaces with a single key press, and delete them again with another single key press. Personally, I think tabs make more sense for indents than spaces, but for compatibility with others who are not as enlightened and insist on using broken tools that cannot deal with tabs, I have reluctantly standardised on spaces for indentation. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 12:33:01 -0400, Dave Angel wrote: On 07/18/2012 08:58 AM, Steven D'Aprano wrote: SNIP For bonus points, can you see the mistake? [...] There are actually two bugs in that function. One is in the assertion, but more importantly, there's a typo earlier. One that would give a traceback, so it would be caught quickly. UnboundLocalError: local variable 'x' referenced before assignment Good catch :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote: Python isn't object oriented in the way Java is (EVERYTHING has to be in a class! Look, it's all OO now!). Actually, Python is more object-oriented than Java. In Python, everything is an object. We have no distinction between boxed and unboxed integers, for example -- all integers are boxed, always. (Of course, data structures written in C, for example the array type, can encapsulate unboxed native ints. But the array itself is still an object.) On the other hand, Python doesn't force you to program using an object- oriented style. If you want to write functional code like Haskell, you can. If you want to write Pascal-style procedural code, you can. If you prefer an imperative style closer to shell scripting, go right ahead. The only one of the major paradigms that Python doesn't naturally support is logic programming. So Python is simultaneously more *and* less object-oriented than Java. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 19/07/2012 02:14, Steven D'Aprano wrote: On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote: On 18/07/12 15:34, Grant Edwards wrote: Unless you're asking about the tabs vs. spaces argument. In that case, people who use 4 spaces per level are 'correct'; people who use a different number of spaces are a bit less correct; people who use tabs are wrong; hmm, I've been using tabs ... still, why use one key press when you can use 4 ;-). My editor lets me add four spaces with a single key press, and delete them again with another single key press. Personally, I think tabs make more sense for indents than spaces, but for compatibility with others who are not as enlightened and insist on using broken tools that cannot deal with tabs, I have reluctantly standardised on spaces for indentation. Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. -- Georg Brandl -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote: [...] Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit? Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind. Um, yes? I'm no sure what this has to do with single-exit functions/methods. You can just as easily write multi-exit methods in an OO language as in a non- OO language. So long as your language has a return statement which exits the function, you can have more than one. I am aware that some languages enforce a single exit point, but that seems to be an unnecessary restriction to me. Of course it does require discipline and/or sense to not write crap code: if you have a 300 line function or method, whether it has dozens of exits or just one, that is crap code in any language. But if the choice is to write a 20 line function with three exits, or a 30 line function with a single exit, there would have to be a good reason to prefer the single- exit version. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 11:22 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote: Python isn't object oriented in the way Java is (EVERYTHING has to be in a class! Look, it's all OO now!). Actually, Python is more object-oriented than Java. In Python, everything is an object. We have no distinction between boxed and unboxed integers, for example -- all integers are boxed, always. That was my point. Less hype about OO but everything really is an object. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Encapsulation, inheritance and polymorphism
Pythoners Python 2.7.3 Ubuntu Linux 12.04 LTS I've been taking a brief look at Python. From the tutorial documentation I get the following 'Python is an easy to learn, powerful programming language. It has efficient high-level data structures and a simple but effective approach to object-oriented programming'. I was expecting (hoping) to see in depth documentation relating to Class construction, extension mechanisms and runtime polymorphism. What I actually get is a confusion of Classes, modules, scripts and whatever else. Is Python truly OO or is it just one way to use the language. I see some documentation relating to classes but nothing on instantiation .. in fact the documentation appears to say that classes are used in a static way e.g ClassName.method(), and command line scripting is really outside the scope of other OO languages I have experienced. Is there a previous discussion in the group that I could read. Many thanks Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat lip...@lipskathekat.com wrote: Is Python truly OO or is it just one way to use the language. I see some documentation relating to classes but nothing on instantiation .. in fact the documentation appears to say that classes are used in a static way e.g ClassName.method(), and command line scripting is really outside the scope of other OO languages I have experienced. It doesn't look like you're reading the section on classes: http://docs.python.org/tutorial/classes.html You create a class like this: class MyClass(MySuperclass1, MySuperclass2): # class attributes and methods attr = 3 def method(self): print self.attr You can instantiate it by calling the class, as if it were a function: myinstance = MyClass() You call a method getting the method (myinstance.method), and then calling that as if it were a function. myinstance.method() Polymorphism is duck typed -- that is, it's based on the presence/absence of attributes and methods, not on declared interfaces (Python has no interfaces). So, for example, foo.read() works on any object bound to the name foo, as long as it has a read method that takes no parameters. This could be a file-like object, but it could also be something completely different that just happens to have a method by the same name. Is there a previous discussion in the group that I could read. Man, I dunno, the list archives are impossible to navigate. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Welcome! Am 17.07.2012 10:45, schrieb Lipska the Kat: I was expecting (hoping) to see in depth documentation relating to Class construction, extension mechanisms and runtime polymorphism. In addition to this forum for direct help and discussion, two suggestions: Firstly, it could help if you mentioned what programming languages you are fluent in, in order to help traditional misconceptions and to draw parallels. Secondly, http://docs.python.org is the central hub to tutorials and documentation. What I actually get is a confusion of Classes, modules, scripts and whatever else. Due to the very dynamic nature of Python, types (classes), modules and functions are themselves objects that can be manipulated. Is Python truly OO or is it just one way to use the language. Python supports OOP, but it doesn't enforce it. You can use other paradigms, too. I see some documentation relating to classes but nothing on instantiation .. in fact the documentation appears to say that classes are used in a static way e.g ClassName.method(), and command line scripting is really outside the scope of other OO languages I have experienced. I think you are confused. For the documentation, it would help to know which documentation exactly seems to make such claims. For the thing about commandline scripting, I'm afraid you will have to adjust your expectations. BTW: In general, you instantiate a class by just calling the class' name like a function. If e.g. ClassName is a class, ClassName() instantiates this class. Good luck! Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 10:30, Ulrich Eckhardt wrote: Welcome! Am 17.07.2012 10:45, schrieb Lipska the Kat: I was expecting (hoping) to see in depth documentation relating to Class construction, extension mechanisms and runtime polymorphism. In addition to this forum for direct help and discussion, two suggestions: Firstly, it could help if you mentioned what programming languages you are fluent in For the past 9 years I have been developing in Java, everything from device drivers (well firmware interfaces would be a better description) to serverside business logic implemented using POJOs and database interfaces along with some in depth work with earlier versions of J2EE including EJBs and of course the obligatory frameworks. There's more but you get the idea. My speciality if you like is the design of high availability real time business systems right from high level natural language specifications to detailed use cases and associated models in UML. I also do some implementation work although not so much these days. phew! my resume in a nutshell I suppose Earlier on in my career I did some fairly low level stuff in C and C++ although the mists of time and all that ... Anyway, I'm looking at Python as a rapid prototyping language. I have an idea and just want to get it down in basic outline code as quickly as possible before it departs my aging brain... I'm not used to using variables without declaring their type ... (well I used to do Visual Basic many years ago) It just seems so weird, and what's this obsession with 'correct' indentation of code ??? in order to help traditional misconceptions and to draw parallels. Secondly, http://docs.python.org is the central hub to tutorials and documentation. What I actually get is a confusion of Classes, modules, scripts and whatever else. Due to the very dynamic nature of Python, types (classes), modules and functions are themselves objects that can be manipulated. snip I see some documentation relating to classes but nothing on instantiation .. in fact the documentation appears to say that classes are used in a static way e.g ClassName.method(), and command line scripting is really outside the scope of other OO languages I have experienced. I think you are confused. Highly likely For the documentation, it would help to know which documentation exactly seems to make such claims. For the thing about commandline scripting, I'm afraid you will have to adjust your expectations. I'll try to find it again BTW: In general, you instantiate a class by just calling the class' name like a function. If e.g. ClassName is a class, ClassName() instantiates this class. Good luck! Thank you, and thank you for your kind response Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/17/2012 07:01 AM, Lipska the Kat wrote: SNIP Anyway, I'm looking at Python as a rapid prototyping language. I have an idea and just want to get it down in basic outline code as quickly as possible before it departs my aging brain... I'm not used to using variables without declaring their type ... (well I used to do Visual Basic many years ago) It just seems so weird, and what's this obsession with 'correct' indentation of code ??? Welcome to comp.lang.python. I hope you enjoy learning and using Python. Indentation isn't just custom in Python. It's part of the syntax. Other languages use braces, or keywords, to indicate scope, but Python uses indentation. Other than the occasional tab to confuse things, the rules are pretty simple. You must indent the body of a function, the scope of an if or else clause, or other similar language pieces (class, try, except, ...) Within such a scope, you cannot change indentation, except of course for a nested scope. At the end of such scope you must outdent to the previous state. The convention is to use 4 spaces per indentation, but the language will accept any amount, as long as it's consistent within any single scope. And although mixing tabs and space worked in Python 2.x, sort of, it's disallowed in Python 3. An expression may span multiple lines, but only if it's unambiguous to the compiler (eg. a pending left paren with no matching right paren yet). In that case. indentation of the subsequent lines is unrestricted. HTH -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 11:03, Devin Jeanpierre wrote: On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Katlip...@lipskathekat.com wrote: Is Python truly OO or is it just one way to use the language. I see some documentation relating to classes but nothing on instantiation .. in fact the documentation appears to say that classes are used in a static way e.g ClassName.method(), and command line scripting is really outside the scope of other OO languages I have experienced. It doesn't look like you're reading the section on classes: http://docs.python.org/tutorial/classes.html Thanks, I wasn't, there is too much to do and not enough time to do it. So now I just need to chill out a bit and get into 'documentation reading mode' again Polymorphism is duck typed -- Yes, I've been reading the wikipedia entry on this ... this type of polymorphism is not familiar to me ... I come from a Java background. more reading I guess. snip -- Devin Thanks for your time and I'll try to do a bit better with the reading thing before asking more questions... not sure about this obsession with code indentation though :-| -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 6:01 AM, Lipska the Kat wrote: Anyway, I'm looking at Python as a rapid prototyping language. I have an idea and just want to get it down in basic outline code as quickly as possible before it departs my aging brain... I'm not used to using variables without declaring their type ... (well I used to do Visual Basic many years ago) It just seems so weird, and what's this obsession with 'correct' indentation of code ??? Pythonic is (or at least should be) a word you encounter frequently in discussions of Python code. Learn what is considered Pythonic and then write Python code that way if you want to work with the language rather than fight it. Duck-typing is very Pythonic and so is readable code. As Dave mentioned, indentation is part of the syntax - blocks must be indented with either tabs or spaces (choose one - if you mix them ambiguously, an IndentationError will be raised). Try from __future__ import braces and import this for some insight. ;) The official tutorial gives a great overview of the language and has links to reference material that goes into greater detail: http://docs.python.org/tutorial/ (Python 2.7) http://docs.python.org/py3k/tutorial/ (Python 3.2) On a side note, I would highly recommend learning Python 3 (3.2 is the latest stable version) unless you have an explicit need for Python 2 (some major 3rd-party libraries have not been ported yet). Python 2 won't get any new features; it will simply get bug fixes until its EOL in 2014 (15?). -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 12:37, Andrew Berg wrote: On 7/17/2012 6:01 AM, Lipska the Kat wrote: Anyway, I'm looking at Python as a rapid prototyping language. snip Pythonic is (or at least should be) a word you encounter frequently in discussions of Python code. Learn what is considered Pythonic and then write Python code that way if you want to work with the language rather than fight it. Duck-typing is very Pythonic You're not kidding, the 'duck' example at http://en.wikipedia.org/wiki/Duck_typing made me check I hadn't overdone the medication this morning. That is just plain ...weird. It will take me a while to form non knee jerk opinions of this for sure. snip On a side note, I would highly recommend learning Python 3 (3.2 is the latest stable version) unless you have an explicit need for Python 2 (some major 3rd-party libraries have not been ported yet). Python 2 won't get any new features; it will simply get bug fixes until its EOL in 2014 (15?). I'll check it out, thanks. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 6:44 AM, Lipska the Kat wrote: I'll check it out, thanks. I forgot to add this: http://wiki.python.org/moin/Python2orPython3 It's a little outdated (there is more progress toward py3k by 3rd-party libraries every day), but still quite helpful. -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 09:45, Lipska the Kat wrote:
Pythoners
Python 2.7.3
Ubuntu Linux 12.04 LTS
I've been taking a brief look at Python.
snip
Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.
Please note I am NOT asking for solutions.
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Java is easy but long winded and takes a while to set up
C is ... well it's been a while but I'll get there
Python, well that's my current task. It will be interesting to compare
the solutions for speed and ease of development and more importantly
re-usability.
Lipska
--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Am 17.07.2012 13:01, schrieb Lipska the Kat: On 17/07/12 10:30, Ulrich Eckhardt wrote: Am 17.07.2012 10:45, schrieb Lipska the Kat: I was expecting (hoping) to see in depth documentation relating to Class construction, extension mechanisms and runtime polymorphism. In addition to this forum for direct help and discussion, two suggestions: Firstly, it could help if you mentioned what programming languages you are fluent in For the past 9 years I have been developing in Java [...] Java is usually called an OOP language, because everything you do there is put into a class. Free functions don't exist, the closest you get is class-static functions (correct me if I'm wrong, I'm not really fluent in that language). In Python, you have the choice to use OOP, but you can also use free functions or mix those. I'm not used to using variables without declaring their type As a C++ programmer (roughly 80%C++, 15%Python, 5%C) I know that feeling. Having types declared in advance just helps by having the compiler check if the passed arguments are correct. Not having this gives both freedom but also bears dangers. what's this obsession with 'correct' indentation of code ??? You'll get used to it and then start loving it. ;) Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 12:01, Lipska the Kat wrote: Anyway, I'm looking at Python as a rapid prototyping language. Lipska One of the huge advantages of Python here is that you can simply blast stuff into the interactive prompt and see what happens, no need to write a script. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 12:44, Lipska the Kat wrote: You're not kidding, the 'duck' example at http://en.wikipedia.org/wiki/Duck_typing made me check I hadn't overdone the medication this morning. That is just plain ...weird. It will take me a while to form non knee jerk opinions of this for sure. Lipska It's difficult to get junkies off of their addictive substances but I'm sure that the qualities of Python will eventually overcome your Java habit :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
In article -8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com,
Lipska the Kat lip...@lipskathekat.com wrote:
I'm not used to using variables without declaring their type
If you truly wanted to recreate this type-bondage style of programming
in Python, it's easy enough to do.
Where you would write in C++:
// Type matching will get checked at compile-time
void my_function(MassivelyParallelFrobinator mpf, OtherThing ot) {
blah, blah, blah
}
you could write in Python:
# Type matching will get checked at run-time
def my_function(mpf, ot):
assert isinstance(mpf, MassivelyParallelFrobinator)
assert isinstance(ot, OtherThing)
but that's just not the way people write code in Python.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 12:37, Andrew Berg wrote: On 7/17/2012 6:01 AM, Lipska the Kat wrote: snip On a side note, I would highly recommend learning Python 3 (3.2 is the latest stable version) unless you have an explicit need for Python 2 (some major 3rd-party libraries have not been ported yet). Python 2 won't get any new features; it will simply get bug fixes until its EOL in 2014 (15?). Wow, that was a blast from the past Just downloaded, unzipped, untarred, configured, made and installed python 3.2.3 ... it's YEARS since I've done this, makes me feel young again. Lispka -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 9:01 AM, Lipska the Kat wrote: Wow, that was a blast from the past Just downloaded, unzipped, untarred, configured, made and installed python 3.2.3 ... it's YEARS since I've done this, makes me feel young again. Most Linux distributions should have a premade package for stable Python versions - apt-get install python3 or something like that. Python 2 is generally the default Python because of all the system scripts that haven't been ported to py3k. -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 14:52, Roy Smith wrote: In article-8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com, Lipska the Katlip...@lipskathekat.com wrote: I'm not used to using variables without declaring their type If you truly wanted to recreate this type-bondage style of programming in Python, it's easy enough to do. snip Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug) but I'm not about to get into some religious war about declaring a variables type. I'll just say that I prefer to devote testing efforts to the real danger area which in my experience is 'user' input. Clients look dimly on runtime errors however they occur and if I can leave it to the compiler to check as much as possible then I'll take that. I do understand however that compiling an intepreted language doesn't really make sense however i'm sure there are interpreted languages that allow pre-execution type checking ... aren't there ? Oh yes, there's one called Java :-) Still, I'm sure you're only kidding around with me :-) Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 15:16, Andrew Berg wrote: On 7/17/2012 9:01 AM, Lipska the Kat wrote: Wow, that was a blast from the past Just downloaded, unzipped, untarred, configured, made and installed python 3.2.3 ... it's YEARS since I've done this, makes me feel young again. Most Linux distributions should have a premade package for stable Python versions - apt-get install python3 or something like that. Not as much fun though is it :-) Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 15:23, Lipska the Kat wrote: On 17/07/12 14:52, Roy Smith wrote: In article-8sdnvrxgqie25jnnz2dnuvz7qkdn...@bt.com, Lipska the Katlip...@lipskathekat.com wrote: I'm not used to using variables without declaring their type If you truly wanted to recreate this type-bondage style of programming in Python, it's easy enough to do. snip Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug) but I'm not about to get into some religious war about declaring a variables type. I'll just say that I prefer to devote testing efforts to the real danger area which in my experience is 'user' input. Why waste time testing, I thought that the compiler looked after everything? :) But seriously you might want to look at the unittest module in the standard library. There's also a separate mailing list for Python testing and I'm sure there's a wiki that compares the available tesing tools. Google and ye shall find!!! Clients look dimly on runtime errors however they occur and if I can leave it to the compiler to check as much as possible then I'll take that. I do understand however that compiling an intepreted language doesn't really make sense however i'm sure there are interpreted languages that allow pre-execution type checking ... aren't there ? Oh yes, there's one called Java :-) There are tools available to help here such as pylint, pychecker and pyflakes. For other modules check out pypi at http://pypi.python.org/pypi Still, I'm sure you're only kidding around with me :-) Kidding around on a Python mailing list, never, how dare you Sir, simply wouldn't be cricket :-) Lipska -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 17:26, Mark Lawrence wrote: On 17/07/2012 15:23, Lipska the Kat wrote: On 17/07/12 14:52, Roy Smith wrote: snip Still, I'm sure you're only kidding around with me :-) Kidding around on a Python mailing list, never, how dare you Sir, simply wouldn't be cricket :-) As in The batsman of the Kalahari no doubt :-) -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 10:23 AM, Lipska the Kat wrote:
Well 'type-bondage' is a strange way of thinking about compile time type
checking and making code easier to read (and therefor debug
'type-bondage' is the requirement to restrict function inputs and output
to one declared type, where the type declaration mechanisms are usually
quite limited.
def max(a, b):
if a = b: return a
return b
max(1,3)
1
max(3.3, 3.1)
3.1
max('ab', 'aa')
'aa'
max([1,1], [1,0])
[1, 0]
and so on, indefinitely. How easy is it to write the same in Java?
Similarly, list.sort sorts any list as long as a b works for all pairs
of items in the list.
Function max works for any two objects as long as 'a = b' works. So the
'type' of a and b is 'mutually comparable with ='. How do you declare
that in Java? How do you declare the type 'non-negative number'? In
python, putting 'if input = 0:' as the top effectively 'declares' that
input must be a number and greater than 0.
but I'm not about to get into some religious war about declaring a variables
type.
In Python, *all* data items have a class (type). Names in code do not
have a type. When they become data items, they are strings. 'Variable'
is a somewhat fuzzy term or concept in Python.
Since every object is an instance of some class, every class is a
subclass of class 'object', and an instance of a class is an instance of
all its classess superclasses; every object is an instance of 'object'.
So 'object' is the type of all inputs until further restricted. id(ob)
produces an integer for all objects. str(ob) is intented to produce a
string representation for all objects. The print functions calls str on
all its inputs.
I'll just say that I prefer to devote testing efforts to the real
danger area which in my experience is 'user' input.
Clients look dimly on runtime errors however they occur and if I can
leave it to the compiler to check as much as possible then I'll take that.
import ast
a = ast.literal_eval(input('enter a value: '))
b = ast.literal_eval(input('enter a comparable value: ')
try:
print('the max of those two is ', max(a,b))
except TypeError:
print(a, ' and ', b, ' are not comparable')
I suppose
Still, I'm sure you're only kidding around with me :-)
How easy was it to write max, or a universal sort in Java?
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 8:01 AM, Lipska the Kat wrote:
On 17/07/12 09:45, Lipska the Kat wrote:
Pythoners
Python 2.7.3
Ubuntu Linux 12.04 LTS
I've been taking a brief look at Python.
snip
Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.
Nice problem. Easy but non-trivial.
Please note I am NOT asking for solutions.
Ok. With some inefficient redundancy, I believe it could be done in one
line in Python. Better code would take a few more.
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Won't sort work alphabetically and leave the following as is?
1\talpha
11\tbeta
2\tgamma
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 10:16 AM, Andrew Berg wrote: On 7/17/2012 9:01 AM, Lipska the Kat wrote: Wow, that was a blast from the past Just downloaded, unzipped, untarred, configured, made and installed python 3.2.3 ... it's YEARS since I've done this, makes me feel young again. Most Linux distributions should have a premade package for stable Python versions - apt-get install python3 or something like that. I am just curious: how long will it take 'most Linux distributions' to premake the even better 3.3.0 (after it comes out) and change the default python3 to that? Do any of them have a premade 3.3.0b0 available? (In some ways, it is already better than 3.2.3.) -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 18:24, Terry Reedy wrote:
On 7/17/2012 8:01 AM, Lipska the Kat wrote:
On 17/07/12 09:45, Lipska the Kat wrote:
Pythoners
Python 2.7.3
Ubuntu Linux 12.04 LTS
I've been taking a brief look at Python.
snip
Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.
Nice problem. Easy but non-trivial.
Please note I am NOT asking for solutions.
Ok. With some inefficient redundancy, I believe it could be done in one
line in Python. Better code would take a few more.
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Won't sort work alphabetically and leave the following as is?
1\talpha
11\tbeta
2\tgamma
The commandline options are -nr. n means compare numerically and
r means reverse order.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/17/12 12:24, Terry Reedy wrote:
On 7/17/2012 8:01 AM, Lipska the Kat wrote:
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Won't sort work alphabetically and leave the following as is?
1\talpha
11\tbeta
2\tgamma
Only if Lipska had omitted the -n which tells sort to treat
numbers like numbers.
For Lipska, you'd want to look into the csv module for parsing the
file easily (specifying '\t' as the delimiter). You can then sort
and crop as-is, or you can use heapq.nsmallest()
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 7/17/2012 12:30 PM, Terry Reedy wrote: (In some ways, it is already better than 3.2.3.) I certainly make heavy use of some of the new features. I'm not sure we can have enough separate exceptions for OS errors without exhausting every possibility and I might start looking for excuses to use the lzma module. :P -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Wed, Jul 18, 2012 at 12:23 AM, Lipska the Kat lip...@lipskathekat.com wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug) but I'm not about to get into some religious war about declaring a variables type. There are options for that, but they aren't Python. (I'd like to see a from __future__ import variable_declarations, but it doesn't seem to work. Yet.) If you're interested, I could tell you about a language that has a lot of what you're looking for (including polymorphism and even the ability to declare a variable that can contain non-negative integer as a type), but it's off-topic for the forum. However, I can't email you, as lipskathekat.com doesn't seem to exist... Email me privately if you're interested, we can continue the discussion off-list. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 07/17/12 12:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) Or he could have meant min instead of max. Or he could have returned the wrong values: def max(a, b): if a = b: return b return a :-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 18:24, Terry Reedy wrote:
On 7/17/2012 8:01 AM, Lipska the Kat wrote:
On 17/07/12 09:45, Lipska the Kat wrote:
Pythoners
Python 2.7.3
Ubuntu Linux 12.04 LTS
I've been taking a brief look at Python.
snip
Well I've set myself a task.
I have a text file containing a list of stock items
each line contains the number in stock followed by a tab followed by the
name of the item. I need to implement something that reads in the text
file and outputs the stock list in ascending or descending order of
quantity.
snip
In bash this is laughably trivial
sort -nr $1 | head -${2:-10}
Won't sort work alphabetically and leave the following as is?
1\talpha
11\tbeta
2\tgamma
The -n option tells sort to interpret the first word on a line as a
number r means sort in descending order. It works fine. I also added
another feature not in the specification that allows the input of a
number of lines to print ...
well on the way to being bloatware I guess ;-)
Lipska
--
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
Mark Lawrence wrote: On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) Silly me, the word processor would have caught it! ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 19:18, Mark Lawrence wrote: On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) Not unless the compiler could read your mind! The syntax looks fine it's the semantics that are suspect. Wrong is a word that I try not to use as it tends to upset people, let's call them differently right ;-) BTW having more than one return statement in a block is a little thing I know but it drives me nuts ... another Pythonic thing I'll have to get used to I suppose. -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, Jul 17, 2012 at 1:07 PM, Terry Reedy tjre...@udel.edu wrote: 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. This is interesting, I hadn't expected that sort of definition. So Haskell is not a type-bondage language? (i.e. it lets you write functions that accept any type via parametric polymorphism, or any type that supports an interface via type classes). How easy was it to write max, or a universal sort in Java? You write obj.compareTo(other) 0 instead of using obj other, and your methods only work on objects (that support the comparable interface). Otherwise, no different than Python, I guess. Would Java not be a type-bondage language if everything was an object? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 18:07, Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug snip How easy was it to write max, or a universal sort in Java? Well java.lang.Math.max() (or min() depending on what you want) might do it and as for sorting ... java.utils.Collections.sort will sort anything that implements the java.util.Comparable interface. All the standard numerical classes implement Comparable by default so there is nothing to do really. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 19:43, Ethan Furman wrote: Mark Lawrence wrote: On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) Silly me, the word processor would have caught it! ~Ethan~ +1 laugh of the week -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 20:29, Lipska the Kat wrote: On 17/07/12 18:07, Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug snip How easy was it to write max, or a universal sort in Java? Well java.lang.Math.max() (or min() depending on what you want) might do it and as for sorting ... java.utils.Collections.sort will sort anything that implements the java.util.Comparable interface. All the standard numerical classes implement Comparable by default so there is nothing to do really. Lipska I would like to spend more time on this thread, but unfortunately the 44 ton artic carrying Java in a Nutshell Volume 1 Part 1 Chapter 1 Paragraph 1 Sentence 1 has just arrived outside my abode and needs unloading :-) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 19:43, Ethan Furman wrote: Mark Lawrence wrote: On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) Silly me, the word processor would have caught it! ~Ethan~ No compiler can find as many faults as publishing your code on a mailing list!!! :) Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/12 20:39, Mark Lawrence wrote: On 17/07/2012 20:29, Lipska the Kat wrote: On 17/07/12 18:07, Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: snip How easy was it to write max, or a universal sort in Java? Well java.lang.Math.max() (or min() depending on what you want) might do it and as for sorting ... java.utils.Collections.sort will sort anything that implements the java.util.Comparable interface. All the standard numerical classes implement Comparable by default so there is nothing to do really. Lipska I would like to spend more time on this thread, but unfortunately the 44 ton artic carrying Java in a Nutshell Volume 1 Part 1 Chapter 1 Paragraph 1 Sentence 1 has just arrived outside my abode and needs unloading :-) :-))) LOL (and I did) but the pay is FANTASTIC, particularly if you 'get' OO. -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On 17/07/2012 19:36, Lipska the Kat wrote: On 17/07/12 19:18, Mark Lawrence wrote: On 17/07/2012 18:29, Ethan Furman wrote: Terry Reedy wrote: On 7/17/2012 10:23 AM, Lipska the Kat wrote: Well 'type-bondage' is a strange way of thinking about compile time type checking and making code easier to read (and therefor debug 'type-bondage' is the requirement to restrict function inputs and output to one declared type, where the type declaration mechanisms are usually quite limited. def max(a, b): if a = b: return a return b Surely you meant 'if a = b: . . .' No worries, I'm sure your unittests would have caught it. ;) ~Ethan~ Wouldn't the compiler have caught it before the unittests? :-) Not unless the compiler could read your mind! The syntax looks fine it's the semantics that are suspect. Wrong is a word that I try not to use as it tends to upset people, let's call them differently right ;-) BTW having more than one return statement in a block is a little thing I know but it drives me nuts ... another Pythonic thing I'll have to get used to I suppose. Its not a pythonic thing. Its a common and very acceptable paradigm. Mainly, it avoids complicated breaks from nested control structures, and especially the 'style' of maintaining one boolean value called should_continue or something equally silly. My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc specifications and cursing violently at some of the stupidity, Python, Bash and C++, and this is one of the few styles which remains fairly constant throughout. Take for example a Linux system call handler. The general form looks a little like (substituting C for python style pseudocode) if not (you are permitted to do this): return -EPERM if not (you've given me some valid data): return -EFAULT if not (you've given me some sensible data): return -EINVAL return actually_try_to_do_something_with(data) How would you program this sort of logic with a single return statement? This is very common logic for all routines for which there is even the remotest possibility that some data has come from an untrusted source. ~Andrew P.S. like the sig. -- http://mail.python.org/mailman/listinfo/python-list
