Re: Help with some python homework...
sjud9227 wrote: Doesn't assigning seconds/(60*60) mean that calculating 6*hours will give me 6 hours in seconds? No, it's giving you 6 seconds in hours. (That should give you a clue as to what you should have done instead. :-) Also, I don't know what you were trying to do with these two statements: seconds = seconds - hours*60*60 seconds = seconds - minutes *60 but they don't belong there at all. If you simply take them out, that part of the program is almost right. Also, why calculate how many seconds from midnight? Because the question asked what time do I get home?, not how long did it take me to get home?. You're already calculating what time do I get home with: total_time_run = miles_run_easy_pace + miles_run_fast_pace + time_left_house except that 'total_time_run' would be better called something like 'time_got_home'. Also, for the life of me I cannot figure out how to make everything display in hh:mm:ss. Here are a few hints: 1. Consider that if you take a number of seconds and divide it by the number of seconds in an hour, the quotient is the number of hours, and the remainder is the number of minutes and seconds left over, expressed in seconds. 2. If you then divide the remainder from (1) by the number of seconds in a minute, the quotient is the number of minutes, and the remainder is the number of seconds. 3. Python has the following operators for performing integer division: a // b gives the quotient of dividing a by b a % b gives the remainder (I recommend using '//' rather than just '/', because in some versions of Python, a/b does floating point division even if a and b are both integers, and that's not what you want here.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On Fri, Jan 31, 2014 at 7:17 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: sjud9227 wrote: Doesn't assigning seconds/(60*60) mean that calculating 6*hours will give me 6 hours in seconds? No, it's giving you 6 seconds in hours. (That should give you a clue as to what you should have done instead. :-) ... a // b gives the quotient of dividing a by b a % b gives the remainder (I recommend using '//' rather than just '/', because in some versions of Python, a/b does floating point division even if a and b are both integers, and that's not what you want here.) OP is using 2.7.6, so short of a __future__ directive, that won't actually give 6 seconds in hours (though it will try to), and // is unnecessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On 31/01/2014 04:08, Dan Sommers wrote: On Thu, 30 Jan 2014 15:21:35 +, Grant Edwards wrote: On 2014-01-30, wxjmfa...@gmail.com wxjmfa...@gmail.com wrote: The temperature unit is the Kelvin, not the Degree Kelvin. One writes: 0 K, 275.15 K And remember to say Kelvins not Kelvin when speaking about temperatures other than 1 K. And -1 K.¹ *wink* ¹ http://meta.stackoverflow.com/questions/165244/is-negative-one-plural notwithstanding Does that -1 allow for the wind chill factor or not? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
how to iterate all sub-element in a list
a list like L = [[1, 2], [3, 4, 5], [6]], which has random numbers of list, which has random numbers. How do I get another list m = [1, 2, 3, 4, 5, 6] in a succinct way? ( or iterate them) I should provide my own solution, but I really can't come out with one. -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
Le vendredi 31 janvier 2014 08:02:22 UTC+1, Rustom Mody a écrit :
On Thursday, January 30, 2014 2:15:20 PM UTC+5:30, jmf wrote:
Le jeudi 30 janvier 2014 04:27:54 UTC+1, Chris Angelico a écrit :
On Thu, Jan 30, 2014 at 1:40 PM, MRAB wrote:
How cruel... I suspect the smack at 0degC is much more painful
than one
It's the 21st century; you should be making use of Unicode: 0°C.
I started to read that and thought you were going to advocate the use of
0°K...
==
The temperature unit is the Kelvin, not the Degree Kelvin.
One writes: 0 K, 275.15 K
OMG! OMG!!
That is an ASCII K and not a unicode K
Now poor jmf will suffer the fire and brimstone of hell without
diacrïticál marks
I'm aware of what I did.
1) You wrote: That is an ASCII K and not a unicode K.
This is a non sense. You are opposing ascii and unicode,
the reperoire of the ascii chars and the repertoire of the
Unicode chars.
In unicode, the are two K's, one for the letter and one
for the Kelvin unit, see my previous post.
2) I used the letter K for commodity. Btw, I'm also
aware the 'KELVIN SIGN' is not availaible in many fonts.
3) If you wish to discuss the typographical aspect
in that story, one can discuss the kind of space which
should separate the number and the unit ('SPACE',
'SOFT HYPHEN', 'NARROW NO-BREAK SPACE',
'HAIR SPACE', ...). My lazy white space can also be
considered as a mistake.
4) What is definitively wrong is to claim :
It's the 21st century; you should be making use of
Unicode: 0°C.
The 'DEGREE SIGN' and Unicode are two different
things. It exists in many coding schemes.
cs = ['iso-8859-1', 'iso-8859-2', 'cp437', 'cp850', 'cp1252', 'cp857',\
'iso-8859-15']
for c in cs:
c, '\u00b0'.encode(c, 'replace').decode(c)
cs = ['iso-8859-1', 'iso-8859-2', 'cp437', 'cp850', 'cp1252', 'cp857',\
... 'iso-8859-15']
for c in cs:
... c, '\u00b0'.encode(c, 'replace').decode(c)
...
('iso-8859-1', '°')
('iso-8859-2', '°')
('cp437', '°')
('cp850', '°')
('cp1252', '°')
('cp857', '°')
('iso-8859-15', '°')
5) Not unicode. The ° is available as direct (Shift) key
on many European keyboards.
6) Finally and for the record : n Kelvin and not n Degree Kelvin.
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
Google for python flatten list. This question comes up frequently, though I'm not sure if that's because it's a common homework problem or because people are unaware of the += operator (or extend method) for lists, and so build lists-of-lists when they could just build them flat in the first place. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
Skip Montanaro於 2014年1月31日星期五UTC+8下午6時29分27秒寫道： Google for python flatten list. This question comes up frequently, though I'm not sure if that's because it's a common homework problem or because people are unaware of the += operator (or extend method) for lists, and so build lists-of-lists when they could just build them flat in the first place. Skip thanks. a keyword is all I need. It is not homework. It is a common problem I guess. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
seasp...@gmail.com wrote: a list like L = [[1, 2], [3, 4, 5], [6]], which has random numbers of list, which has random numbers. How do I get another list m = [1, 2, 3, 4, 5, 6] in a succinct way? ( or iterate them) I should provide my own solution, but I really can't come out with one. sum(L, []) list(itertools.chain.from_iterable(L)) but as a learning experience you should do this at least once with two nested for loops, then again with a single for loop and list.extend(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Chris Angelico wrote: OP is using 2.7.6, so short of a __future__ directive, that won't actually give 6 seconds in hours Oops, yes, you're right! (I always use future division these days, so I tend to forget about that.) and // is unnecessary. It's still a good habit to get into, though, since it will continue to work in 3.x, and in 2.x it makes the intent of the code clear without having to know whether from __future__ import division is in effect. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why this throws an UnboundLocalError ?
On Thu, Jan 30, 2014 at 11:53 PM, Chris Angelico ros...@gmail.com wrote: On Fri, Jan 31, 2014 at 9:46 AM, Marc Aymerich glicer...@gmail.com wrote: GLOBAL = 0 def update(): GLOBAL += 1 If you assign to a name, Python makes it local, unless you explicitly tell it that you want it to be global: def update(): global GLOBAL GLOBAL += 1 But be aware that the ALL_CAPS name conventionally means a constant. Since you're changing its value, it's not constant (wow! :) ), so using a name of GLOBAL is a bad idea. (Also, obviously, you want to name it appropriately to what you're doing, but I assume you called it this as part of cutting down your example. For which, by the way, thank you. You posted a complete example, and the full traceback, and the Python version and platform. That's everything that we need to help you - it's such a luxury!!) Thank you very much guys! and for the additional tips Chris. :) I can't believe, all these years using Python and never encountered a situation where I needed to use global ! -- Marc -- https://mail.python.org/mailman/listinfo/python-list
webbrowser module bug?
Sorry. Experiencing same problem in Python 2.6.4 on Ubuntu 10.04 (actually, Puppy Linux 5.2.8 which is based on Ubuntu Lucid) If anyone happens to see this and knows what was settled on as the best workaround, please email me a link to it or something at robertcwat...@yahoo.com. Robert DocSalvage Watson 2014-01-31 -- https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
On Friday, January 31, 2014 4:18:13 PM UTC+5:30, Peter Otten wrote: seaspeak wrote: a list like L = [[1, 2], [3, 4, 5], [6]], which has random numbers of list, which has random numbers. How do I get another list m = [1, 2, 3, 4, 5, 6] in a succinct way? ( or iterate them) I should provide my own solution, but I really can't come out with one. sum(L, []) list(itertools.chain.from_iterable(L)) but as a learning experience you should do this at least once with two nested for loops, then again with a single for loop and list.extend(). And then again with a double comprehension: [y for x in L for y in x] -- https://mail.python.org/mailman/listinfo/python-list
Re: Why this throws an UnboundLocalError ?
On Fri, Jan 31, 2014 at 10:05 PM, Marc Aymerich glicer...@gmail.com wrote: I can't believe, all these years using Python and never encountered a situation where I needed to use global ! That might be an indication of good code design :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On 2014-01-31, scottw...@gmail.com scottw...@gmail.com wrote: Here is the question that was asked and below that I'll paste the code I have so far. **If I leave my house at 6:52 am and run 1 mile at an easy pace (8:15 per mile), then 3 miles at tempo (7:12 per mile) and 1 mile at easy pace again, what time do I get home for breakfast?** That depends on the directions in which you run. Also, you are fast! But seriously, my advice is to find the answer the old fashioned way first, with pencil and paper. Then you'll have two things you don't now: 1. A correct answer to test your program's answer with. 2. A general idea of how to solve the problem. It's often a mistake to start writing code. Eventually you'll be able to go directly from problem to code more often, but it will take practice. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
On Fri, 31 Jan 2014 06:07:39 -0500, Robert Watson wrote: Sorry. Experiencing same problem in Python 2.6.4 on Ubuntu 10.04 (actually, Puppy Linux 5.2.8 which is based on Ubuntu Lucid) If anyone happens to see this and knows what was settled on as the best workaround, please email me a link to it or something at robertcwat...@yahoo.com. Robert DocSalvage Watson I'm reminded of the story of the guy who goes to the doctor. The doctor says, Good morning, so what seems to be the problem? The guy replies You're the doctor, you tell me. You might have a bit more success asking for help with a bug if you tell us what bug it is. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
On Sat, Feb 1, 2014 at 1:24 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 31 Jan 2014 06:07:39 -0500, Robert Watson wrote: Sorry. Experiencing same problem in Python 2.6.4 on Ubuntu 10.04 (actually, Puppy Linux 5.2.8 which is based on Ubuntu Lucid) If anyone happens to see this and knows what was settled on as the best workaround, please email me a link to it or something at robertcwat...@yahoo.com. Robert DocSalvage Watson I'm reminded of the story of the guy who goes to the doctor. The doctor says, Good morning, so what seems to be the problem? The guy replies You're the doctor, you tell me. I think, in this case, he had previously been consulting with Dr Hu, pediatrician, and now he just walked into a police box and didn't realize he wasn't talking to the right person. Either the post lacks content, or it ought to have been sent to a completely different list, or both. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
On 31/01/2014 10:42, seasp...@gmail.com wrote: Skip Montanaro於 2014年1月31日星期五UTC+8下午6時29分27秒寫道： Google for python flatten list. This question comes up frequently, though I'm not sure if that's because it's a common homework problem or because people are unaware of the += operator (or extend method) for lists, and so build lists-of-lists when they could just build them flat in the first place. Skip thanks. a keyword is all I need. It is not homework. It is a common problem I guess. I'm pleased to see that you have answers. In return would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing above, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On 31/01/2014 10:17, wxjmfa...@gmail.com wrote: Is the double line spacing that you still use despite being asked not to ASCII or unicode? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Would Python be suitable for a sports statistics website?
In article 1a7a822f-569b-4ead-9421-f1dcc5d46...@googlegroups.com, britt.jonatha...@gmail.com wrote: I have been assigned by an internship with my university's athletic department, to create a statistics website to be used by sports media during games. What this means is that the statistics are generated by a stats computer into an XML file and I am wanting to parse this XML file and place it on the web quickly. Not necessarily in real-time but in a matter of a couple of seconds. I'd like to make a clean, simple website to start off with that displays these statistics. I've been playing around with Javascript and jQuery and as a beginning programmer have really been in over my head. What I want to do is start completely over and actually try to learn a language before diving in. My first thought is that this is a really ambitious project for a beginning programmer. My second thought is that maybe you want to bypass most of the work by having a mostly static site (which you can build with any number of Content Management Systems, even something like WordPress). Then, have a process which takes the XML, parses it (you would use Python's lxml library), and produces a HTML file containing the formatted scores. You could then include you HTML in the static site by way of an iframe, or something like that. -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
In article 52eb287c$0$29972$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 31 Jan 2014 04:08:46 +, Dan Sommers wrote about temperatures: And -1 K. You josh, but there are negative temperatures in Kelvin. They're hotter than infinitely hot. http://en.wikipedia.org/wiki/Negative_temperature Negative Kelvins also have meaning as relative measurements. The framzit is changing temperature at a rate of -3.6 K per gigafortnight -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
In article mailman.6209.1391180106.18130.python-l...@python.org, Mark Lawrence breamore...@yahoo.co.uk wrote: On 31/01/2014 10:17, wxjmfa...@gmail.com wrote: Is the double line spacing that you still use despite being asked not to ASCII or unicode? It's not actually double line spacing. It's single spaced using UNICODE DOUBLE COMBINING LINEFEED WITH QUOTE MARKER as line terminators. -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On 2014-01-31 15:04, Roy Smith wrote:
In article mailman.6209.1391180106.18130.python-l...@python.org,
Mark Lawrence breamore...@yahoo.co.uk wrote:
On 31/01/2014 10:17, wxjmfa...@gmail.com wrote:
Is the double line spacing that you still use despite being asked not to
ASCII or unicode?
It's not actually double line spacing. It's single spaced using UNICODE
DOUBLE COMBINING LINEFEED WITH QUOTE MARKER as line terminators.
len('\n\n')
3
Clearly, the FSR is broken beyond repair.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why this throws an UnboundLocalError ?
That might be an indication of good code design :) Or he got lucky and all his previous globals were mutable. :) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python (windows)packet sniffer ARP
On Friday, January 31, 2014 2:10:28 AM UTC-5, Ralle wrote: Hello I am wondering if it possible to create a packet sniffer in windows using python that only sniffs for ARP packets. A couple of links to get you started: http://www.winpcap.org/ http://code.google.com/p/winpcapy/ -- https://mail.python.org/mailman/listinfo/python-list
RE: Python (windows)packet sniffer ARP
Date: Fri, 31 Jan 2014 07:32:42 -0800 Subject: Re: Python (windows)packet sniffer ARP From: betz.m...@gmail.com To: python-list@python.org On Friday, January 31, 2014 2:10:28 AM UTC-5, Ralle wrote: Hello I am wondering if it possible to create a packet sniffer in windows using python that only sniffs for ARP packets. A couple of links to get you started: http://www.winpcap.org/ http://code.google.com/p/winpcapy/ -- https://mail.python.org/mailman/listinfo/python-list Try scapy Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Python (windows)packet sniffer ARP
Mark Betz betz.m...@gmail.com wrote: I am wondering if it possible to create a packet sniffer in windows using python that only sniffs for ARP packets. A couple of links to get you started: The OP could use Impacket's libpcap bindings. With one of the examples, it's easy: python examples/sniff.py ether proto 0x0806 The excellent Impacket/Pcapy is here: http://oss.coresecurity.com/pcapy/ (but it seems down now). --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: how to iterate all sub-element in a list
Mark Lawrence於 2014年1月31日星期五UTC+8下午10時48分46秒寫道： I'm pleased to see that you have answers. In return would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing above, thanks. My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence My bad, I replied in a hurry with my mobile. -- https://mail.python.org/mailman/listinfo/python-list
Python shell wont open idle or an exisiting py file
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit
(Intel)] on win32
Type copyright, credits or license() for more information.
import idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
File C:\Python33\lib\tkinter\__init__.py, line 1475, in __call__
return self.func(*args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 927, in open_recent_file
self.io.open(editFile=fn_closure)
File C:\Python33\lib\idlelib\IOBinding.py, line 183, in open
flist.open(filename)
File C:\Python33\lib\idlelib\FileList.py, line 36, in open
edit = self.EditorWindow(self, filename, key)
File C:\Python33\lib\idlelib\PyShell.py, line 126, in __init__
EditorWindow.__init__(self, *args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 287, in __init__
if io.loadfile(filename):
File C:\Python33\lib\idlelib\IOBinding.py, line 242, in loadfile
self.updaterecentfileslist(filename)
File C:\Python33\lib\idlelib\IOBinding.py, line 523, in
updaterecentfileslist
self.editwin.update_recent_files_list(filename)
File C:\Python33\lib\idlelib\EditorWindow.py, line 915, in
update_recent_files_list
menu.delete(0, END) # clear, and rebuild:
File C:\Python33\lib\tkinter\__init__.py, line 2778, in delete
if 'command' in self.entryconfig(i):
File C:\Python33\lib\tkinter\__init__.py, line 2788, in entryconfigure
return self._configure(('entryconfigure', index), cnf, kw)
File C:\Python33\lib\tkinter\__init__.py, line 1247, in _configure
self.tk.call(_flatten((self._w, cmd:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 10:
invalid start byte
This is the error message.--
https://mail.python.org/mailman/listinfo/python-list
New facts about the pyramids: a new miracle of the Qur'an
New facts about the pyramids: a new miracle of the Qur'an Last scientific discovery stated the following: French and U.S. researchers assert that the huge stones used by the Pharaohs to build the pyramids are just clay that has been heated at high temperatures... http://www.kaheel7.com/ar/images/stories/pyr-0.jpg Will the pyramids that we know as one of the Seven Wonders survive in the world? Did scientists find an answer to the puzzle of how the pyramids were built in ancient Egypt? Are some people still believe that the Jinn are the builders of these pyramids? Is it possible to believe that creatures from outer space built the pyramids of Egypt? ... These speculations filled the world and lasted for several centuries, but the new discovery made by scientists from France and America will change the scientists` look forever. It will also give a simple scientific explanation to the mystery of building the pyramids, but more odd is that this mystery has been in the Qur'an fourteen centuries ago!!! It was believed that the pharaohs have carved the stones but the question here is: How come all the stones are so identical that you cannot find a distance between one stone and another? And where are the equipments and chisels that were used in carving those stones? Until now, they have not been found? This discovery confirms that the scientists were wrong when they thought that the pyramids were built of stones. The nearest answer to logic and truth is to say that the civilization of the pharaohs was built on the clay!! http://www.kaheel7.com/ar/images/stories/pyr-1.jpg This is a picture from top of Cheops the Great ` pyramid, as we can notice this pyramid was the highest building in the world with a height up to 146 meters. Millions of stones were used in the construction: each stone weighs several tons. It is an enormous work that gives evidence to the powers the Pharaohs reached before 4500 years ago. New scientific facts One of the scientific facts that the great pyramid with the height of 146 meters was the highest building in the world for the last 4500 years and continued until the nineteenth century, The new theory proposed by French Professor Joseph Davidovits, the director of Geopolymer Institute asserts that the pyramids were built mainly of mud and that clay was used as a mean to move the stones on special railway. The research suggests that the mud and other materials were taken from the Nile`s soil and these materials were put together in tight stone molds .Then they were heated at a high temperature, leading to the interaction of these materials and forming them into stones-like volcanoes stones, which were formed millions of years ago. Scientist Davidovits affirms that the stones which were used to build the pyramids were mainly from limestone, clay and water. The tests made by using Nanotechnology (the branch of engineering that deals with things smaller than 100 nanometers) proved the existence of large quantities of water in these rocks; such quantities do not exist in natural stones. Furthermore,there is also consistency in the internal structure of stones which confirms that it is unreasonable that these stones were brought, then were carved in this way. The most realistic possibility is that they poured the clay in molds to make identical stones just as today as we pour plastic tools in templates so all the pieces are quite equal and similar. Electronic microscope was used to analyze samples of the pyramids stones. The result was closer to the opinion of Prof. Davidovits and the quartz crystals appeared clearly as a result of heating the mud. He stated that we don`t have in the nature like these stones which his confirms they were made by the Pharaohs. The analysis by Mini E scale indicated the presence of silicon dioxide too. This is another proof that the stones are not natural. http://kaheel7.com/userimages/pyramids_02.JPG The picture shows Professor Michel Barsoum standing next to the Great Pyramid. He stress that these stones were poured into molds of clay! This what he proved in his researches after results of long experiments that these stones are not natural. Pro. Michel Barsoum confirmed after Electronic microscope analysis that they are a result of a quick interaction between clay, limestone and water at high temperatures. Davidovits famous book entitled Ils ont bati les pyramides ,published in France in 2002, has resolved all problems and puzzles which were told about the way that the pyramids were built. Moreover, he put a simple geometric construction mechanism of mud. It was very convincing to many researchers in this field of science. Some researches emphasized that furnaces or stoves were used in ancient times to make ceramics and statues. The common use of fire was to build status of clay, mixed with metals and natural materials. After that, they lit a fire until the statue solidifies and takes the
__init__ is the initialiser
From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
rpuc...@cox.net wrote:
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32
bit (Intel)] on win32 Type copyright, credits or license() for more
information.
import idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
File C:\Python33\lib\tkinter\__init__.py, line 1475, in __call__
return self.func(*args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 927, in
open_recent_file
self.io.open(editFile=fn_closure)
File C:\Python33\lib\idlelib\IOBinding.py, line 183, in open
flist.open(filename)
File C:\Python33\lib\idlelib\FileList.py, line 36, in open
edit = self.EditorWindow(self, filename, key)
File C:\Python33\lib\idlelib\PyShell.py, line 126, in __init__
EditorWindow.__init__(self, *args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 287, in __init__
if io.loadfile(filename):
File C:\Python33\lib\idlelib\IOBinding.py, line 242, in loadfile
self.updaterecentfileslist(filename)
File C:\Python33\lib\idlelib\IOBinding.py, line 523, in
updaterecentfileslist
self.editwin.update_recent_files_list(filename)
File C:\Python33\lib\idlelib\EditorWindow.py, line 915, in
update_recent_files_list
menu.delete(0, END) # clear, and rebuild:
File C:\Python33\lib\tkinter\__init__.py, line 2778, in delete
if 'command' in self.entryconfig(i):
File C:\Python33\lib\tkinter\__init__.py, line 2788, in entryconfigure
return self._configure(('entryconfigure', index), cnf, kw)
File C:\Python33\lib\tkinter\__init__.py, line 1247, in _configure
self.tk.call(_flatten((self._w, cmd:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 10:
invalid start byte
This is the error message.
What happens if you rename
$HOME/.idlerc/recent-files.lst
(to an arbitrary name, just to keep it around for further debugging if the
file indeed triggers the problem)?
--
https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. Most classes have __init__, only very very few have __new__. The sense that __new__ is the constructor is the one borrowed from C++ and Java: you don't have an instance of your type until the constructor has returned. This is why __init__ is not a constructor: the self passed into __init__ is already an object of your class. But that distinction isn't useful in most programs. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Insisting that __init__ is not a constructor makes about as much sense as insisting that Python has no variables just because they work differently than in C. Python has variables, and it has constructors. We don't have to be tied to C++ semantics of the word constructor any more than we have to tied to its semantics of the word variable or for. Why can't we call __init__ the constructor and __new__ the allocator? -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 31/01/2014 19:52, Ned Batchelder wrote: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. Most classes have __init__, only very very few have __new__. The sense that __new__ is the constructor is the one borrowed from C++ and Java: you don't have an instance of your type until the constructor has returned. This is why __init__ is not a constructor: the self passed into __init__ is already an object of your class. But that distinction isn't useful in most programs. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Insisting that __init__ is not a constructor makes about as much sense as insisting that Python has no variables just because they work differently than in C. Python has variables, and it has constructors. We don't have to be tied to C++ semantics of the word constructor any more than we have to tied to its semantics of the word variable or for. Why can't we call __init__ the constructor and __new__ the allocator? To clarify the situation I think we should call __new__ the thing that instanciates an instance of a class and __init__ the thing that isn't actually needed as you can add attributes to an instance anywhere in your code :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Sat, Feb 1, 2014 at 7:17 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: To clarify the situation I think we should call __new__ the thing that instanciates an instance of a class and __init__ the thing that isn't actually needed as you can add attributes to an instance anywhere in your code :) With a typical class layout, you have something like this: class Foo: def __init__(self, some, other, args): self.stuff=some+other, other+args def roll(self, arg): ret,keep=self.stuff self.stuff=keep,arg return ret This has an invariant: it always has a two-item tuple in self.stuff. The job of __init__ is to get the class invariants straight. Before it's called, you can't safely call anything else, because all those other parts of the class are written on the assumption that __init__ will be called first. This is a fairly common way of laying out a class, and it fits pretty much any language. So what is __new__ and what is __init__? The former is the thing you rarely need, and when you do, you can go fiddle with the docs if necessary; the latter is the most obvious place to guarantee invariants. Whatever you call them, they'll both be called before pretty much anything else in the class is, barring weirdnesses, which is something you cannot depend on with other methods. Yes, you can add attributes anywhere, but you shouldn't need this: f = Foo() f.setup(12,23,34) Instead, use this: f = Foo(12,23,34) And then there's no way to accidentally muck something up and have a Foo that breaks its invariants. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 11:33 AM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I would say yes. Go ahead and create an issue if one doesn't already exist. Thanks. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 2014-01-31 19:52, Ned Batchelder wrote: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. Most classes have __init__, only very very few have __new__. The sense that __new__ is the constructor is the one borrowed from C++ and Java: you don't have an instance of your type until the constructor has returned. This is why __init__ is not a constructor: the self passed into __init__ is already an object of your class. But that distinction isn't useful in most programs. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Insisting that __init__ is not a constructor makes about as much sense as insisting that Python has no variables just because they work differently than in C. Python has variables, and it has constructors. We don't have to be tied to C++ semantics of the word constructor any more than we have to tied to its semantics of the word variable or for. Why can't we call __init__ the constructor and __new__ the allocator? The advantage of calling it the initialiser is that it explains why it's called __init__. -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 11:52 AM, Ned Batchelder wrote: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. Most classes have __init__, only very very few have __new__. My problem is with the first sentence, as it makes it sound like there is no __new__ and everything you need is in __init__. Figuring out how __new__ and __init__ were tied together took a long time because of that. Why can't we call __init__ the constructor and __new__ the allocator? I'm not so much concerned about the names (although I like those names ;) as I am about the prose. If that first line was something like: Called after the instance has been created but before it is returned. I think that would be much clearer. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 12:48 PM, MRAB wrote: On 2014-01-31 19:52, Ned Batchelder wrote: Why can't we call __init__ the constructor and __new__ the allocator? The advantage of calling it the initialiser is that it explains why it's called __init__. Hm, yes, good point. Also, __init__ initializes so it is a good choice. Ignore the names comment in my previous post. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
scipy error invalid path
Readers,
Used the community edition service of activepython web site to install
python27. Within the 'bin' directory, received the following error:
$ ./easy_install-2.7 scipy
Searching for scipy
Reading https://pypi.python.org/simple/scipy/
Best match: scipy 0.13.2
Downloading
https://pypi.python.org/packages/source/s/scipy/scipy-0.13.2.zip#md5=9befa30e546fba762a0c1695a509f731
Processing scipy-0.13.2.zip
Writing /tmp/easy_install-Ef9P39/scipy-0.13.2/setup.cfg
Running scipy-0.13.2/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-Ef9P39/scipy-0.13.2/egg-dist-tmp-6SO8yB
/path/to/.local/lib/python2.7/site-packages/numpy/distutils/system_info.py:564:
UserWarning: Specified path /home/apy/atlas/lib is invalid.
warnings.warn('Specified path %s is invalid.' % d)
There is no directory in the host computer with this home directory
name. How to solve please?
--
https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/14 3:57 PM, Ethan Furman wrote: On 01/31/2014 12:48 PM, MRAB wrote: On 2014-01-31 19:52, Ned Batchelder wrote: Why can't we call __init__ the constructor and __new__ the allocator? The advantage of calling it the initialiser is that it explains why it's called __init__. Hm, yes, good point. Also, __init__ initializes so it is a good choice. Ignore the names comment in my previous post. These days, when teaching Python, I'd say, __init__ is an initializer, or constructor. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: scipy error invalid path
On 31/01/2014 18:33, e-letter wrote:
Readers,
Used the community edition service of activepython web site to install
python27. Within the 'bin' directory, received the following error:
$ ./easy_install-2.7 scipy
Searching for scipy
Reading https://pypi.python.org/simple/scipy/
Best match: scipy 0.13.2
Downloading
https://pypi.python.org/packages/source/s/scipy/scipy-0.13.2.zip#md5=9befa30e546fba762a0c1695a509f731
Processing scipy-0.13.2.zip
Writing /tmp/easy_install-Ef9P39/scipy-0.13.2/setup.cfg
Running scipy-0.13.2/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-Ef9P39/scipy-0.13.2/egg-dist-tmp-6SO8yB
/path/to/.local/lib/python2.7/site-packages/numpy/distutils/system_info.py:564:
UserWarning: Specified path /home/apy/atlas/lib is invalid.
warnings.warn('Specified path %s is invalid.' % d)
There is no directory in the host computer with this home directory
name. How to solve please?
This is a warning and not an error so I'd assume that scipy has been
successfully installed. Have you checked this?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 31Jan2014 12:57, Ethan Furman et...@stoneleaf.us wrote: On 01/31/2014 12:48 PM, MRAB wrote: On 2014-01-31 19:52, Ned Batchelder wrote: Why can't we call __init__ the constructor and __new__ the allocator? The advantage of calling it the initialiser is that it explains why it's called __init__. Hm, yes, good point. Also, __init__ initializes so it is a good choice. Ignore the names comment in my previous post. On this basis, would it suffice to change the opening sentence from: Called when the instance is created. to Called to initialise a new instance immediately after creation. ? This seems succinct while getting both initialise and new into the line, which makes it clear that there is a separate and earlier new step. (Conveniently overridable with __new__ :-) Cheers, -- Cameron Simpson c...@zip.com.au Don't have awk? Use this simple sh emulation: #!/bin/sh echo 'Awk bailing out!' 2 exit 2 - Tom Horsley tahors...@csd.harris.com -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Ned Batchelder n...@nedbatchelder.com writes: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ […] Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. I assume the “95%” figure is made up. Whose wants are you divining, here? Most classes have __init__, only very very few have __new__. Yes, this is true, and I agree it is a major factor in the confusion: the term “constructor” is commonly encountered in discussion of classes, and in Python, the method “__init__” is commonly encountered. It is a natural mistake to think Python names its constructor “__init__”, since most classes don't define “__new__”. The sense that __new__ is the constructor is the one borrowed from C++ and Java: you don't have an instance of your type until the constructor has returned. This is why __init__ is not a constructor: the self passed into __init__ is already an object of your class. A more salient reason, I think, is that “constructor” entails that the function will return the instance. This is another important reason why “__init__” is not a constructor: it does not return the instance. But that distinction isn't useful in most programs. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Here we disagree. I think the meaning “… and that returns the new instance” is entailed in the meaning of “constructor”. Why can't we call __init__ the constructor and __new__ the allocator? Because those terms already have meanings, and “__new__” fits the meaning of “constructor” better. -- \ “This world in arms is not spending money alone. It is spending | `\ the sweat of its laborers, the genius of its scientists, the | _o__) hopes of its children.” —Dwight Eisenhower, 1953-04-16 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01Feb2014 10:05, Ben Finney ben+pyt...@benfinney.id.au wrote: Ned Batchelder n...@nedbatchelder.com writes: Why can't we call __init__ the constructor and __new__ the allocator? Because those terms already have meanings, and “__new__” fits the meaning of “constructor” better. +1 on not giving new conflicting meanings to terms already well defined in practice. Better just to make in clear in the __init__ docs that there is a separate construction step. -- Cameron Simpson c...@zip.com.au 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/14 6:05 PM, Ben Finney wrote: Ned Batchelder n...@nedbatchelder.com writes: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ […] Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. I assume the “95%” figure is made up. Whose wants are you divining, here? Most classes have __init__, only very very few have __new__. Yes, this is true, and I agree it is a major factor in the confusion: the term “constructor” is commonly encountered in discussion of classes, and in Python, the method “__init__” is commonly encountered. It is a natural mistake to think Python names its constructor “__init__”, since most classes don't define “__new__”. The sense that __new__ is the constructor is the one borrowed from C++ and Java: you don't have an instance of your type until the constructor has returned. This is why __init__ is not a constructor: the self passed into __init__ is already an object of your class. A more salient reason, I think, is that “constructor” entails that the function will return the instance. This is another important reason why “__init__” is not a constructor: it does not return the instance. But that distinction isn't useful in most programs. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Here we disagree. I think the meaning “… and that returns the new instance” is entailed in the meaning of “constructor”. Why can't we call __init__ the constructor and __new__ the allocator? Because those terms already have meanings, and “__new__” fits the meaning of “constructor” better. You say these terms already have meanings, and that constructor means a function that returns the new instance. Then your word constructor isn't the same as C++'s word constructor? Those don't return the instance. Neither do Java constructors. In terms of the code developers actually write in __init__, it looks an awful lot like a C++ or Java constructor, and serves precisely the same purpose. The fact that the underlying mechanisms are slightly different seems like an odd reason to force a difference in names. My point is that often the same word in two different programming languages won't have a precise mapping. Variable is a common example. Python ints are different than C ints, yet we call them both ints. C and Java and Python all have for statements. We didn't insist on a different keyword just because the semantics are different. There are enormous differences between Python functions, C functions, Java functions, and Haskell functions. But they serve similar roles in the programmer's toolkit, and we use the same name for them. I'm not hoping to change any official terminology. I just think that calling __init__ anything other than a constructor is confusing pedantry. It is a constructor, and Python constructors work differently than those in C++ and Java. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Cameron Simpson c...@zip.com.au writes: On 01/31/2014 12:48 PM, MRAB wrote: The advantage of calling it the initialiser is that it explains why it's called __init__. On this basis, would it suffice to change the opening sentence from: Called when the instance is created. to Called to initialise a new instance immediately after creation. ? This seems succinct while getting both initialise and new into the line, which makes it clear that there is a separate and earlier new step. (Conveniently overridable with __new__ :-) It leaves a naive reader (who isn't yet familiar with the convention for special names in Python) with the false implication that “__init__” is usually called *manually*. I would prefer it to be clear that “__init__” is called automatically, *during* the constructor's operation. So, instead of: Called when the instance is created. I suggest: Called automatically by the constructor “__new__” during instance creation, to initialise the new instance. -- \ “Why doesn't Python warn that it's not 100% perfect? Are people | `\ just supposed to “know” this, magically?” —Mitya Sirenef, | _o__) comp.lang.python, 2012-12-27 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Ned Batchelder n...@nedbatchelder.com writes: On 1/31/14 6:05 PM, Ben Finney wrote: Here we disagree. I think the meaning “… and that returns the new instance” is entailed in the meaning of “constructor”. […] You say these terms already have meanings, and that constructor means a function that returns the new instance. Then your word constructor isn't the same as C++'s word constructor? Those don't return the instance. Neither do Java constructors. In terms of the code developers actually write in __init__, it looks an awful lot like a C++ or Java constructor, and serves precisely the same purpose. These are good points, thanks for raising them. -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__)later?” —http://www.achewood.com/ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 03:43 PM, Ned Batchelder wrote: On 1/31/14 6:05 PM, Ben Finney wrote: Ned Batchelder writes: I'm not hoping to change any official terminology. I just think that calling __init__ anything other than a constructor is confusing pedantry. It is a constructor, and Python constructors work differently than those in C++ and Java. And I would say the opposite. __init__ is not creating anything, which is what I think of when speaking of a constructor. I'd be willing to yield the point that Python has a pair of methods that make up the constructor (an allocator and an initializer), but I found calling __init__ the constructor very confusing. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 03:47 PM, Ben Finney wrote: I would prefer it to be clear that “__init__” is called automatically, *during* the constructor's operation. So, instead of: Called when the instance is created. I suggest: Called automatically by the constructor “__new__” during instance creation, to initialise the new instance. But __new__ does not call __init__, type does [1]. -- ~Ethan~ [1] And I seem to think pickle does, too, but I'm not sure. -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/02/2014 00:13, Ethan Furman wrote: On 01/31/2014 03:43 PM, Ned Batchelder wrote: On 1/31/14 6:05 PM, Ben Finney wrote: Ned Batchelder writes: I'm not hoping to change any official terminology. I just think that calling __init__ anything other than a constructor is confusing pedantry. It is a constructor, and Python constructors work differently than those in C++ and Java. And I would say the opposite. __init__ is not creating anything, which is what I think of when speaking of a constructor. I'd be willing to yield the point that Python has a pair of methods that make up the constructor (an allocator and an initializer), but I found calling __init__ the constructor very confusing. -- ~Ethan~ Here's what help says. Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 16:23:43) [MSC v.1600 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. help(object.__new__) Help on built-in function __new__: __new__(...) T.__new__(S, ...) - a new object with type S, a subtype of T help(object.__init__) Help on wrapper_descriptor: __init__(...) x.__init__(...) initializes x; see help(type(x)) for signature -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On Sat, Feb 1, 2014 at 11:42 AM, Scott W Dunning swdunn...@cox.net wrote: Also, any help on how to get the hours and seconds into double digits that would be cool too. 00:00:00 Once you can divide the number of seconds into hours, minutes, and seconds, you can format them like this: time = %02d:%02d:%02d % (hours, minutes, seconds) I'll give you that one for free because I don't think it's particularly critical to your course, but it will look better that way :) Look up the string formatting features of Python in the docs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
In article mailman.6233.1391214984.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: I found calling __init__ the constructor very confusing. I've heard many people say this, and it's always sort of befuddled me. In C++, a constructor is really an initializer too. By the time C++'s Foo::Foo() or Python's Foo.__init__() get called, memory has already been allocated, so I would say the object has been constructed. Yet, C++ people are perfectly happy calling this thing that takes some allocated hunk of memory and sets its attributes to useful values a constructor[1], and Python people are not. [1] Well, they really call it a ctor, but I chalk that up to the same sort of silliness that makes pythonistas pronounce __ as dunder :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On Sat, Feb 1, 2014 at 12:14 PM, Scott W Dunning swdunn...@cox.net wrote: Thanks Chris! Also, before I forget what is the difference between / and //? I remember something about floor division? In Python 2, the / operator by default is floor division. 5 divided by 2 is 2. When you divide two integers, you get back an integer. In Python 3, the / operator is sorta kinda real number division, in that it does what you're more likely to expect: 5 divided by 2 is 2.5. You'll get back a floating point number instead of an integer. You can ask Python 2 to give you the Python 3 behaviour by putting this at the top of your script: from __future__ import division Regardless of whether you're on Py2 without the future directive, Py2 with the future directive, or Py3, you can use the // operator to get the behaviour of floor division. Since that behaviour is exactly what you want when you're working with modulo, it may be worth getting into the habit of using it. But then again, it may not. You'll have other changes to make when you move to Python 3, so you can just figure it out then. (Incidentally, if there's nothing keeping you on Python 2, you may want to move sooner rather than later. There are lots of awesome features in Python 3 that will never be added to Python 2.) Also, I think I found out through a little trial and error that I had two different hours, mins, and sec so I had to use one uppercase and one lower case. Is that frowned upon? And should I have come up with a different name instead? SECONDS = 1 MINUTES = 60 * SECONDS HOURS = 60 * MINUTES Well, an ALL_UPPERCASE_NAME is generally a constant, which is how you're using them here. So in this specific instance, what you've done is fine. But don't treat this as a way to get yourself a few more variable names; if you'd done these ones in lower case and the other ones in caps, it would have been extremely confusing to an experienced Python programmer. For some style tips that a lot of Python programs follow, check out PEP 8: http://www.python.org/dev/peps/pep-0008/ Formally, this is the style guide for the Python standard library, but it's a fairly sensible set of rules, and a lot of projects follow them. Some of the rules are widely adopted elsewhere, others (like the insistence on spaces rather than tabs - everyone agrees that you should use one OR the other, but plenty of people advocate tabs above spaces) less so; take your pick which bits you follow, but all of it is worth a read. time_left_house = 6 * HOURS + 52 * MINUTES miles_run_easy_pace = 2 * (8 * MINUTES + 15 * SECONDS) miles_run_fast_pace = 3 * (7 * MINUTES + 12 * SECONDS) time_returned_home = miles_run_easy_pace + miles_run_fast_pace + time_left_house hours = time_returned_home // HOURS part_hour = time_returned_home % HOURS minutes = part_hour // MINUTES seconds = part_hour % MINUTES print Time returned home:, hours,:, minutes,:, seconds,”am Looks fairly good. This is where you could use the formatting notation I gave you above: print Time returned home: %02d:%02d:%02d am % (hours, minutes, seconds) And then, since you're using print with a single string argument, get in the habit of putting parentheses around it: print(Time returned home: %02d:%02d:%02d am % (hours, minutes, seconds)) This syntax (one string argument, parens around it) is common to both Python 2's print statement and Python 3's print function (as with division, you can ask Python 2 to give you a print function if you wish). So, is the program giving you the result you expect? That's really the key. If it is, then you (probably!) have a working program! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 2014-02-01 01:10, Roy Smith wrote: In article mailman.6233.1391214984.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: I found calling __init__ the constructor very confusing. I've heard many people say this, and it's always sort of befuddled me. In C++, a constructor is really an initializer too. By the time C++'s Foo::Foo() or Python's Foo.__init__() get called, memory has already been allocated, so I would say the object has been constructed. Yet, C++ people are perfectly happy calling this thing that takes some allocated hunk of memory and sets its attributes to useful values a constructor[1], and Python people are not. You could argue that construction is not complete until the instance has been initialised. In the case of C++, all you have is the initialiser, so doesn't really matter, but Python has __new__ and __init__, so it _does_ matter. [1] Well, they really call it a ctor, but I chalk that up to the same sort of silliness that makes pythonistas pronounce __ as dunder :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On 1/31/2014 2:51 PM, Peter Otten wrote:
rpuc...@cox.net wrote:
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32
bit (Intel)] on win32 Type copyright, credits or license() for more
information.
import idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
File C:\Python33\lib\tkinter\__init__.py, line 1475, in __call__
return self.func(*args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 927, in
open_recent_file
self.io.open(editFile=fn_closure)
File C:\Python33\lib\idlelib\IOBinding.py, line 183, in open
flist.open(filename)
File C:\Python33\lib\idlelib\FileList.py, line 36, in open
edit = self.EditorWindow(self, filename, key)
File C:\Python33\lib\idlelib\PyShell.py, line 126, in __init__
EditorWindow.__init__(self, *args)
File C:\Python33\lib\idlelib\EditorWindow.py, line 287, in __init__
if io.loadfile(filename):
File C:\Python33\lib\idlelib\IOBinding.py, line 242, in loadfile
self.updaterecentfileslist(filename)
File C:\Python33\lib\idlelib\IOBinding.py, line 523, in
updaterecentfileslist
self.editwin.update_recent_files_list(filename)
File C:\Python33\lib\idlelib\EditorWindow.py, line 915, in
update_recent_files_list
menu.delete(0, END) # clear, and rebuild:
File C:\Python33\lib\tkinter\__init__.py, line 2778, in delete
if 'command' in self.entryconfig(i):
File C:\Python33\lib\tkinter\__init__.py, line 2788, in entryconfigure
return self._configure(('entryconfigure', index), cnf, kw)
File C:\Python33\lib\tkinter\__init__.py, line 1247, in _configure
self.tk.call(_flatten((self._w, cmd:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 10:
invalid start byte
This is the error message.
What happens if you rename
$HOME/.idlerc/recent-files.lst
For me, on Win7, $HOME is C:/Users/Terry
(to an arbitrary name, just to keep it around for further debugging if the
file indeed triggers the problem)?
Or try the following in the console with the file name changed, but
without the first line wrapped
with open('C:/Users/Terry/.idlerc/recent-files.lst', encoding='utf-8') as f:
for n, line in enumerate(f):
print(n, line, end='')
There was a (non-obvious) bug, recently fixed in
http://bugs.python.org/issue19020
which caused this seemingly bogus error message when an entry in
recent-files.list contained a directory or file name beginning with '0'.
H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py
caused this message
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14:
invalid start byte
If your file has such a line, either delete it or upgrade to 3.3.4 (rc1,
final soon) or 3.4.0 (rc1 due soon).
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On Sat, Feb 1, 2014 at 12:45 PM, Terry Reedy tjre...@udel.edu wrote: H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py caused this message UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14: invalid start byte So... something's interpreting \0 as codepoint U+ (which it shouldn't), storing that in UTF-8 as 0xC0 0x80 (which it shouldn't), and then giving it to Python to decode. That's a weird little combination bug right there. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
In article mailman.6238.1391218886.18130.python-l...@python.org, MRAB pyt...@mrabarnett.plus.com wrote: You could argue that construction is not complete until the instance has been initialised. In the case of C++, all you have is the initialiser, so doesn't really matter, but Python has __new__ and __init__, so it _does_ matter. C++ has operator new (which you can override) and the constructor. -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Ethan Furman et...@stoneleaf.us writes: On 01/31/2014 03:47 PM, Ben Finney wrote: I suggest: Called automatically by the constructor “__new__” during instance creation, to initialise the new instance. But __new__ does not call __init__, type does [1]. My apologies, you're right and that's made clear at URL:file:///usr/share/doc/python3.3/html/reference/datamodel.html#object.__new__. Try: object.__init__(self[, …]) Called automatically after the constructor “__new__”, during instance creation, to initialise the new instance. -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Ben Finney ben+pyt...@benfinney.id.au writes: My apologies, you're right and that's made clear at URL:file:///usr/share/doc/python3.3/html/reference/datamodel.html#object.__new__. And that's a URL to my local filesystem. Clearly it's time for me to step away from the discussion for a while :-) -- \ “I went to the cinema, it said ‘Adults: $5.00, Children $2.50’. | `\ So I said ‘Give me two boys and a girl.’” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/2014 3:41 PM, Ethan Furman wrote: On 01/31/2014 11:52 AM, Ned Batchelder wrote: On 1/31/14 2:33 PM, Mark Lawrence wrote: From http://docs.python.org/3/reference/datamodel.html#object.__init__ which states:- Called when the instance is created. The arguments are those passed to the class constructor expression. If a base class has an __init__() method, the derived class’s __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: BaseClass.__init__(self, [args...]). As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime. Should the wording of the above be changed to clearly reflect that we have an initialiser here and that __new__ is the constructor? Construct a house: Clear and grade house site. Bring in power and water. Built temporary structures. Built foundation. Built house on foundation. For most classes, __new__ stops with the foundation -- the bare object object (with the class name slapped onto it). A *house* is not constructed until the house is constructed on top of the foundation. I'm torn about that. The fact is, that for 95% of the reasons you want to say constructor, the thing you're describing is __init__. Right: __init__ usually does the stuff that makes the object an instance of a particular class rather than just a bare bones object. In English, constructing a 'something' includes constructing the features that make the object a 'something' rather than something else. Most classes have __init__, only very very few have __new__. *Every* class has .__new__. Mutable builtins and almost all user classes inherit .__new__ from object. Every class also has .__init__, but it is mainly inherited from object by immutable builtins. tuple.__init__ slot wrapper '__init__' of 'object' objects User classes lacking .__init__ usually inherit it from something other than object. So objects are constructed by first calling .__new__ and then passing the result to .__init__. The Python 3 doc should say so. My problem is with the first sentence, as it makes it sound like there is no __new__ and everything you need is in __init__. .__new__ allocates a bare object and initializes immutable builtins. Figuring out how __new__ and __init__ were tied together took a long time because of that. Why can't we call __init__ the constructor and __new__ the allocator? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 05:10 PM, Roy Smith wrote: In article mailman.6233.1391214984.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: I found calling __init__ the constructor very confusing. I've heard many people say this, and it's always sort of befuddled me. I have never learned C++, so I don't know its screwy semantics. ;) Nor Java, for that matter. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Terry Reedy tjre...@udel.edu writes: User classes lacking .__init__ usually inherit it from something other than object. So objects are constructed by first calling .__new__ and then passing the result to .__init__. The Python 3 doc should say so. That matches my understanding, and I agree the docs should (somehow) say that clearly. -- \ “He may look like an idiot and talk like an idiot but don't let | `\ that fool you. He really is an idiot.” —Groucho Marx | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/2014 7:13 PM, Ethan Furman wrote: On 01/31/2014 03:47 PM, Ben Finney wrote: I would prefer it to be clear that “__init__” is called automatically, *during* the constructor's operation. So, instead of: Called when the instance is created. I suggest: Called automatically by the constructor “__new__” during instance creation, to initialise the new instance. But __new__ does not call __init__, type does [1]. If the class is an instance of type, it is type.__call__, tuple.__call__ method-wrapper '__call__' of type object at 0x67E8ED30 I presume it is basically something like this: class type: def __call__(self, *args, **kwds): instance = self.__new__(cls, *args, **kwds) self.__init__(instance, *args, **kwds) return instance .__new__ and .__init__ are the plugins used by the true class instance constructor. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Try-except-finally paradox
Terry Reedy tjre...@udel.edu writes:
I do not have any information on the topic, but I *imagine* that the
when RETURN_VALUE opcode is evaluated within the context of an except
block, it triggers a check for whether a corresponding finally block
exists and should it exist, it is triggered, much like a callback.
So, my *imaginary* algorithm works like this:
return:
if within an except block EB:
if EB has a correspoinding final block FB
run FB
else
do return
else
do return
In Jessica's example, as the finally block executes a RETURN_VALUE
opcode, and as this is *probably* a jump to the caller, the rest of the
code does not get a chance to be executed.
As I have said earlier, I by no means assert the truth of this idea I've
explained here, but it seems quite reasonable to me.
gk
On 1/30/2014 7:05 AM, Dave Angel wrote:
Jessica Ross deathwea...@gmail.com Wrote in message:
I found something like this in a StackOverflow discussion.
def paradox():
... try:
... raise Exception(Exception raised during try)
... except:
... print Except after try
... return True
... finally:
... print Finally
... return False
... return None
...
return_val = paradox()
Except after try
Finally
return_val
False
I understand most of this.
What I don't understand is why this returns False rather than True. Does
the finally short-circuit the return in the except block?
The finally has to happen before any return inside the try or the
except. And once you're in the finally clause you'll finish it
before resuming the except clause. Since it has a return, that
will happen before the other returns. The one in the except block
will never get reached.
It's the only reasonable behavior., to my mind.
Checking with the disassembled code, it appears that the except return
happens first and is then caught and the value over-written
2 0 SETUP_FINALLY 45 (to 48)
3 SETUP_EXCEPT16 (to 22)
3 6 LOAD_GLOBAL 0 (Exception)
9 LOAD_CONST 1 ('Exception raised during try')
12 CALL_FUNCTION1 (1 positional, 0 keyword pair)
15 RAISE_VARARGS1
18 POP_BLOCK
19 JUMP_FORWARD22 (to 44)
422 POP_TOP
23 POP_TOP
24 POP_TOP
5 25 LOAD_GLOBAL 1 (print)
28 LOAD_CONST 2 ('Except after try')
31 CALL_FUNCTION1 (1 positional, 0 keyword pair)
34 POP_TOP
6 35 LOAD_CONST 3 (True)
38 RETURN_VALUE
39 POP_EXCEPT
40 JUMP_FORWARD 1 (to 44)
43 END_FINALLY
44 POP_BLOCK
45 LOAD_CONST 0 (None)
848 LOAD_GLOBAL 1 (print)
51 LOAD_CONST 4 ('Finally')
54 CALL_FUNCTION1 (1 positional, 0 keyword pair)
57 POP_TOP
9 58 LOAD_CONST 5 (False)
61 RETURN_VALUE
62 END_FINALLY
10 63 LOAD_CONST 0 (None)
66 RETURN_VALUE
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On 2014-02-01 01:52, Chris Angelico wrote: On Sat, Feb 1, 2014 at 12:45 PM, Terry Reedy tjre...@udel.edu wrote: H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py caused this message UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14: invalid start byte So... something's interpreting \0 as codepoint U+ (which it shouldn't), storing that in UTF-8 as 0xC0 0x80 (which it shouldn't), and then giving it to Python to decode. That's a weird little combination bug right there. I think that some years ago I heard about a variation on UTF-8 (Microsoft?) where codepoint U+ is encoded as 0xC0 0x80 so that the null byte can be used as the string terminator. I had a look on Wikipedia found this: http://en.wikipedia.org/wiki/Null-terminated_string -- https://mail.python.org/mailman/listinfo/python-list
Dunder [was Re: __init__ is the initialiser]
On Fri, 31 Jan 2014 20:10:46 -0500, Roy Smith wrote: In article mailman.6233.1391214984.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: I found calling __init__ the constructor very confusing. I've heard many people say this, and it's always sort of befuddled me. In C++, a constructor is really an initializer too. By the time C++'s Foo::Foo() or Python's Foo.__init__() get called, memory has already been allocated, so I would say the object has been constructed. Yet, C++ people are perfectly happy calling this thing that takes some allocated hunk of memory and sets its attributes to useful values a constructor[1], and Python people are not. [1] Well, they really call it a ctor, but I chalk that up to the same sort of silliness that makes pythonistas pronounce __ as dunder :-) I see your smiley, but the comparison is ridiculous. Constructor is three syllables; ctor isn't readily pronounceable in English at all, rather like Cthulhu. (I can't think of any standard English words with a CT in them at all, let alone at the start of the word). The best I can come up with is KUH TOR or possibly SEE TOR, both of which are clumsy, and only save a single syllable. On the other hand, double leading and trailing underscore is ten syllables. Dunder is two, a significant saving, and it's a readily pronounceable word in English (and probably Dutch). There's nothing silly about abbreviating double leading and trailing underscore as dunder. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/14 9:28 PM, Terry Reedy wrote: Most classes have __init__, only very very few have __new__. *Every* class has .__new__. Mutable builtins and almost all user classes inherit .__new__ from object. Every class also has .__init__, but it is mainly inherited from object by immutable builtins. tuple.__init__ slot wrapper '__init__' of 'object' objects User classes lacking .__init__ usually inherit it from something other than object. So objects are constructed by first calling .__new__ and then passing the result to .__init__. The Python 3 doc should say so. Sorry, I wasn't clear. I meant (as many have understood) that most user-defined classes define __init__, and that very very few define __new__. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Dunder [was Re: __init__ is the initialiser]
On 2014-02-01 02:52, Steven D'Aprano wrote: On Fri, 31 Jan 2014 20:10:46 -0500, Roy Smith wrote: In article mailman.6233.1391214984.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: I found calling __init__ the constructor very confusing. I've heard many people say this, and it's always sort of befuddled me. In C++, a constructor is really an initializer too. By the time C++'s Foo::Foo() or Python's Foo.__init__() get called, memory has already been allocated, so I would say the object has been constructed. Yet, C++ people are perfectly happy calling this thing that takes some allocated hunk of memory and sets its attributes to useful values a constructor[1], and Python people are not. [1] Well, they really call it a ctor, but I chalk that up to the same sort of silliness that makes pythonistas pronounce __ as dunder :-) I see your smiley, but the comparison is ridiculous. Constructor is three syllables; ctor isn't readily pronounceable in English at all, rather like Cthulhu. (I can't think of any standard English words with a CT in them at all, let alone at the start of the word). The best I can come up with is KUH TOR or possibly SEE TOR, both of which are clumsy, and only save a single syllable. So you've never used the word ctenoid? How strange! :-) (adj. - Resembling a comb; having projections like the teeth of a comb.) On the other hand, double leading and trailing underscore is ten syllables. Dunder is two, a significant saving, and it's a readily pronounceable word in English (and probably Dutch). There's nothing silly about abbreviating double leading and trailing underscore as dunder. -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On Thu, 30 Jan 2014 21:12:19 -0800, scottwd80 wrote:
Here is the question that was asked and below that I'll paste the code I
have so far.
The following is a reasonably but not highly obfuscated short solution to
the problem set in python 2.7. With a bit of luck, after each lesson of
your course, you'll be able to understand a bit more of how it works.
M=60;H=M*60
def s(h,m,s): return h*H+m*M+s
def hms(s): return (int(s/H),int((s%H)/M),s%M)
(a,b,c)=hms(s(6,52,0)+3*s(0,7,12)+2*s(0,8,15))
print {:02d}:{:02d}:{:02d}.format(a,b,c)
When you can write a short paragraph describing what each line of the
program does, you'll be on your way to understanding a few of the
structures, syntaxes and mechanisms of python.
Or you could show it to your lecturer or a TA and say it was suggested
that you ask her or him to work through it with you.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 1/31/2014 7:13 PM, Ethan Furman wrote: On 01/31/2014 03:43 PM, Ned Batchelder wrote: On 1/31/14 6:05 PM, Ben Finney wrote: Ned Batchelder writes: I'm not hoping to change any official terminology. I just think that calling __init__ anything other than a constructor is confusing pedantry. It is a constructor, and Python constructors work differently than those in C++ and Java. And I would say the opposite. __init__ is not creating anything, As you pointed out in a different response, Python has one default, two-phase constructor. type.__call__. Typically, .__new__ allocates a generic object (with one customization as to class). .__init__ creates, from that mostly generic object, a customized instance of class C with the minimal attributes needed to be an instance of C, with value specific to the instance. Creating a painting on canvas has two similar phases. Prepare a generic blank canvas stretched on a frame and coated with a white undercoat. Paint a particular picture. Would you say that the second step is not creating anything? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On Sat, Feb 1, 2014 at 1:54 PM, MRAB pyt...@mrabarnett.plus.com wrote: I think that some years ago I heard about a variation on UTF-8 (Microsoft?) where codepoint U+ is encoded as 0xC0 0x80 so that the null byte can be used as the string terminator. I had a look on Wikipedia found this: http://en.wikipedia.org/wiki/Null-terminated_string Yeah, it's a common abuse of UTF-8. It's a violation of spec, but an understandable one. However, I don't understand why the first part - why should \0 become U+ but (presumably) the \a later on (...cs\accel...) doesn't become U+0007, etc? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Fri, 31 Jan 2014 14:52:15 -0500, Ned Batchelder wrote: Why can't we call __init__ the constructor and __new__ the allocator? __new__ constructs the object, and __init__ initialises it. What's wrong with calling them the constructor and initialiser? Is this such a difficult concept that the average programmer can't learn it? I've met people who have difficulty with OOP principles, at least at first. But once you understand the idea of objects, it isn't that hard to understand the idea that: - first, the object has to be created, or constructed, or allocated if you will; - only then can it be initialised. Thus, two methods. __new__ constructs (creates, allocates) a new object; __init__ initialises it after the event. (In hindsight, it was probably a mistake for Python to define two create- an-object methods, although I expect it was deemed necessary for historical reasons. Most other languages make do with a single method, Objective-C being an exception with alloc and init methods.) Earlier in this post, you wrote: But that distinction [between __new__ and __init__] isn't useful in most programs. Well, I don't know about that. I guess it depends on what sort of objects you're creating. If you're creating immutable objects, then the distinction is vital. If you're subclassing from immutable built-ins, of which there are a few, the distinction may be important. If you're using the object-pool design pattern, the distinction is also vital. It's not *rare* to care about these things. The thing most people mean by constructor is the method that gets invoked right at the beginning of the object's lifetime, where you can add code to initialize it properly. That describes __init__. Most people. I presume you've done a statistically valid survey then *wink* It *better* describes __new__, because it is *not true* that __init__ gets invoked right at the beginning of the object's lifetime. Before __init__ is invoked, the object's lifetime has already begun, inside the call to __new__. Excluding metaclass shenanigans, the object lifetime goes: Prior to the object existing: - static method __new__ called on the class[1] - __new__ creates the object[2] === start of object lifetime Within the object's lifetime: - the rest of the __new__ method runs, which may perform arbitrarily complex manipulations of the object; - __new__ exits, returning the object - __init__ runs So __init__ does not occur *right at the beginning*, and it is completely legitimate to write your classes using only __new__. You must use __new__ for immutable objects, and you may use __new__ for mutable ones. __init__ may be used by convention, but it is entirely redundant. I do not buy the argument made by some people that Python ought to follow whatever (possibly inaccurate or misleading) terminology other languages use. Java and Ruby have the exact same argument passing conventions as Python, but one calls it call by value and the other call by reference, and neither is the same meaning of call by value/reference as used by Pascal, C, Visual Basic, or other languages. So which terminology should Python use? Both C++ and Haskell have functors, but they are completely different things. What Python calls a class method, Java calls a static method. We could go on for days, just listing differences in terminology. In Python circles, using constructor for __new__ and initialiser for __init__ are well-established. In the context of Python, they make good sense: __new__ creates (constructs) the object, and __init__ _init_ialises it. Missing the opportunity to link the method name __init__ to *initialise* would be a mistake. We can decry the fact that computer science has not standardised on a sensible set of names for concepts, but on the other hand since the semantics of languages differ slightly, it would be more confusing to try to force all languages to use the same words for slightly different concepts. The reality is, if you're coming to Python from another language, you're going to have to learn a whole lot of new stuff anyway, so having to learn a few language-specific terms is just a small incremental cost. And if you have no idea about other languages, then it is no harder to learn that __new__ / __init__ are the constructor/initialiser than it would be to learn that they are the allocator/constructor or preformulator/ postformulator. I care about using the right terminology that will cause the least amount of cognitive dissonance to users' understanding of Python, not whether they have to learn new terminology, and in the context of Python's object module, constructor and initialiser best describe what __new__ and __init__ do. [1] Yes, despite being declared with a cls parameter, __new__ is actually hard-coded as a static method. [2] By explicitly or implicitly calling object.__new__. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 07:16 PM, Terry Reedy wrote: On 1/31/2014 7:13 PM, Ethan Furman wrote: On 01/31/2014 03:43 PM, Ned Batchelder wrote: On 1/31/14 6:05 PM, Ben Finney wrote: Ned Batchelder writes: I'm not hoping to change any official terminology. I just think that calling __init__ anything other than a constructor is confusing pedantry. It is a constructor, and Python constructors work differently than those in C++ and Java. And I would say the opposite. __init__ is not creating anything, As you pointed out in a different response, Python has one default, two-phase constructor. type.__call__. Typically, .__new__ allocates a generic object (with one customization as to class). .__init__ creates, from that mostly generic object, a customized instance of class C with the minimal attributes needed to be an instance of C, with value specific to the instance. Creating a painting on canvas has two similar phases. Prepare a generic blank canvas stretched on a frame and coated with a white undercoat. Paint a particular picture. Would you say that the second step is not creating anything? Very nicely put. Considering the discussion that this topic has engendered, you will hopefully agree that the current docs could use a little improvement. :) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 06:28 PM, Terry Reedy wrote: Construct a house: Clear and grade house site. Bring in power and water. Built temporary structures. Built foundation. Built house on foundation. For most classes, __new__ stops with the foundation -- the bare object object (with the class name slapped onto it). A *house* is not constructed until the house is constructed on top of the foundation. On the ground programming has the dividing line at: immutable objects -- everything done in __new__ mutable objects -- everything done in __init__ Typically, immutable objects are not created in Python code because, well, it's really dang hard (__slots__, anyone?), but one still needs to understand how __new__ and __init__ go together to do the more interesting stuff (such as having __new__ return a dynamically selected subclass, which still needs to be (or not be) __init__ed). -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
Not any direct comments on this... Just some thoughts around a couple of questions 1. Declarative and Imperative Terminology 2. Is OOP declarative or imperative 1. Python is an imperative language. It does a good amount of functional stuff. Are its terms neutral? Look at sort sort -- imperative sorted -- functional By contrast in scheme one would have something like sort -- functional sort! -- imperative Or haskell sort -- functional unsafePerformSort -- imperative If the simple term corresponds to the standard and therefore default, this shows a fundamental difference in world-views 2. Is OOP functional, imperative or neutral? In theory it is neutral: If we only ever make and use value-objects (ie immutable objects) then it is used declaratively If we have mutable objects then OOP is being used imperatively So much for the theory. In practice (in the words of Neal Ford): OOP tries to encapsulate moving parts, FP tries to minimize the moving parts IOW it seems (to me) OOP is almost always used as a clover-leaf on wanton state-change ie. imperativeness. This comes from the fact that while objects in programming languages may pretend neutrality, philosphically objects and values are fundamentally opposed: Objects belong to 'this world' -- born change live die Values belong to the platonic world -- 3 was 3 even without an exsting universe In hhttp://research.microsoft.com/en-us/um/people/gurevich/opera/123.pdf (first few pages) Yuri Gurevich gives an entertaining account of how kids learning math are platonically indoctrinated. What most dyed-in-the-wool imperative programmers dont get is that when we take a task that humans perform in 'this world' and abstract it effectively into a program that a machine can (at least partly) perform, this is only possible if we build a model of the action. And models are intrinsically abstract entities ie platonic. IOW to modify the standard dictum of philosophy: No philosophy is bad philosophy we have Imperative programmers are bad functional programmers What has this to do with how constructors are named? Both 'constructor' and 'initializer' have (to my ears) an imperative sound though initializer is perhaps more so -- evokes a picture of a life-story -- a saga! Constructor less so This may be factored in to the choice of terminology -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I've met people who have difficulty with OOP principles, at least at first. But once you understand the idea of objects, it isn't that hard to understand the idea that: - first, the object has to be created, or constructed, or allocated if you will; - only then can it be initialised. Thus, two methods. __new__ constructs (creates, allocates) a new object; __init__ initialises it after the event. Yes, but if you think in terms of abstractions, they're both just steps in the conceptual process of creating the object. If I ask GTK to create me a Button, I don't care how many steps it has to go through of allocating memory, allocating other resources, etc, etc, etc. All I want is to be able to write: foobar = Button(Foo Bar) and, at the end of it, to have a Button that I can toss onto a window. That's the job of a constructor - to give me an object in a state that I can depend on. (And this is completely independent of language. Modulo trivialities like semicolons, adorned names, etc, etc, I would expect that this be valid in any object oriented GUI toolkit in any object oriented language.) The difference between __new__ and __init__ is important when you write either method, but not when you use the class. It's like writing other dunder methods. You care about the distinction between __add__ and __radd__ when you write the methods, but in all other code, all that matters is that it does what you want: three = Three() four = three + 1 four == 1 + three The two methods could have been done as a single method, __construct__, in which you get passed a cls instead of a self, and you call self=super().__construct__() and then initialize stuff. It would then be obvious that this is the constructor. So maybe it's best to talk about the two methods collectively as the constructor, and then let people call the two parts whatever they will. I do like the idea of calling __init__ the initializer. The downside of calling __new__ the constructor is that it'll encourage C++ and Java programmers to override it and get themselves confused, when really they should have been writing __init__ and having an easy time of it. So, current best suggestion is allocator for that? Not entirely sure that's right, but it's not terrible. I'm +1 on __init__ being documented as the initializer, and +0 on allocator for __new__. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Fri, 31 Jan 2014 22:16:59 -0500, Terry Reedy wrote:
Creating a painting on canvas has two similar phases. Prepare a generic
blank canvas stretched on a frame and coated with a white undercoat.
Paint a particular picture. Would you say that the second step is not
creating anything?
A dubious analogy, since there are artists who would say that attacking
the canvas with a knife and setting the remains on fire count as a form
of artistic creation :-)
Creation can mean various things in English. One might argue that the
only creation was the guy at the factory who made the canvas, and the
people who made the paints. After that comes the preparation stage,
followed by the splashing-paint-on-canvas stage.
If you want to use creating to refer to the splashing-paint stage, then
I think the closest analogy in Python is the stuff which happens *after*
__init__ is called. Using a class often means modifying it as you go (in
much the same way that using a canvas requires modifying it as you go),
and it's never *completely* prepared until just before you stop using it.
One adds data, modifies the data, moves data from one attribute to
another, sets up temporary data attributes, calls methods which modify
the instance, and finally get the final answer you want, at which point
your task is done and the instance is thrown away. Think of a dict:
d = {} # Dict is constructed.
for key in data:
key = process(key)
if condition():
d[key] = something(key)
Is all that work also not part of the object construction process? If we
write it like this:
d = dict(something(key) for key in map(process, data) if condition())
you'd probably call it the constructor. But the two bits of code do the
same thing.
While we talk about a constructor as if the process of constructing an
object was black and white with a clear and obvious dividing line, in
practice its often fuzzy, with a lot of grey. (That's one of the
objections the functional crowd has with mutable objects.)
So to answer your question: no, in context of programming, I would *not*
call the putting-paint-to-canvas stage of artist painting to be
creation. I would call it *using* the constructed object (the canvas).
Whether that *use* of the canvas happens to be *artistic* creation or
mere derivative pap is another story :-)
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
In article 52ec84bc$0$29972$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 31 Jan 2014 22:16:59 -0500, Terry Reedy wrote: Creating a painting on canvas has two similar phases. Prepare a generic blank canvas stretched on a frame and coated with a white undercoat. Paint a particular picture. Would you say that the second step is not creating anything? A dubious analogy, since there are artists who would say that attacking the canvas with a knife and setting the remains on fire count as a form of artistic creation :-) That's __del__() -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
On 1 February 2014 12:34, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 1, 2014 at 12:14 PM, Scott W Dunning swdunn...@cox.net wrote: Also, I think I found out through a little trial and error that I had two different hours, mins, and sec so I had to use one uppercase and one lower case. Is that frowned upon? And should I have come up with a different name instead? SECONDS = 1 MINUTES = 60 * SECONDS HOURS = 60 * MINUTES What is actually being defined here are constants to be used for scaling or conversion of some quantity (a time) into different units. So in this situation would I define the conversion constant with an upper case name like this: SECONDS_PER_MINUTE = 60 and I would use it like this seconds = minutes * SECONDS_PER_MINUTE where seconds and minutes are the names holding the numeric data. That line has the extra benefit that it is clear to me why the units are seconds on both sides of the equals sign (because on the right hand side the minute-units cancel thus: m*s/m=s), whereas this is much less clear to me in Scott's line. Scott's message quoted above did not reach me, only Chris's quote of it, so I say: Scott once you begin a discussion on a mailing list like this one, please make sure that every reply you make goes to python-list@python.org and not to the individual. That way we can all participate in the discussion, that is best for everyone especially you. -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Saturday, February 1, 2014 10:53:08 AM UTC+5:30, Steven D'Aprano wrote:
On Fri, 31 Jan 2014 22:16:59 -0500, Terry Reedy wrote:
Creating a painting on canvas has two similar phases. Prepare a generic
blank canvas stretched on a frame and coated with a white undercoat.
Paint a particular picture. Would you say that the second step is not
creating anything?
A dubious analogy, since there are artists who would say that attacking
the canvas with a knife and setting the remains on fire count as a form
of artistic creation :-)
Creation can mean various things in English. One might argue that the
only creation was the guy at the factory who made the canvas, and the
people who made the paints. After that comes the preparation stage,
followed by the splashing-paint-on-canvas stage.
If you want to use creating to refer to the splashing-paint stage, then
I think the closest analogy in Python is the stuff which happens *after*
__init__ is called. Using a class often means modifying it as you go (in
much the same way that using a canvas requires modifying it as you go),
and it's never *completely* prepared until just before you stop using it.
One adds data, modifies the data, moves data from one attribute to
another, sets up temporary data attributes, calls methods which modify
the instance, and finally get the final answer you want, at which point
your task is done and the instance is thrown away. Think of a dict:
d = {} # Dict is constructed.
for key in data:
key = process(key)
if condition():
d[key] = something(key)
Is all that work also not part of the object construction process? If we
write it like this:
d = dict(something(key) for key in map(process, data) if condition())
you'd probably call it the constructor. But the two bits of code do the
same thing.
While we talk about a constructor as if the process of constructing an
object was black and white with a clear and obvious dividing line, in
practice its often fuzzy, with a lot of grey. (That's one of the
objections the functional crowd has with mutable objects.)
So to answer your question: no, in context of programming, I would *not*
call the putting-paint-to-canvas stage of artist painting to be
creation. I would call it *using* the constructed object (the canvas).
Whether that *use* of the canvas happens to be *artistic* creation or
mere derivative pap is another story :-)
http://en.wikipedia.org/wiki/Four_causes
[Replace cause by create(ion) ]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
So, this is what I came up with. It works, which is good but it’s a little different from a few things you guys had mentioned. For one, I got the correct time by calculating the number of time run and converting that into seconds then back out to hr:mn:sc. I didn’t calculate from midnight. That seemed more complicated to me because I’d have to figure the number of seconds from midnight to 6:52am then do the calculations for number of seconds run until I got home, then I got kind of lost. Also, before I forget what is the difference between / and //? I remember somthing about floor division? Not sure what that means though. Is it like a % where it gives the remainder after dividing? Thanks again. Code below. Also, I think I found out through a little trial and error that I had two different hours, mins, and sec so I had to use one uppercase and one lower case. Is that frowned upon? And should I have come up with a different name instead? SECONDS = 1 MINUTES = 60 * SECONDS HOURS = 60 * MINUTES time_left_house = 6 * HOURS + 52 * MINUTES miles_run_easy_pace = 2 * (8 * MINUTES + 15 * SECONDS) miles_run_fast_pace = 3 * (7 * MINUTES + 12 * SECONDS) time_returned_home = miles_run_easy_pace + miles_run_fast_pace + time_left_house hours = time_returned_home // HOURS part_hour = time_returned_home % HOURS minutes = part_hour // MINUTES seconds = part_hour % MINUTES print Time returned home:, hours,:, minutes,:, seconds,am On Jan 31, 2014, at 6:51 AM, Neil Cerutti ne...@norwich.edu wrote: On 2014-01-31, scottw...@gmail.com scottw...@gmail.com wrote: Here is the question that was asked and below that I'll paste the code I have so far. **If I leave my house at 6:52 am and run 1 mile at an easy pace (8:15 per mile), then 3 miles at tempo (7:12 per mile) and 1 mile at easy pace again, what time do I get home for breakfast?** That depends on the directions in which you run. Also, you are fast! But seriously, my advice is to find the answer the old fashioned way first, with pencil and paper. Then you'll have two things you don't now: 1. A correct answer to test your program's answer with. 2. A general idea of how to solve the problem. It's often a mistake to start writing code. Eventually you'll be able to go directly from problem to code more often, but it will take practice. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
You guys are awesome! I think I was over complicating things for one. Plus I was looking at some code I wrote for another problem that asked to put in the number of seconds to calculate the problem and I didn’t need some of the things I added to this problem. Anyways, you guys have given me a lot of help and I think I can get it now. I’ll post what I got when I’m done so you guys can help with unnecessary code if needed or just to see how you helped. On Jan 31, 2014, at 6:51 AM, Neil Cerutti ne...@norwich.edu wrote: On 2014-01-31, scottw...@gmail.com scottw...@gmail.com wrote: Here is the question that was asked and below that I'll paste the code I have so far. **If I leave my house at 6:52 am and run 1 mile at an easy pace (8:15 per mile), then 3 miles at tempo (7:12 per mile) and 1 mile at easy pace again, what time do I get home for breakfast?** That depends on the directions in which you run. Also, you are fast! But seriously, my advice is to find the answer the old fashioned way first, with pencil and paper. Then you'll have two things you don't now: 1. A correct answer to test your program's answer with. 2. A general idea of how to solve the problem. It's often a mistake to start writing code. Eventually you'll be able to go directly from problem to code more often, but it will take practice. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Also, can any of you reccommend sites that may have little “projects” that I could work on to help me learn python better? On Jan 31, 2014, at 1:30 AM, Chris Angelico ros...@gmail.com wrote: On Fri, Jan 31, 2014 at 7:17 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: sjud9227 wrote: Doesn't assigning seconds/(60*60) mean that calculating 6*hours will give me 6 hours in seconds? No, it's giving you 6 seconds in hours. (That should give you a clue as to what you should have done instead. :-) ... a // b gives the quotient of dividing a by b a % b gives the remainder (I recommend using '//' rather than just '/', because in some versions of Python, a/b does floating point division even if a and b are both integers, and that's not what you want here.) OP is using 2.7.6, so short of a __future__ directive, that won't actually give 6 seconds in hours (though it will try to), and // is unnecessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Also, any help on how to get the hours and seconds into double digits that would be cool too. 00:00:00 On Jan 31, 2014, at 1:30 AM, Chris Angelico ros...@gmail.com wrote: On Fri, Jan 31, 2014 at 7:17 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: sjud9227 wrote: Doesn't assigning seconds/(60*60) mean that calculating 6*hours will give me 6 hours in seconds? No, it's giving you 6 seconds in hours. (That should give you a clue as to what you should have done instead. :-) ... a // b gives the quotient of dividing a by b a % b gives the remainder (I recommend using '//' rather than just '/', because in some versions of Python, a/b does floating point division even if a and b are both integers, and that's not what you want here.) OP is using 2.7.6, so short of a __future__ directive, that won't actually give 6 seconds in hours (though it will try to), and // is unnecessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
If you’re interested in what the problem is here it is…
Suppose the cover price of a book is $24.95, but bookstores get a 40% discount.
Shipping costs $3 for the first copy and 75 cents for each additional copy.
What is the total wholesale cost for 60 copies?
On Jan 31, 2014, at 10:18 PM, Scott W Dunning swdunn...@cox.net wrote:
Any chance you guys could help with another question I have? Below is a code
to a different problem. The only thing I don’t understand is why when
calculating the 'discounted price’ you have to subtract 1? Thanks again
guys!
price_per_book = 24.95
discount = .40
quantity = 60
discounted_price = (1-discount) * price_per_book
shipping = 3.0 + (60 - 1) * .75
total_price = 60 * discounted_price + shipping
print total_price, 'Total price'
Scott
On Jan 31, 2014, at 8:02 PM, Denis McMahon denismfmcma...@gmail.com wrote:
On Thu, 30 Jan 2014 21:12:19 -0800, scottwd80 wrote:
Here is the question that was asked and below that I'll paste the code I
have so far.
The following is a reasonably but not highly obfuscated short solution to
the problem set in python 2.7. With a bit of luck, after each lesson of
your course, you'll be able to understand a bit more of how it works.
M=60;H=M*60
def s(h,m,s): return h*H+m*M+s
def hms(s): return (int(s/H),int((s%H)/M),s%M)
(a,b,c)=hms(s(6,52,0)+3*s(0,7,12)+2*s(0,8,15))
print {:02d}:{:02d}:{:02d}.format(a,b,c)
When you can write a short paragraph describing what each line of the
program does, you'll be on your way to understanding a few of the
structures, syntaxes and mechanisms of python.
Or you could show it to your lecturer or a TA and say it was suggested
that you ask her or him to work through it with you.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Thanks Chris! So, this is what I came up with. It works, which is good but it’s a little different from a few things you guys had mentioned. For one, I got the correct time by calculating the number of time run and converting that into seconds then back out to hr:mn:sc. I didn’t calculate from midnight. That seemed more complicated to me because I’d have to figure the number of seconds from midnight to 6:52am then do the calculations for number of seconds run until I got home, then I got kind of lost. Also, before I forget what is the difference between / and //? I remember something about floor division? Not sure what that means though. Is it like a % where it gives the remainder after dividing? Thanks again. Code below. Also, I think I found out through a little trial and error that I had two different hours, mins, and sec so I had to use one uppercase and one lower case. Is that frowned upon? And should I have come up with a different name instead? SECONDS = 1 MINUTES = 60 * SECONDS HOURS = 60 * MINUTES time_left_house = 6 * HOURS + 52 * MINUTES miles_run_easy_pace = 2 * (8 * MINUTES + 15 * SECONDS) miles_run_fast_pace = 3 * (7 * MINUTES + 12 * SECONDS) time_returned_home = miles_run_easy_pace + miles_run_fast_pace + time_left_house hours = time_returned_home // HOURS part_hour = time_returned_home % HOURS minutes = part_hour // MINUTES seconds = part_hour % MINUTES print Time returned home:, hours,:, minutes,:, seconds,”am On Jan 31, 2014, at 5:57 PM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 1, 2014 at 11:42 AM, Scott W Dunning swdunn...@cox.net wrote: Also, any help on how to get the hours and seconds into double digits that would be cool too. 00:00:00 Once you can divide the number of seconds into hours, minutes, and seconds, you can format them like this: time = %02d:%02d:%02d % (hours, minutes, seconds) I'll give you that one for free because I don't think it's particularly critical to your course, but it will look better that way :) Look up the string formatting features of Python in the docs. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Dunder [was Re: __init__ is the initialiser]
On Sat, Feb 1, 2014 at 1:52 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Constructor is three syllables; ctor isn't readily pronounceable in English at all, rather like Cthulhu. (I can't think of any standard English words with a CT in them at all, let alone at the start of the word). The best I can come up with is KUH TOR or possibly SEE TOR, both of which are clumsy, and only save a single syllable. May I tactfully suggest that searching the abstract of a dictionary for the letters 'ct' would be a useful action here. Actually, you could collect a compact list of words containing ct, and maybe even concoct a paragraph of text that conflicts with the theory that this is a rare conjunction of characters. Hopefully this will convict you of the correctness of what I am saying - though it does not at all deduct from your main point to the effect that few or no English words would be depicted *starting* with these letters. I mean no disrespect to you, Steven, but in dissecting your words, I expect myself to exactly demonstrate the imperfect (I won't say incorrect, as I don't have a doctorate in this) information here, to ensure that it does not infect the structure of python-list. We are all persons of intellect, and we know how to interact without getting intractable; all I want to do is offer an introduction to the results of grep|less, not to give a lecture. I apologize if this comes across harshly, but the neglect of manners may be a consequence of my nocturnal exertions of late, with the objective of removing all obstructions to converting to Linux before I'm an octogenarian. [1] Let us make a pact to view matters from each other's perspective, as we picture a more practical projection of life, with a reasonable prospect of rejecting unpleasantness and resurrecting the on-topic discussions that we might otherwise have. In retrospect, I perhaps shouldn't have started writing this, and it may be time to impose sanctions on me for not being more selective in my use o English; this is becoming a spectacular flop, a spectre to haunt me. Strictly between ourselves, wordplay is a subject which (I suspect) is unattractive to many, but it would be uncharacteristic of me to refrain. I leave the final verdict up to you: are you the victims of a horrible plot, or will your vindictive anger be turned aside? Ahem. I'd probably pronounce it k'tor, like your first option but with a really short schwa in there; or - more likely - I'd spell it ctor and pronounce it constructor. ChrisA [1] Okay, that one's really pushing it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On 1/31/2014 8:52 PM, Chris Angelico wrote: On Sat, Feb 1, 2014 at 12:45 PM, Terry Reedy tjre...@udel.edu wrote: H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py caused this message UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14: invalid start byte So... something's interpreting \0 as codepoint U+ (which it shouldn't), storing that in UTF-8 as 0xC0 0x80 (which it shouldn't), and then giving it to Python to decode. Right. Which is why it puzzled me. Credit Serhiy for unraveling this and fixing it. That's a weird little combination bug right there. Which started with Microsoft's decision to reuse the string excape character '\' as a directory separator. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Ok cool, thanks Denis!
On Jan 31, 2014, at 8:02 PM, Denis McMahon denismfmcma...@gmail.com wrote:
On Thu, 30 Jan 2014 21:12:19 -0800, scottwd80 wrote:
Here is the question that was asked and below that I'll paste the code I
have so far.
The following is a reasonably but not highly obfuscated short solution to
the problem set in python 2.7. With a bit of luck, after each lesson of
your course, you'll be able to understand a bit more of how it works.
M=60;H=M*60
def s(h,m,s): return h*H+m*M+s
def hms(s): return (int(s/H),int((s%H)/M),s%M)
(a,b,c)=hms(s(6,52,0)+3*s(0,7,12)+2*s(0,8,15))
print {:02d}:{:02d}:{:02d}.format(a,b,c)
When you can write a short paragraph describing what each line of the
program does, you'll be on your way to understanding a few of the
structures, syntaxes and mechanisms of python.
Or you could show it to your lecturer or a TA and say it was suggested
that you ask her or him to work through it with you.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help with some python homework...
Any chance you guys could help with another question I have? Below is a code
to a different problem. The only thing I don’t understand is why when
calculating the 'discounted price’ you have to subtract 1? Thanks again guys!
price_per_book = 24.95
discount = .40
quantity = 60
discounted_price = (1-discount) * price_per_book
shipping = 3.0 + (60 - 1) * .75
total_price = 60 * discounted_price + shipping
print total_price, 'Total price'
Scott
On Jan 31, 2014, at 8:02 PM, Denis McMahon denismfmcma...@gmail.com wrote:
On Thu, 30 Jan 2014 21:12:19 -0800, scottwd80 wrote:
Here is the question that was asked and below that I'll paste the code I
have so far.
The following is a reasonably but not highly obfuscated short solution to
the problem set in python 2.7. With a bit of luck, after each lesson of
your course, you'll be able to understand a bit more of how it works.
M=60;H=M*60
def s(h,m,s): return h*H+m*M+s
def hms(s): return (int(s/H),int((s%H)/M),s%M)
(a,b,c)=hms(s(6,52,0)+3*s(0,7,12)+2*s(0,8,15))
print {:02d}:{:02d}:{:02d}.format(a,b,c)
When you can write a short paragraph describing what each line of the
program does, you'll be on your way to understanding a few of the
structures, syntaxes and mechanisms of python.
Or you could show it to your lecturer or a TA and say it was suggested
that you ask her or him to work through it with you.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On 1/31/2014 10:36 PM, Chris Angelico wrote: On Sat, Feb 1, 2014 at 1:54 PM, MRAB pyt...@mrabarnett.plus.com wrote: I think that some years ago I heard about a variation on UTF-8 (Microsoft?) where codepoint U+ is encoded as 0xC0 0x80 so that the null byte can be used as the string terminator. I had a look on Wikipedia found this: http://en.wikipedia.org/wiki/Null-terminated_string Yeah, it's a common abuse of UTF-8. It's a violation of spec, but an understandable one. However, I don't understand why the first part - why should \0 become U+ but (presumably) the \a later on (...cs\accel...) doesn't become U+0007, etc? Because only \0 has a special meaning in a C string, and Tk is written in C and uses C strings. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On 01/31/2014 08:35 PM, Chris Angelico wrote: On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano wrote: Thus, two methods. __new__ constructs (creates, allocates) a new object; __init__ initialises it after the event. Yes, but if you think in terms of abstractions, they're both just steps in the conceptual process of creating the object. So maybe it's best to talk about the two methods collectively as the constructor, and then let people call the two parts whatever they will. I do like the idea of calling __init__ the initializer. The downside of calling __new__ the constructor is that it'll encourage C++ and Java programmers to override it and get themselves confused Why do we worry so about other languages? If and when I go to learn C++ or Lisp, I do not expect their devs to be worrying about making their terminology match Python's. Part of the effort is in learning what the terms mean, what the ideology is, the differences, the similarities, etc., etc.. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: fseek In Compressed Files
On Thursday, January 30, 2014 9:51:28 PM UTC+5:30, Peter Otten wrote: Serhiy Storchaka wrote: 30.01.14 13:28, Peter Otten написав(ла): Ayushi Dalmia wrote: I need to randomly access a bzip2 or gzip file. How can I set the offset for a line and later retreive the line from the file using the offset. Pointers in this direction will help. with gzip.open(filename) as f: f.seek(some_pos) print(f.readline()) f.seek(some_pos) print(f.readline()) seems to work as expected. Can you tell a bit more about your usecase (if it isn't covered by that basic example)? I don't recommend to seek backward in compressed file. This is very inefficient operation. Do you know an efficient way to implement random access for a bzip2 or gzip file? Nothing that I know of. -- https://mail.python.org/mailman/listinfo/python-list
Re: __init__ is the initialiser
On Sat, 01 Feb 2014 15:35:17 +1100, Chris Angelico wrote: On Sat, Feb 1, 2014 at 2:42 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I've met people who have difficulty with OOP principles, at least at first. But once you understand the idea of objects, it isn't that hard to understand the idea that: - first, the object has to be created, or constructed, or allocated if you will; - only then can it be initialised. Thus, two methods. __new__ constructs (creates, allocates) a new object; __init__ initialises it after the event. Yes, but if you think in terms of abstractions, they're both just steps in the conceptual process of creating the object. If I ask GTK to create me a Button, I don't care how many steps it has to go through of allocating memory, allocating other resources, etc, etc, etc. You deleted the part of my post where I suggested that it's only a historical accident that Python has two methods for constructing an object when most OOP languages get by with one. All I want is to be able to write: foobar = Button(Foo Bar) and, at the end of it, to have a Button that I can toss onto a window. That's the job of a constructor - to give me an object in a state that I can depend on. You're assuming your conclusion. Why is it the job of the constructor, rather than the initialiser? When I buy a house, it is fully constructed, but it's not yet usable -- there's no bed, no fridge, no furniture of any sort, just a bare shell with a roof and some built-in cupboards and perhaps an oven. I have to initialise the house myself with whatever furniture I need. Even if it's a fully furnished house, I still have to initialise it before I can say it's truly usable, even if that is merely emptying my suitcase into the built-in robes. The curse of the discontinuous mind: we look for hard dividing lines between black and white when what we really have is shades of grey. It's easy to tell when an int is constructed and ready to use, and sure enough it uses __new__ and has a do-nothing __init__. But with mutable objects, say a list, when is it constructed and ready to use? Suppose you want to create a list of items and extract the third smallest item. When is the list constructed and ready to use? - Is it when the memory is allocated for the object? Obviously not, since we can't do anything with it yet. - How about when the object fields are set up and made consistent? (Array is blanked, length set to the correct value, pointer to the class set, etc.) This makes a good candidate, since this is the earliest that the object is in a consistent state. - Is it when the list items are placed into the array? This is also a good candidate, since this is the earliest that the list has the items we expect. Assuming we expect any -- since many lists are created as simply [], then populated later, this isn't exactly black and white either. - Or when it is sorted? Probably not here, although this is the earliest that the user can *actually* use the list for what they wanted it for, namely to extract the third largest value. When does a pile of computer parts become a computer? When the CPU is plugged in? When the mouse is attached? Somewhere in between? We have difficulty drawing dividing lines because our minds are discontinuous but reality is continuous. [...] The difference between __new__ and __init__ is important when you write either method, but not when you use the class. It's like writing other dunder methods. You care about the distinction between __add__ and __radd__ when you write the methods, but in all other code, all that matters is that it does what you want: Yes. And your point is? Speaking as an end user, call the constructor to refer to: instance = MyClass(arg) is exactly right, because the constructor is called regardless of whether __new__ is called alone, or __new__ and __init__. [...] The two methods could have been done as a single method, __construct__, in which you get passed a cls instead of a self, and you call self=super().__construct__() and then initialize stuff. That would be called __new__ in Python. There's no *need* to use __init__ for anything (except old-style classic classes in Python 2). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: fseek In Compressed Files
On Friday, January 31, 2014 12:16:59 AM UTC+5:30, Dave Angel wrote: Ayushi Dalmia ayushidalmia2...@gmail.com Wrote in message: On Thursday, January 30, 2014 4:20:26 PM UTC+5:30, Ayushi Dalmia wrote: Hello, I need to randomly access a bzip2 or gzip file. How can I set the offset for a line and later retreive the line from the file using the offset. Pointers in this direction will help. We are not allowed to use databases! I need to do this without database. Why do you reply to your own message? Makes it hard for people to make sense of your post. Have you any answers to earlier questions? How big is this file, what python version, do you care about performance, code you've tried, ... -- DaveA The size of this file will be 10 GB. The version of Python I am using is 2.7.2. Yes, performance is an important issue. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dunder [was Re: __init__ is the initialiser]
On Sat, 01 Feb 2014 15:05:34 +1100, Chris Angelico wrote: On Sat, Feb 1, 2014 at 1:52 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Constructor is three syllables; ctor isn't readily pronounceable in English at all, rather like Cthulhu. (I can't think of any standard English words with a CT in them at all, let alone at the start of the word). The best I can come up with is KUH TOR or possibly SEE TOR, both of which are clumsy, and only save a single syllable. May I tactfully suggest that searching the abstract of a dictionary for the letters 'ct' would be a useful action here. Point taken :-P I did say that *I* couldn't think of any. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
On Fri, 31 Jan 2014 17:42:30 +1100, Chris Angelico wrote: On Fri, Jan 31, 2014 at 5:28 PM, Dan Sommers d...@tombstonezero.net wrote: ObPython: My program retrieves temperatures (in Kelvins) from an external device (the details of which I am not at liberty to discuss) and stores them in the cloud (because that's where all the cool kids store data these days), and there's something really weird going on. $ python ./program.py temperature1 is -100 K temperature2 is 100 K temperature2 is hotter than temperature1 But everyone knows that -100K is hotter than 100K. I tried converting to UTC, but that didn't help. What am I missing? I'm sorry, you have completely misunderstood the problem here. You are storing data in the cloud, which means you're representing everything with water. It is therefore fundamentally illogical to use any temperature outside the range [273.15K, 373.15K], because otherwise your cloud will freeze or boil, and either way, it'll crash badly. I think I found the problem: it's not a water cloud, it's a potassium sulfide cloud, and as its temperatures rose, I lost the special Ks. Plus, converting to UTC? Puh-leeze. You should be using kilogram meters per second. It was a momentary lapse of reason. Sorry. Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Python shell wont open idle or an exisiting py file
On Sat, Feb 1, 2014 at 4:46 PM, Terry Reedy tjre...@udel.edu wrote: On 1/31/2014 10:36 PM, Chris Angelico wrote: On Sat, Feb 1, 2014 at 1:54 PM, MRAB pyt...@mrabarnett.plus.com wrote: I think that some years ago I heard about a variation on UTF-8 (Microsoft?) where codepoint U+ is encoded as 0xC0 0x80 so that the null byte can be used as the string terminator. I had a look on Wikipedia found this: http://en.wikipedia.org/wiki/Null-terminated_string Yeah, it's a common abuse of UTF-8. It's a violation of spec, but an understandable one. However, I don't understand why the first part - why should \0 become U+ but (presumably) the \a later on (...cs\accel...) doesn't become U+0007, etc? Because only \0 has a special meaning in a C string, and Tk is written in C and uses C strings. Eh? I've used \a in C programs (not often but I have used it). It's possible that \0 is the only one that actually bombs anything (because of C0 80 representation). But since \7 and \a both represent 0x07 in a C string, I would expect there to be other problems, if it's interpreting it as source. Ah well! Weird weird. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue20452] test_timeout_rounding() of test_asyncio fails on x86 Ubuntu Shared 3.x buildbot
New submission from STINNER Victor: The failure is minor, it's just a suboptimal code. Calling _run_once() 4 times instead of 3. http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9630/steps/test/logs/stdio == FAIL: test_timeout_rounding (test.test_asyncio.test_events.EPollEventLoopTests) -- Traceback (most recent call last): File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_events.py, line 1180, in test_timeout_rounding self.assertEqual(calls, [1, 3, 5, 6]) AssertionError: Lists differ: [1, 4, 6, 7] != [1, 3, 5, 6] First differing element 1: 4 3 - [1, 4, 6, 7] + [1, 3, 5, 6] I'm unable to reproduce the error on my Linux box. When we had the rounding away from zero in epoll directly, the epoll test failed on the same buildbot: http://bugs.python.org/issue20311#msg208601 http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.3/builds/1360/steps/test/logs/stdio == FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) -- Traceback (most recent call last): File /srv/buildbot/buildarea/3.3.bolen-ubuntu/build/Lib/test/test_epoll.py, line 58, in test_timeout_rounding self.assertGreaterEqual(dt, timeout) AssertionError: 0.009388947859406471 not greater than or equal to 0.01 -- components: Tests messages: 209749 nosy: gvanrossum, haypo priority: normal severity: normal status: open title: test_timeout_rounding() of test_asyncio fails on x86 Ubuntu Shared 3.x buildbot versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20451] os.exec* mangles argv on windows (splits on spaces, etc)
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
