[Tutor] (no subject)
I have been reading a book on Python. I am currently stuck with one of
the exercises and so wanted to ask you if you can help me.
Of course, if you have the time.
Exercise : Ask the user to input 3 integers and prints out the largest odd
number. if no odd number was entered it should print a message o that
effect.
These lines of code don't work :
a = raw_input('enter number: ')
b = raw_input('enter number: ')
c = raw_input('enter number: ')
list = [ a, b, c]
list2 =[ ]
for x in list:
if x%2 == 1: # responsible for the type error: not all arguments
converted during string #
#formatting
list2.append(x)
print list2
w = max(list2)
print ' %d is the largest odd number.' % w
# i don't know but maybe I have to return the list for this to work?
Because if I assign a
#variable to to 3 integers, like the code below it works.
But these do:
a = 3
b = 7
c = 9
list = [ a, b, c]
list2 =[]
for x in list:
if x%2 == 1:
list2.append(x)
print list2
w = max(list2)
print ' %d is the largest odd number.' % w
#Thank you for your time.
Sincerely ,
Job
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] (no subject)
On 25/07/15 02:49, Job Hernandez wrote:
These lines of code don't work :
a = raw_input('enter number: ')
b = raw_input('enter number: ')
c = raw_input('enter number: ')
raw_input() returns a string. So if you enter 6,
say, it is stored as the character '6' not the
number 6. You need to use the int() function to
convert it to an integer or float() to convert
it to a floating point number. eg.
c = int(raw_input('enter number: '))
list = [ a, b, c]
A small point: its not a good idea to use the
type name as your variable because that then
hides the function used to convert things to lists.
ie you can no longer do
>>> list('abc')
['a','b','c']
Its better to use names that describe the content
of the data, so in your case something like inputs
or numbers.
Just a small point which makes no difference in
this example but might trip you up in future.
list2 =[ ]
for x in list:
if x%2 == 1: # responsible for the type error: not all arguments
You get the error because you are trying to divide
a character by a number. If you convert to int()
up above then it will go away.
list2.append(x)
print list2
w = max(list2)
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] How to generate a pure tones and random noise using Python?
Hi All, I try to train my listening by using python. (estimating the frequency of sound) So... Are there some way to generate a fixed frequency sound in different waves (eg. Sine Wave, Saw Wave, Triangle Wave etc.) and different random noise. (eg. white noise & pink noise) ? I have search in web, some people say that I can use winsound which can generate a fixed frequency beep. However, It is Windows only. (I'm under Linux) and I think It is not a professional library to generate audio signal. How about pygame? and some examples? any ideas? Thanks Paul Z ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How to generate a pure tones and random noise using Python?
In a message of Sat, 25 Jul 2015 19:15:31 +0800, Paul Z writes: >Hi All, > >I try to train my listening by using python. (estimating the frequency of >sound) >So... Are there some way to generate a fixed frequency sound in different >waves (eg. Sine Wave, Saw Wave, Triangle Wave etc.) and different random >noise. (eg. white noise & pink noise) ? > >I have search in web, some people say that I can use winsound which can >generate a fixed frequency beep. However, It is Windows only. (I'm under >Linux) and I think It is not a professional library to generate audio signal. > >How about pygame? and some examples? >any ideas? > >Thanks > >Paul Z >___ >Tutor maillist - Tutor@python.org >To unsubscribe or change subscription options: >https://mail.python.org/mailman/listinfo/tutor I think you want this: https://zach.se/generate-audio-with-python/ https://github.com/zacharydenton/wavebender pygame will not give you want you want. blender might. I am not sure but worth googling for. Laura ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages
After having a long discussion with my wife on her user requirements, I am convinced that an OO approach is required. Which is just as well as that has been one of my next areas of learning to do. I am currently reading "Python 3 Object Oriented Programming" by Dusty Phillips, which so far seems to be a reasonably good text. This has led me to the subject line topics. >From my understandings to date: 1) A single underscore is used conventionally for a "throw-away" variable, such as a loop index for which the index value is not actually used in a subsequent calculation. 2) _name is used inside class methods to indicate that the programmer's intention is that this name should only be accessed internally by that particular class. Other supposedly "adult" Python programmers will attempt to respect this original intent if they use my code. 3) __name invokes Python's name mangling mechanism. The intent of this usage is to not allow subclasses of the class containing __name to access this name, and to add additional emphasis to future users of my code that this name is meant to be strictly hands-off. 4) name_ is used when one is "forced" to use one of Python's reserved words as a name. 5) __name__ is meant to be used only by the creators of Python for their special built-in methods, such as __init__, __new__, etc. Are my understandings above correct or flawed? For (3), it seems to me that one would normally be able to use the simpler _name construction from (2). What would be a best-practice example of when name mangling *should* be used? Likewise, it seems that normally (4) should never be needed, though I have a feeling that I have seen something in tkinter recently that suggests some exceptions, but I cannot (yet) bring it to mind. And for (5), surely I should never violate this one? It seems that in some future edition of Python they might add any particular __name__ that I might try to use presently in their future version of Python (however miniscule that possibility might actually be). Thanks! boB -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages
In a message of Sat, 25 Jul 2015 16:08:03 -0500, boB Stepp writes: >After having a long discussion with my wife on her user requirements, >I am convinced that an OO approach is required. Which is just as well >as that has been one of my next areas of learning to do. I am >currently reading "Python 3 Object Oriented Programming" by Dusty >Phillips, which so far seems to be a reasonably good text. This has >led me to the subject line topics. > >>From my understandings to date: > >1) A single underscore is used conventionally for a "throw-away" >variable, such as a loop index for which the index value is not >actually used in a subsequent calculation. Some people do this. I find it irritatingly twee, and hard to read as well. I like 'junk' for such things. >2) _name is used inside class methods to indicate that the >programmer's intention is that this name should only be accessed >internally by that particular class. Other supposedly "adult" Python >programmers will attempt to respect this original intent if they use >my code. The world is packed very full of Python programmers who have never heard of this rule, and thus this is sort of a 'pious hope' more than anything else. The world is also full of python modules that have no single underscore variable names at all. >3) __name invokes Python's name mangling mechanism. The intent of >this usage is to not allow subclasses of the class containing __name >to access this name, and to add additional emphasis to future users of >my code that this name is meant to be strictly hands-off. worry about this when you want to share your code with the world and don't want new users to be able to rely on things to always be the way you have it right now. i.e. adding double underscores is often the last thing you do before release. >4) name_ is used when one is "forced" to use one of Python's reserved >words as a name. You are never forced to. Sometimes you might want to. Sometimes name_ is a good choice in this case. But in my life 'stop wanting this, you arrogant wretch' has mostly been the correct thing. :) (At least I think never. Maybe I am being an arrogrant wretch here, too.) >5) __name__ is meant to be used only by the creators of Python for >their special built-in methods, such as __init__, __new__, etc. > >Are my understandings above correct or flawed? Pretty much dead on. > >For (3), it seems to me that one would normally be able to use the >simpler _name construction from (2). What would be a best-practice >example of when name mangling *should* be used? If you do not mangle the names, you are making a promise, sometimes a half-hearted promise, that through the life of the code other people can come by and use these methods, with exactly this signature, and it will just work. This is called 'being Part of the public API'. If you publish such things and then, next release, remove those methods or change the number or order of the arguments their code will break. If its just you and your tapeworm, you don't care and you make and remove methods and signatures all the time. If people do not like it, tough, and so it goes. It's what they get for running your experimental software. If you publish your code as a module on PyPI people will find ways to use the public API, so if you want to reserve the right to delete this method later, or change it's signature then by all means mangle the thing. In the Python world people are generally less worried about what will happen if some wretch gets a hold of a method that I didn't really want as part of the public API than what will happen if they badly need to get a hold of a method and I didn't make it possible. This makes for a lot of the single underscore variables. 'I don't want to make it impossible for you to access things this way, but I wish you wouldn't' more or less. > >Likewise, it seems that normally (4) should never be needed, though I >have a feeling that I have seen something in tkinter recently that >suggests some exceptions, but I cannot (yet) bring it to mind. Not sure what you are thinking about. >And for (5), surely I should never violate this one? It seems that in >some future edition of Python they might add any particular __name__ >that I might try to use presently in their future version of Python >(however miniscule that possibility might actually be). Right. Don't go there. > >Thanks! >boB > >-- >boB MY .02 euros. Others will have other ideas. but that is the way I see it. Laura ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages
On Saturday, July 25, 2015, boB Stepp > wrote: > > 5) __name__ is meant to be used only by the creators of Python for > their special built-in methods, such as __init__, __new__, etc. Everything up to this point was pretty accurate. You're only half right with this one, though; __dunder__ names are ones that you should only use when hooking into the "magic" of the interpreter. That is, you should not define your own __dunder__ names, but feel free to use ones that have been defined by the implementation and documented as the way to do something. For example: class Spam: def __init__(self, value): self.value = value def __getitem__(self, key): return self.value assert Spam(42)['eggs'] == 42 __getitem__ is the documented method to implement to allow instances of your class to be indexed like a list or dict. Are my understandings above correct or flawed? > > For (3), it seems to me that one would normally be able to use the > simpler _name construction from (2). What would be a best-practice > example of when name mangling *should* be used? I have yet to ever see a place where name mangling was warranted. I have been severely annoyed by it before, though. To make a particular class work the way I wanted it to, I had to subclass it and explicitly override a couple of mangled names. In my opinion, name mangling should never be used unless overriding the value will set your CPU aflame. Likewise, it seems that normally (4) should never be needed, though I > have a feeling that I have seen something in tkinter recently that > suggests some exceptions, but I cannot (yet) bring it to mind. There are a couple of methods in tkinter that accept an 'in_' keyword argument, where in Tcl it is documented as 'in', which is a Python keyword. In code that's not interfacing with something else that uses a Python keyword, it's usually best to just find a different name. And for (5), surely I should never violate this one? It seems that in > some future edition of Python they might add any particular __name__ > that I might try to use presently in their future version of Python > (however miniscule that possibility might actually be). > Right, don't make up your own __dunder__ names. Hope this helps, -- Zach (On an iPad) -- Sent from Gmail Mobile ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages
On 25/07/2015 22:08, boB Stepp wrote: After having a long discussion with my wife on her user requirements, I am convinced that an OO approach is required. Which is just as well as that has been one of my next areas of learning to do. I am currently reading "Python 3 Object Oriented Programming" by Dusty Phillips, which so far seems to be a reasonably good text. This has led me to the subject line topics. From my understandings to date: 1) A single underscore is used conventionally for a "throw-away" variable, such as a loop index for which the index value is not actually used in a subsequent calculation. It is not a convention, it is inbuilt. It is very useful as linter type tools don't complain about you defining something but not using it. 2) _name is used inside class methods to indicate that the programmer's intention is that this name should only be accessed internally by that particular class. Other supposedly "adult" Python programmers will attempt to respect this original intent if they use my code. Correct. 3) __name invokes Python's name mangling mechanism. The intent of this usage is to not allow subclasses of the class containing __name to access this name, and to add additional emphasis to future users of my code that this name is meant to be strictly hands-off. 4) name_ is used when one is "forced" to use one of Python's reserved words as a name. I don't know about reserved words but it is certainly used rather than override a built-in name. 5) __name__ is meant to be used only by the creators of Python for their special built-in methods, such as __init__, __new__, etc. Correct. Are my understandings above correct or flawed? For (3), it seems to me that one would normally be able to use the simpler _name construction from (2). What would be a best-practice example of when name mangling *should* be used? I'd be inclined not to bother yourself with this. I've never used it in the centuries that I've been writing Python, and somebody who is determined enough can work around it anyway owing to Python's dynamic nature. Likewise, it seems that normally (4) should never be needed, though I have a feeling that I have seen something in tkinter recently that suggests some exceptions, but I cannot (yet) bring it to mind. If you like a name enough and cannot think of a better alternative why not? And for (5), surely I should never violate this one? It seems that in some future edition of Python they might add any particular __name__ that I might try to use presently in their future version of Python (however miniscule that possibility might actually be). Definitely. Thanks! boB No problem. Once again my invoice is in the post, your cheque by return please :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Socket Module
Thank you all for your responses. I have taken your feedback and made changes
to my code.
-Danny, per your suggestion, I have renamed some of my variables to make their
purpose little more clearer.
- Alan, I have created a new host list (ResolvedAddresses) which is storing
the output from socket.gethostbyaddr(address).
Here is the updated code: https://bpaste.net/show/358583e1a0bd
The issue that I am running into now is that for some reason, the script is not
resolving known-public IP addresses that I am passing through. For example,
some of the IPs, that I have used are for sites like facebook (173.252.120.6)
github (207.97.227.239), however the script is not able to resolve them.
But its interesting that I am able to resolve them using nslookup on windows
command prompt.
Which means my laptop's DNS setting is fine.
Looking forward to your feedback. Thanks!
Thank you.
On Monday, July 20, 2015 5:00 AM, Alan Gauld
wrote:
On 20/07/15 00:55, Nym City via Tutor wrote:
> Thank you for your response. I gave it another try:
> As suggested, first I ran the concept just in the terminal, and it worked
> fine:
names =['173.252.120.6', '98.139.183.24']
import socket
for name in names:
> socket.gethostbyaddr(name)
> print(name)
>
> output:
> ('edge-star-shv-12-frc3.facebook.com', [], ['173.252.120.6'])
> ('ir2.fp.vip.bf1.yahoo.com', [], ['98.139.183.24'])
Remember that the >>> prompt evaluates your results and
automatically prints them for you.
Thus
>>> 5 + 3
8
But if you put code in a script and execute it the interpreter
does NOT print out arbitrary expressions so a file add.py
containing just
5 + 3
will not output anything, you need the print function:
print(5+3)
to see the result.
So in the interpreter your gethostbyaddr() function is
evaluated AND printed. But in a script it will only be
evaluated...
> import csv
> import socket
>
> domains = []
>
> with open('top500ips.csv', 'r') as f:
> for line in f:
> line = line.strip()
> domains.append(line)
You are importing csv but not using it to read your file.
But I'll ignore that for now! (in fact it looks like the
csv file really only contains the IP addresses, one per
line so csv is probably redundant here.)
Also you could do all of the above in a single line with:
domains = [line.strip() for line in open('top500ips.csv')]
But none of that matters for your specific issue...
> for name in domains:
> socket.gethostbyaddr(name)
> print(name)
Notice here that you run the gethostbyaddr() function but
do nothing with the result. You don't store it and you
don't print it. Instead you print the initial name that
you passed in, which does not change.
You need to create a variable to store the host result
and then print that host. And since you want to store a
set of hosts you probably want to append the results to
a list of some kind (or a dictionary based on your names?)
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] _ vs. _name vs. __name vs. name_ vs. __name__ usages
boB Stepp writes: > From my understandings to date: > > 1) A single underscore is used conventionally for a "throw-away" > variable, such as a loop index for which the index value is not > actually used in a subsequent calculation. That accurately describes common usage. But it's important to also know that ‘_’ has numerous conflicting common usages (including a widely-used text translation function). Less common, but IMO much more preferable for “don't actually want this value but need to bind something to it”, is the convention ‘__’ as a name:: for (__, important_value) in sequence_of_tuples: ... The name ‘__’ doesn't AFAIK have conflicting usages (therefore more strongly connoting this meaning), is pretty easy to type and much easier to spot than a single underscore. > 2) _name is used inside class methods to indicate that the > programmer's intention is that this name should only be accessed > internally by that particular class. Not so much “inside class methods”; rather, the names are on attributes of a class (or module or, sometimes, function). This is the convention for “even if you can see this attribute, it is an implementation detail, not part of the public API for this class, anything might change about this in future revisions”. With no leading underscore, the implicit promise is that the name is a published API for the code, and can be relied on to keep the same name and behaviour in future revisions of the code. > 3) __name invokes Python's name mangling mechanism. The intent of this > usage is to not allow subclasses of the class containing __name to > access this name, and to add additional emphasis to future users of my > code that this name is meant to be strictly hands-off. > > […] it seems to me that one would normally be able to use the > simpler _name construction Right. I've felt any need to use this in my Python programming career; the distinction between “public API” (‘foo’) versus “implementation detail” (‘_foo’) is plenty. > 4) name_ is used when one is "forced" to use one of Python's reserved > words as a name. Yes. It's a last resort, IMO, but a valuable one; and the only damage is to readability (difficult to distinguish when reading quickly). > it seems that normally (4) should never be needed, though I have a > feeling that I have seen something in tkinter recently that suggests > some exceptions, but I cannot (yet) bring it to mind. The Python keywords and built-in object names include some obvious, common words. This is a clear benefit, but it can also cause a clash when choosing your own names: some of the best ones are already taken. I've seen this used to name ‘assert_’, ‘file_’, and the like. > 5) __name__ is meant to be used only by the creators of Python for > their special built-in methods, such as __init__, __new__, etc. > > […] surely I should never violate this one? It seems that in > some future edition of Python they might add any particular __name__ > that I might try to use presently in their future version of Python > (however miniscule that possibility might actually be). Yes. Never name anything with this ‘__foo__’ style unless Python already will treat it specially, and your intention is to invoke that special treatment by Python. This convention is violated too often in third-party code for names that don't have any special significance to Python, leading to needless confusion about how special a newly-encoutered name really is. All the ones I've seen in third-party code would always be improved for clarity by choosing a normal ‘foo’ or ‘_foo’ name. > Are my understandings above correct or flawed? I hope that helps. -- \ “It's dangerous to be right when the government is wrong.” | `\ —Francois Marie Arouet Voltaire | _o__) | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
