Re: [Tutor] R: Re: Re: Re: Class learning
On 24/01/15 01:50, Cameron Simpson wrote: On 24Jan2015 00:47, Alan Gauld wrote: But why a property rather than a simple method? Because it is a value that feels like an attribute. OK, Having seen Dannys reply as well as yours I guess I see the logic. I think Python's openness has lead ton this problem of breaking the basic OOP model. The whole concept of OOP is that objects communicate via messages. Direct access to the internals should be discouraged. So the default mechanism should be a message which in Python is represented by a method call. But Python has traditionally allowed direct access to data which has encouraged a style of programming that forgets that objects are not *supposed* to be directly accessed. That leads to a kind of mentality that treats objects as mere containers rather than as active subprograms, In that frame of reference properties sound like a good thing even though they break the fundamental theoretical OOP model. The problem I have with properties is that they are fundamentally a way of "fixing" a broken model. We have allowed people to mix direct access and message calling then bolted on a way to convert the direct access into a method call. Its pragmatic but not conducive to fixing the underlying issue. Future incarnations of the classes involved are likely to promulgate the direct access approach. A method that always returns the same value for a given object (and is very cheap) is, to my mind, not worth burdening the caller with the detail that is it a function. There is the problem. When using objects we shouldn't be thinking that we are calling a function we should be thinking we are sending a message. The message may look like a kind of function call but conceptually its very different. We are instructing an independent computing entity (the object) to perform some task on our behalf. The object may be a part of our programs computing environment or it could be on another processor or even on another network node, we shouldn't care. the caller bothers keeping the value around) then why should the caller care that it is a function? So why should it even look like a function? Because they should remember that they are dealing with an object not just a data container. It encourages the client (and designer) to treat the object as a separate "living" entity within the program. It should look and feel like any other object attribute - a simple value that can just be examined. But that's a broken object model. It's a concession Python makes for pragmatic reasons. Unfortunately we, as Python programmers, are starting to abuse that freedom and forget the fundamentals of OOP. Our programs become more brittle because of it and we need to introduce "fixes" like properties to tidy up the mess. My intuition is that a function is costly (potentially) and that consulting an attribute is very cheap. I don't want to break such intuition. That's true, there is a small overhead in calling a function but considering that aspect in the OOP design stage is always a premature optimisation. Bad OOP design that encourages direct access to data for processing outside the object is far more likely to lead to performance issues. Of course pure OOP design is often not practical (or even possible) and very occasionally we do need to consider the performance impact of a function call, but those occasions are as rare as hens teeth in most real world programs, there are usually far bigger factors to consider. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] R: Re: Re: Re: Class learning
On 24Jan2015 09:16, Alan Gauld wrote: On 24/01/15 01:50, Cameron Simpson wrote: On 24Jan2015 00:47, Alan Gauld wrote: But why a property rather than a simple method? Because it is a value that feels like an attribute. OK, Having seen Dannys reply as well as yours I guess I see the logic. I think Python's openness has lead ton this problem of breaking the basic OOP model. The whole concept of OOP is that objects communicate via messages. Direct access to the internals should be discouraged. So the default mechanism should be a message which in Python is represented by a method call. However, Python is an "open Kimono" language; direct access to object attributes is permitted and, with restraint, encouraged what appropriate. EVen the leading underscore convention for "private" attributes is just a naming convention. The point here is that while you _can_ program in a pure OOP fashion, using only method calls, the language does not enforce this. Since OOP is just a particular paradigm, this is a good thing: one can choose to work that way or you can choose not to, or you can mix at your discretion. But Python has traditionally allowed direct access to data which has encouraged a style of programming that forgets that objects are not *supposed* to be directly accessed. In a "pure" OOP environment yes. But this needn't be. That leads to a kind of mentality that treats objects as mere containers rather than as active subprograms, In that frame of reference properties sound like a good thing even though they break the fundamental theoretical OOP model. The problem I have with properties is that they are fundamentally a way of "fixing" a broken model. We have allowed people to mix direct access and message calling then bolted on a way to convert the direct access into a method call. Its pragmatic but not conducive to fixing the underlying issue. Future incarnations of the classes involved are likely to promulgate the direct access approach. There is a flip side to that. In a language like Python or Java, every entity is an object. Including mere containers. If the only medium for interacting with a contained is a message in the form of a method call, things get very painful very fast. So there is a line to be drawn, several in fact. For notational convenience, a property is worthwhile all on its own: it presents succinct access to object messages that retrieve or set an aspect of a message. And for containers, again you have a choice. You can permit direct access to container members as ordinary attributes, or you can require cumbersome method access and some kind of (perhaps implicit) mapping from method names to the private container member attributes. While you see a property as a hack, I view it as a succinct way to provide method mediated access to an attribute with the benefits that can accompany it: programmed behaviour around the access or setting, or simple abstraction, separating the published name of the property from whatever object internals are used in its implementation. A method that always returns the same value for a given object (and is very cheap) is, to my mind, not worth burdening the caller with the detail that is it a function. There is the problem. When using objects we shouldn't be thinking that we are calling a function we should be thinking we are sending a message. The message may look like a kind of function call but conceptually its very different. We are instructing an independent computing entity (the object) to perform some task on our behalf. The object may be a part of our programs computing environment or it could be on another processor or even on another network node, we shouldn't care. the caller bothers keeping the value around) then why should the caller care that it is a function? So why should it even look like a function? Because they should remember that they are dealing with an object not just a data container. It encourages the client (and designer) to treat the object as a separate "living" entity within the program. It should look and feel like any other object attribute - a simple value that can just be examined. But that's a broken object model. It's a concession Python makes for pragmatic reasons. Unfortunately we, as Python programmers, are starting to abuse that freedom and forget the fundamentals of OOP. Our programs become more brittle because of it and we need to introduce "fixes" like properties to tidy up the mess. OOP is a tool to an end. It is a very expressive and powerful discipline giving you good data separation. But it isn't the only tool, and it isn't always the preferred choice. My intuition is that a function is costly (potentially) and that consulting an attribute is very cheap. I don't want to break such intuition. That's true, there is a small overhead in calling a function but considering that aspect in the OOP design stage is always a premature opti
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
On Fri, Jan 23, 2015 at 12:10:38AM -0600, boB Stepp wrote: > On Thu, Jan 22, 2015 at 5:45 PM, Steven D'Aprano wrote: > > On Thu, Jan 22, 2015 at 03:17:58PM -0600, boB Stepp hid the following > > question in the subject line: > > > > "Does the Python way of doing things have a definite preference for the > > structure and content of program file header comments?" > > > > and then wrote: > > > >> And will this vary depending on whether a version control system is > >> being used or not? Or is the use of a version control system > >> considered to be highly recommended (if not mandatory)? > > > > This is a language-agnostic question, it is not specific to Python. It > > may be a question about the community of users for a language, but in > > principle at least it applies to *every language*. > > I was wondering if the Python culture had their own particular take on > these types of comments. A good place to learn about Python culture is to look at the standard library. Assuming you are using Python 2.7, you can look at the .py files in some place like /usr/lib/python2.7/ or /usr/local/lib/python2.7/ on Linux. If you have trouble locating the standard library, run this: import warnings print warnings.__file__ and it will print the location of the warnings module from the standard library. (Standard disclaimer applies: if you have created a file called "warnings.py", it will shadow the standard module.) Have a look at the sort of thing that the standard library does. (Remember not to edit the files, lest you break them.) If you don't like the idea of poking around in the standard library with an editor, you can also see the files on the web. Go to the Python docs, choose a module, and many of them will include a read-only link to the source code, e.g.: https://docs.python.org/2/library/pprint.html has a link to: https://hg.python.org/cpython/file/2.7/Lib/pprint.py You might also like to see the sort of thing I put in my modules: http://code.google.com/p/pyprimes/source/browse/ [...] > I am striving hard to at least make myself aware of what constitutes > "professionalism" in software creation. I fully intend to go in your > stated direction, but finding time to become proficient in such a tool > in the midst of all the other things I am trying to absorb is > difficult. I know. So many things to learn, so many distractions, so little time... > However, my mention of version control was in response to a > web search where many said that including change logs/version history > in a program's header comments is made unnecessary by modern version > control systems and is even harmful in that it might lead to > unmaintained comments. OTH, there seemed to be plenty of others who > advocate that this information should indeed be included in the > program's header comments. My take on this is: - your version control system will track the minutiae of your changes; - you should have a separate CHANGELOG file as part of your project, where you put the "important" changes that will be of interest to your users; - keep the change log out of the source code. So, from my "pyprimes" project linked to above, you can see my change log file here: http://code.google.com/p/pyprimes/source/browse/CHANGES.txt That's the things I think are important enough to mention. Because the change log itself is under version control, you can look back at each revision and see how the change log itself changes. And here are all the individual changes, as recorded by the version control system: http://code.google.com/p/pyprimes/source/list > Ugh! Unfortunately I have mirrored your example recently, which has > had me wondering whether I should "make" time to implement a DVCS. By "implement", I trust you don't mean "write your own" :-) There's a good tutorial for Mercurial, or hg, writen by Joel Spolsky: http://hginit.com/ [...] > "Best practices". "Software craftsmanship". Clarity of code. And > more... As I continue to learn I am appreciating these things more and > more, especially when I must suffer multi-day interruptions to the > project I am working on and have to reconstruct what I had last been > doing/thinking. I find myself almost constantly trying to rename > things to make them more self-explanatory, break things down into more > self-contained, single-purpose constructs, etc. Trying to make my code > more "obvious" as to what it is doing to the casual reader is becoming > much more important to me. So much to learn, and the more I learn the > more I realize I do not know... That is excellent! If you are busy or suffer a lot of distractions, *you* are your own Number 1 casual reader. Actually, even if you are not distracted, comments and good naming conventions are essential. A few days ago, one of the programmers I work with was bitterly complaining about some code. Let's call him Trevor (not his real name). After a while, he went quiet, then called out "Stupid yesterday Tr
Re: [Tutor] R: Re: Re: Re: Class learning
On 24/01/2015 01:50, Cameron Simpson wrote: My intuition is that a function is costly (potentially) and that consulting an attribute is very cheap. I don't want to break such intuition. It's not just your intuition, it's a fact. Function calls are costly, relative to attribute lookup that is, at least in cPython. I've no idea what the impact is in other implementations. I'd guess that 99% of the time 99% of Python programmers needn't worry about it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Initiating an external email transmission
On Thu, Jan 22, 2015 at 07:09:24PM -0800, dw wrote: > I have a python script that I've created. > It logs into an online email service and sends out an email. > It works in my Linux box, and it works in my Windows 7 box. > I've also converted it with Py2EXE and it works as an executable in my > Win-7 box. > > The issue is, I made it for someone else to use in his PC. > And its not working for him. Well, what does it do? The most useless problem report is "it isn't working". That tells us nothing. Does it raise an exception? Crash? Set the laptop on fire? Something else? > His system is Windows 7. > And I'm wondering if perhaps he has a firewall blocking it? Quite possibly. Can he send email from his laptop? If so, how? Does he use Gmail via their website, Outlook, something else? Does his ISP block outgoing email on port 25? Many ISPs do, to try to prevent viruses from sending out spam. Does your friend actually have a mail server running? I recommend that you run through the example here: https://docs.python.org/2/library/email-examples.html and see what happens. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] R: Re: Re: Re: Class learning
On 24Jan2015 15:03, Mark Lawrence wrote: On 24/01/2015 01:50, Cameron Simpson wrote: My intuition is that a function is costly (potentially) and that consulting an attribute is very cheap. I don't want to break such intuition. It's not just your intuition, it's a fact. Function calls are costly, relative to attribute lookup that is, at least in cPython. I've no idea what the impact is in other implementations. I'd guess that 99% of the time 99% of Python programmers needn't worry about it. Like Alan, you've missed my intent here. To quote from my reply to Alan: I am not referring to the overhead of making a function call, but the intuitive cost that distinguishes something one thinks of as an attribute from something one thinks of as a function: a function may entain an arbitrary amount of work whereas an attibute is almost free, and constant in cost. I'm not talking about optimisation here, I'm talking about the notion of a value that is derived from (unspecified and perhaps costly) computation versus a value that is merely stored, and trivially retrieved. The an attribute/method/function very closely resembles the latter, I am prone to make it into a property. Cheers, Cameron Simpson On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Babbage ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Initiating an external email transmission
I apologize I should have known better than to have posted without getting more info from the user. Since then, I've discovered that simply sending someone a Py2ExE executable is not sufficient. A little more investigation about Py2EXE and I'm beginning to see it requires both the executable file along with supportive files. I loaded the executable with all of the supportive files in a win-7 laptop last night. The error message was urllib2.URLError: I googled a little bit and got indicators...something having to do with a proxy. But that doesn't make any sense to me. Getting something to work in Python is fairly easy. Getting it to work as an executable in a different PC is something else altogether. Sorry for causing people frustration!! :-/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
