Re: [Tutor] ValueError: could not convert string to float: '13,2'
Pierre Dagenais wrote:
>
>
> On 13-12-31 04:09 PM, Keith Winston wrote:
>> Hi PierreD, I think if you iterate over your strings with something like
>> this, it will do what you want, if I understand correctly (snum is your
>> string number, like "123,321"):
>>
>> fnum = float(snum.replace(",", ".")
>>
>> keith: rank beginner, take everything with a grain of salt!
>>
>>
>>
>> ___
>> Tutor maillist - Tutor@python.org
>> To unsubscribe or change subscription options:
>> https://mail.python.org/mailman/listinfo/tutor
>>
> Thank you all who responded, for now I'll go with Keith's solution and
> keep the locale for next time.
> As all the data has one digit after the decimal I can get away with
> myInt = int(temp.replace(',',''))
> to convert a string representation of a float to an integer. I'll just
> need to remember to divide everything by ten once the calculations are
> done. Not very elegant, but it'll work. I don't suppose there is a
> function for determining the number of digits after the decimal, is it?
It looks like you are trying to avoid rounding errors in decimal arithmetic.
You might be interested in Python's decimal.Decimal type then.
> Also, anybody knows the maximum and/or minimum integer python will accept?
Integers in Python (*) are "unlimited"
>>> 10**1000 -1
99
99
In practice the amount of available memory will be the limit, but you are
unlikely to reach that.
(*) Python 2 had int and long where values that could not represented by
machine integers were automatically propagated to long. In Python 3 the int
and long have been united as int.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
Pierre Dagenais wrote:
> I wish to fill a list called years[] with a hundred lists called
> year1900[], year1901[], year1902[], ..., year1999[]. That is too much
> typing of course. Any way of doing this in a loop? I've tried stuff like
> ("year" + str(1900)) = [0,0] but nothing works.
> Any solution?
Use a dict:
years = {}
for year in range(1900, 2000):
years[year] = [0, 0]
Then instead of
print year1982
you have to type
print years[1982]
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
W dniu 2014-01-18 19:20, Pierre Dagenais pisze:
I wish to fill a list called years[] with a hundred lists called
year1900[], year1901[], year1902[], ..., year1999[]. That is too much
typing of course. Any way of doing this in a loop? I've tried stuff like
("year" + str(1900)) = [0,0] but nothing works.
Any solution?
Hi,
I don't know the solution, or if there is one.
And because of that, if I were you I would try to contain this data in
different way. Why not dictionary?
years = {1900: [0,0], 1901: [0,0], ..., 1999: [0,0]}
Initiating this dictionary with empty (or [0,0]) one hundred lists would
be easy with for loop. Accessing/changing list representing particular
year is much more easier: years[1980].
--
Best regards, Wiktor Matuszewski | Python
'py{}@wu{}em.pl'.format('wkm', 'ka') | newbie
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
W dniu 2014-01-18 19:20, Pierre Dagenais pisze:
I wish to fill a list called years[] with a hundred lists called
year1900[], year1901[], year1902[], ..., year1999[]. That is too much
typing of course. Any way of doing this in a loop? I've tried stuff like
("year" + str(1900)) = [0,0] but nothing works.
Any solution?
>>> y = 1900
>>> exec('year{} = [0, 0]'.format(y))
>>> year1900
[0, 0]
But I still think, that solution with dict with lists is better.
--
Best regards, Wiktor Matuszewski | Python
'py{}@wu{}em.pl'.format('wkm', 'ka') | newbie
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
On 01/19/2014 12:24 AM, Keith Winston wrote:
On Sat, Jan 18, 2014 at 2:19 PM, eryksun wrote:
`xrange` and 3.x `range` aren't iterators. They're sequences. A
sequence implements `__len__` and `__getitem__`, which can be used to
implement an iterator, reversed iterator, and the `in` operator (i.e.
`__contains__`).
I'm so glad you said this, I'm sorta burned out right now trying to
read all this, and I got sorta confused by that part. But what you're
saying is what I thought I understood.
Okay, now your example is pretty interesting. I guess it makes sense
that iter() returns a type iterator. Sure, of course.
Thanks as always to everyone, this is a trove. I'm a bit under the
weather so I'll have to come back and read it closer. I'm a little
clearer, though, and not just on iterators...
There is some inevitable confusion due to the exact usage or definition of given
terms in (the discourse) about given programming languages, as opposed to more
general meaings in programming in general (and to a certain point the meaning we
can infer from the ordinary sense of a term, when applied to programming).
Python for instance has a very precise usage and definition of "iterator" (as a
"protocal" for a kind of objects). This leads to some pythonists refusing or
correcting statements related to iterators which would otherwise be (mostly)
true in the more general context of programming (or which would be _differently_
wrong in the latter context ;-).
'range' ('xrange' in python2) is certainly (at least in my view) a kind of
iterator in the latter, more general sense used in programming (some thing
providing items one at a time); however, it does not implement python's iterator
protocal. Thus, it cannot be used directly in a 'for' traversal loop: if i'm
right, python builds a python iterator for ranges in the background. Like all
other kinds of 'sequences' (in the python sense, again) ranges are traversable
("iteratable") because they can in principle provide items one at a time, and
there exist builtin iterators for them.
For iterators, in python there is additional confusion with generators (at term
which AFAIK in programming means either about the same as iterator, or a
subclass of iterators implemented using poor man's coroutines), precisely
generator objects; and with generator expressions and other comprehensions.
A bit exaggerately complicated, in my view, esp when considering the narrowness
of the application field. Maybe a case of over-abstraction or over-engineering?
Denis
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
On 01/18/2014 07:20 PM, Pierre Dagenais wrote:
Hello,
I wish to fill a list called years[] with a hundred lists called
year1900[], year1901[], year1902[], ..., year1999[]. That is too much
typing of course. Any way of doing this in a loop? I've tried stuff like
("year" + str(1900)) = [0,0] but nothing works.
Any solution?
Thank you,
PierreD.
I think Danny & Wiktor's solutions are the right ones. Danny's is faster a
simpler (because of direct array indexing), but does not allow giving the true
year "names" (actually numbers). Wiktor more correctly matches you expectation
bt is a bit slower because we're searching individual years in a dict.
Here is an alternative, which should about as slow (since it is also searching
in a dict), and give true (string) names, at the cost of some complication in
code. The trick is to make a plain object (unfortunately we need a class in
python for that: it's a "fantom" class) and then directly set years on it as
plain attributes. Unfortunately, I don't remember of any nice way to traverse an
object's attributes: we have to traverse its __dict__ explicitely.
==
class Years: pass # fantom class
years = Years()
# set years as attributes:
start_year = 1900
n_years = 3 # 3 years only as example
for i in range (n_years):
# use setattr(obj, name, value) :
name = "year" + str(start_year + i)
value = [i] # give meaningful value maybe ;-)
setattr(years, name, value)
# access individual year:
print(years.year1901)
# traverse years:
for name in years.__dict__:
value = years.__dict__[name]
# unordered, unfortunately
print("%s : %s" % (name, value))
""" output (by me: order is undefined):
[1]
year1900 : [0]
year1901 : [1]
year1902 : [2]
"""
==
denis
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
On 19/01/2014 13:23, spir wrote:
On 01/18/2014 07:20 PM, Pierre Dagenais wrote:
Hello,
I wish to fill a list called years[] with a hundred lists called
year1900[], year1901[], year1902[], ..., year1999[]. That is too much
typing of course. Any way of doing this in a loop? I've tried stuff like
("year" + str(1900)) = [0,0] but nothing works.
Any solution?
Thank you,
PierreD.
I think Danny & Wiktor's solutions are the right ones. Danny's is faster
a simpler (because of direct array indexing), but does not allow giving
the true year "names" (actually numbers). Wiktor more correctly matches
you expectation bt is a bit slower because we're searching individual
years in a dict.
I suspect that the speed difference between accessing a list by direct
indexing and looking up something in a dict is negligible. I'll happily
leave Steven D'Aprano to supply us with the actual figures from the
timeit module :)
--
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] Naming variables
On 01/19/2014 02:59 PM, Mark Lawrence wrote:
On 19/01/2014 13:23, spir wrote:
On 01/18/2014 07:20 PM, Pierre Dagenais wrote:
Hello,
I wish to fill a list called years[] with a hundred lists called
year1900[], year1901[], year1902[], ..., year1999[]. That is too much
typing of course. Any way of doing this in a loop? I've tried stuff like
("year" + str(1900)) = [0,0] but nothing works.
Any solution?
Thank you,
PierreD.
I think Danny & Wiktor's solutions are the right ones. Danny's is faster
a simpler (because of direct array indexing), but does not allow giving
the true year "names" (actually numbers). Wiktor more correctly matches
you expectation bt is a bit slower because we're searching individual
years in a dict.
I suspect that the speed difference between accessing a list by direct indexing
and looking up something in a dict is negligible. I'll happily leave Steven
D'Aprano to supply us with the actual figures from the timeit module :)
It's 2-3 times slower, I guess (measures in other langs, including lua &
hand-implemented in C, but not in python). The task is accessing an entry which
key is a plain natural number, meaning a sparse array. It is typically
implemented as a "mod table" (my term), meaning a hash table without hashing
since keys already are natural numbers: only remains the modulo (actually just a
mask since the base is a power of 2). The overhead is consistently 2-3 times,
but as you say is often neglectable in practice since time remains small
compared to whatever one does with data, once accessed.
Lua for this reason nevertheless optimises function local scopes by getting rid
of names (unless one explicitely uses them, sort of metaprogramming) and
replacing them with indexes in a plain array (actually kind of custom call
stack). This is as said 2-3 times faster than access of globals (which names
remain, but *interned* thus we have a sparse array, and the scope is the Lua
version of a dict).
I guess (not sure) python optimises access of dicts used as scopes (also of
object attributes) by interning id-strings and thus beeing able to replace them
by hash values already computed once for interning, or other numeric codes, as
keys in dicts. Thus, we fall back to the case of a sparse array as above (but in
this case names are still there and accessible in the string pool).
[This is my preferred method, despite the additional complication of a string
pool, and additional weight of the numeric key in strings. And once we have the
machinary in place, it can be used for other purposes, like interning small user
strings or, as in python, object attr names.]
Denis
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] string indexing
hey guys, super noob here, i am trying to understand the following code
from google tutorial which i failed to comprehend
#code start
# E. not_bad
# Given a string, find the first appearance of the
# substring 'not' and 'bad'. If the 'bad' follows
# the 'not', replace the whole 'not'...'bad' substring
# with 'good'.
# Return the resulting string.
# So 'This dinner is not that bad!' yields:
# This dinner is good!
def not_bad(s):
# +++your code here+++
# LAB(begin solution)
n = s.find('not')
b = s.find('bad')
if n != -1 and b != -1 and b > n:
s = s[:n] + 'good' + s[b+3:]
return s
#code end
on the following lines, what is -1, is that index number? and i dont
understand the entire second line
if n != -1 and b != -1 and b > n:
s = s[:n] + 'good' + s[b+3:]
--
many thanks
mat
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
On 01/19/2014 02:59 PM, rahmad akbar wrote:> hey guys, super noob here, i am
trying to understand the following code
from google tutorial which i failed to comprehend
#code start
# E. not_bad
# Given a string, find the first appearance of the
# substring 'not' and 'bad'. If the 'bad' follows
# the 'not', replace the whole 'not'...'bad' substring
# with 'good'.
# Return the resulting string.
# So 'This dinner is not that bad!' yields:
# This dinner is good!
def not_bad(s):
# +++your code here+++
# LAB(begin solution)
n = s.find('not')
b = s.find('bad')
if n != -1 and b != -1 and b > n:
s = s[:n] + 'good' + s[b+3:]
return s
#code end
on the following lines, what is -1, is that index number? and i dont
understand the entire second line
-1 is what find returns if the searched substring is not at all present in the
bigger string: a trick meaning "could not find it". (-1 also means last index,
but is not necessary for find, it would return the positive last index)
if n != -1 and b != -1 and b > n:
a conditions for which 3 sub-conditions must be met at once
s = s[:n] + 'good' + s[b+3:]
Watch this:
string:This dinner is not that bad!
indexes: 0 nb -1
s[:n] = s[0:n]= "This dinner is "
s[b+3:] = s[b+3:-1] = "!"
+ concatenates (glues together) bits of strings
denis
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
rahmad akbar wrote:
> hey guys, super noob here, i am trying to understand the following code
> from google tutorial which i failed to comprehend
>
> #code start
> # E. not_bad
> # Given a string, find the first appearance of the
> # substring 'not' and 'bad'. If the 'bad' follows
> # the 'not', replace the whole 'not'...'bad' substring
> # with 'good'.
> # Return the resulting string.
> # So 'This dinner is not that bad!' yields:
> # This dinner is good!
> def not_bad(s):
> # +++your code here+++
> # LAB(begin solution)
> n = s.find('not')
> b = s.find('bad')
> if n != -1 and b != -1 and b > n:
> s = s[:n] + 'good' + s[b+3:]
> return s
> #code end
>
> on the following lines, what is -1, is that index number?
Python indices start at 0 and the s.find(t) method returns the starting
index of the first occurence of t in s. That's 0 when s starts with t:
>>> "badmington".find("bad")
0
When t does not occur in s at all the method returns -1, a value that cannot
be confused with any other possible starting pos.
> and i dont
> understand the entire second line
>
> if n != -1 and b != -1 and b > n:
The above line then means (partly in pseudocode):
if ("not" in s) and ("bad" in s) and ("bad" occurs after "not"):
> s = s[:n] + 'good' + s[b+3:]
s[:n] for a positive integer n means "take the first n characters of s", or
everything before the occurence of "not". It's basically a shortcut for
s[0:n]:
>>> s = "This dinner is not that bad!"
>>> s[:3]
'Thi'
>>> n = s.find("not")
>>> s[:n]
'This dinner is '
Likewise s[b:] for a positive integer b means "take all characters after the
first n of s, or everything including and after the occurence of "bad".
Again, you can think of it as a shortcut for s[b:len(s)]:
>>> s[3:]
's dinner is not that bad!'
>>> b = s.find("bad")
>>> s[b:]
'bad!'
But we don't want "bad" in the final string, so we have to ad len("bad") or
3 to b:
>>> s[b+3:]
'!'
So now we have
>>> s[:n]
'This dinner is '
and
>>> s[b+3:]
'!'
and can put whatever we like in between:
>>> s[:n] + "really delicious" + s[b+3:]
'This dinner is really delicious!'
PS: Note that Python's slicing notation allows steps and negative indices,
something you might read up on later.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
On 19 January 2014 12:55, spir wrote:
>
> 'range' ('xrange' in python2) is certainly (at least in my view) a kind of
> iterator in the latter, more general sense used in programming (some thing
> providing items one at a time); however, it does not implement python's
> iterator protocal. Thus, it cannot be used directly in a 'for' traversal
> loop: if i'm right, python builds a python iterator for ranges in the
> background. Like all other kinds of 'sequences' (in the python sense, again)
> ranges are traversable ("iteratable") because they can in principle provide
> items one at a time, and there exist builtin iterators for them.
It's not really that complicated. Basically range on 3.x (or xrange on
2.x) returns a range object:
$ python3
Python 3.3.2+ (default, Oct 9 2013, 14:56:03)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = range(2, 4)
>>> a
range(2, 4)
A range object is not an "iterator":
>>> next(a)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'range' object is not an iterator
However it is an "iterable" which means that I can call iter on it to
get an "iterator":
>>> b = iter(a)
>>> b
Once we have the iterator object we can call next() on it:
>>> next(b)
2
>>> next(b)
3
The distinction between the iterator and the iterable is important
since it affects what happens if we call iter() multiple times:
>>> c = iter(a)
>>> next(c)
2
>>> next(b)
Traceback (most recent call last):
File "", line 1, in
StopIteration
>>> next(c)
3
>>> next(c)
Traceback (most recent call last):
File "", line 1, in
StopIteration
Iterators (as opposed to iterables) must be their own iterator. So
when you call iter you get back the same object:
>>> iter(c) is c
True
>>> iter(c) is b
False
>>> iter(c) is a
False
This means that if we call iter several times we don't start from the
beginning of the sequence of values that come from the iterator.
>>> a = range(9)
>>> a
range(0, 9)
When we iterate over the range object we always get the same values:
>>> for x in a:
... if x > 3:
... break
... print(x)
...
0
1
2
3
>>> for x in a:
... if x > 5:
... break
... print(x)
...
0
1
2
3
4
5
When we iterate over the range_iterator it remembers where it left off:
>>> b = iter(a)
>>> for x in b:
... if x > 3:
... break
... print(x)
...
0
1
2
3
>>> for x in b:
... if x > 5:
... break
... print(x)
...
5
It's important to know whether you have an iterable or an iterator. If
you write a function that should work with either then it's sometimes
necessary to explicitly call iter at the start:
def myfunc(iterable):
iterator = iter(iterable)
# Do stuff with iterator
If you just loop over all the values in the iterable once then this is
unneeded. If your iteration pattern is more complicated then you may
need this. This is important if e.g. you have a function that should
work equally well with a file object or with a list of strings or a
generator that yields strings etc. The list object is an iterable but
not an iterator. File objects and generators are iterators.
> For iterators, in python there is additional confusion with generators (at
> term which AFAIK in programming means either about the same as iterator, or
> a subclass of iterators implemented using poor man's coroutines), precisely
> generator objects; and with generator expressions and other comprehensions.
>
> A bit exaggerately complicated, in my view, esp when considering the
> narrowness of the application field. Maybe a case of over-abstraction or
> over-engineering?
What's the narrowness of the application field? Iteration is
fundamental in pretty much every program I write. Iterators and
generators are great at writing scalable programs without needing to
complicate your code. Try doing a similar thing in C where you have to
write call-back functions or functions to allocate and hold on to
iteration state and so on.
Oscar
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
On 19/01/14 13:59, rahmad akbar wrote:
hey guys, super noob here, i am trying to understand the following code
from google tutorial which i failed to comprehend
Others have answered the specifics but some general advice here:
1) never forget the Python >>> prompt.
Try things out if you don't understand them.
Look at the results. Its a great learning tool.
2) use the built in help() function at the >>> prompt
Those two aids will answer about 80% of your questions.
And for the rest there is the tutor list! :-)
def not_bad(s):
n = s.find('not')
b = s.find('bad')
if n != -1 and b != -1 and b > n:
s = s[:n] + 'good' + s[b+3:]
return s
on the following lines, what is -1, is that index number?
>>> help(''.find)
Help on built-in function find:
find(...)
S.find(sub[, start[, end]]) -> int
Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end]. Optional
arguments start and end are interpreted as in slice notation.
Return -1 on failure.
(END)
>>> s = "Test string thats not interesting but not bad either"
>>> s.find('not')
18
>>> s.find('bad')
42
>>> s.find('gobbledegook')
-1
understand the entire second line
if n != -1 and b != -1 and b > n:
s = s[:n] + 'good' + s[b+3:]
Again try this in bits at the >>> prompt:
>>> s[:18]# using the value found above
'Test string thats '
>>> s[42+3:] # again using value above
' either'
>>> s[:18] + 'good' + s[45:]
'Test string thats good either'
Hopefully that gives you some ideas on how
to use the >>> prompt to answer questions
as they arise.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
On 19/01/14 16:18, Oscar Benjamin wrote: It's not really that complicated. Basically range on 3.x (or xrange on 2.x) returns a range object: Sadly though it is complicated, at least for newbies :-( Python 3 has cleaned up much of the language from a Comp Sci point of view but from the point of view of a lay newbie it has exposed lots of complicated detritus that means absolutely nothing to them. What is an iterator? a range object? generators? slots? Lists and sequences are fairly standard language concepts but these new terms are terrifyingly obscure for newbies, especially when they appear in error messages. It has reached the point that I'm back to looking for a new teaching language. In Python 3 the decision has clearly been made to focus on supporting Python's role as a professional software engineering language at the expense of being a successor to ABC or for use in CP4E etc. That's a fair enough decision but it does mean Python is no longer the easiest option for non Comp Sci beginners. It's not worse than the others but it's no longer clearly superior. (IMHO at least! ) But what else is there? that's the problem :-( -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
Well, as usual thanks for all this, it's really great. I'd worked out that it was a distinction between iterators and iterables, though I'm going to Oscar's description a few more times: most of it made sense, but there are subtleties. For example, this from the Python 3.3 tutorial: We say such an object is iterable [referring to "range"], that is, suitable as a target for functions and constructs that expect something from which they can obtain successive items until the supply is exhausted. We have seen that the for statement is such an iterator. The function list() is another; it creates lists from iterables: Now, everything we've said thus far would not have led me to believe that one would call the for statement an iterator... is this just very, very loose use of the term (in the Python documentation!), or am I still missing something biggish? K ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
On Jan 19, 2014 6:49 PM, "Keith Winston" wrote: > > Well, as usual thanks for all this, it's really great. I'd worked out > that it was a distinction between iterators and iterables, though I'm > going to Oscar's description a few more times: most of it made sense, > but there are subtleties. > > For example, this from the Python 3.3 tutorial: > > We say such an object is iterable [referring to "range"], that is, > suitable as a target for functions and constructs that expect > something from which they can obtain successive items until the supply > is exhausted. We have seen that the for statement is such an iterator. > The function list() is another; it creates lists from iterables: > > Now, everything we've said thus far would not have led me to believe > that one would call the for statement an iterator... is this just > very, very loose use of the term (in the Python documentation!), or am > I still missing something biggish? I think that's just an editing mistake. If you replace the word "iterator" with "construct" then it makes sense: We have seen that the for statement is such a construct. Oscar ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iterators
On Sun, Jan 19, 2014 at 2:02 PM, Oscar Benjamin wrote: > I think that's just an editing mistake. If you replace the word "iterator" > with "construct" then it makes sense: We have seen that the for statement is > such a construct. Fair enough. Thanks. But I think that it underlines the ease with which the language is used loosely, which does get confusing quickly when one is still putting together the concepts. I really appreciated your lengthy post distinguishing iterators from iterables, and I'm going to go back over it someday that I'm not sick and I have a spare neuron or two. -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Python as Teaching Language
On Sun, Jan 19, 2014 at 11:55 AM, Alan Gauld wrote: > It has reached the point that I'm back to looking for a new teaching > language. In Python 3 the decision has clearly been made to focus on > supporting Python's role as a professional software engineering language > at the expense of being a successor to ABC or for use in CP4E etc. > That's a fair enough decision but it does mean Python is no longer the > easiest option for non Comp Sci beginners. It's not worse than the others > but it's no longer clearly superior. (IMHO at least! ) > > But what else is there? that's the problem :-( Hi Alan, since this is off-topic from it's original thread, but I wanted to respond to it, I popped it into a new thread, I hope you don't mind (original was subject "iterators"). I can imagine what you mean about a teaching language, and while I don't 1) teach CS or 2) know Python like you do... AND I don't know the alternatives... it still feels like the cleanest, most user-friendly language I've ever worked with. Anyway, there's something to be said for letting novices play with real tools: instead of coming to the end of their one-semester computer class feeling like they just played with legos, they can feel like they got some (minor) feel for building a house. An interesting question is, what's the goal (for those students, probably the majority in a required comp sci course) who aren't going to do a lot of programming in the future ? I can think of a few: help people expand/develop/reflect on their ability to think in various ways; depressurize fear around programming/computers; give them a leg up in approaching the vast range of computer-supported tools in many fields... Anyway, I'm sorta loving this language, and it feels like a decent way "in" to all of those goals. There are two caveats: one is, without this tutor list (and to a lesser extent, perhaps because I've relied on this so much), other online resources (stack overflow, the Python IRC channels, etc), it would be much harder to make sense of. But those are there, and don't seem in immediate danger of disappearing. And the second... the documentation. I really want to love the documentation, but I can't. I can't maneuver through it hardly at all (if I'm trying to find something in the documentation, I almost always search it from Google), it often doesn't give any examples in the places I want them, and assumes an understanding I don't have at a given moment. I'm SO GRATEFUL to all the people who have contributed to the language, including the documentation, and don't imagine I could do better, I just notice that I haven't figured out how to make it work for me. Now, to a large degree this is not the documentations' fault: I forget things I just read 10s ago, and then I'll charge off to learn a topic far more advanced than I'm reasonably ready for. I have an iterative learning process which involves not understanding a disconcerting amount of what's in front of me. I don't actually think it's optimal, but I literally can't stand (what feels like) the slow, plodding forward approach that is the alternative generally offered. I think there is often a mismatch between teaching structures/approaches, and peoples (very personal, often ill-understood and ill-developed) learning styles. The other thing I wonder about is how to make the learning process more interactive/social: that is, so many of the questions that (even more novice than me) people bring here are things like error statement meanings, etc. In many cases IMO, the first 10 minutes of frustration around something like that can be enough to leave a lasting bad taste. I've gotten some very fast responses around here, and immediate ones on the IRC (which I've only used a little): I believe quick feedback to be crucial to the learning process, and yet we are often trained, in school and elsewhere, to smoulder in frustration around things we don't know yet, I believe (or to just give up and feel stupid)... I don't know whether social platforms will translate to a greater readiness to seek help in order to really learn, or just to learn to fill in the blanks faster/"cheat" better. Teaching is hard. And a last note on feedback: having the interpreter available is a definite plus for Python, though learning to disassemble one's confusion into little pieces that you can test methodically is hard. But another good skill... Sorry for the length. Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
On Sun, Jan 19, 2014 at 11:33 AM, Alan Gauld wrote:
help(''.find)
> Help on built-in function find:
Erm, getting what you want from help can be work.
Help(find) # doesn't work at all.
What Alan did above was create an empty string, by using two single
quotes next to each other ('', not to be confused with a single double
quote, "), and then seek Help on it's method "find" (methods are
accessed by following an object, in this case the empty string, with a
period, and the method name... in actual use there would be further
parenthesis, but for Help you don't use them)... hence
Help(''.find)
Also, Alan's really right on getting used to playing with bits and
pieces at the >>> prompt, you'll be amazed at how much you can do
there. Just don't try to write lengthy programs there, save those as
files and edit them separately.
--
Keith
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
On 19/01/2014 19:34, Keith Winston wrote:
On Sun, Jan 19, 2014 at 11:33 AM, Alan Gauld wrote:
help(''.find)
Help on built-in function find:
Erm, getting what you want from help can be work.
Help(find) # doesn't work at all.
How would Python know whether you want find for gettext, mmap, str,
xml.etree.ElementTree.Element or xml.etree.ElementTree.ElementTree?
Those are the ones listed in the Windows compiled help file for Python
3.3. You could of course have your own find methods or functions, and
have yet more from third party libraries.
--
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] Python as Teaching Language
On 19/01/14 19:18, Keith Winston wrote: On Sun, Jan 19, 2014 at 11:55 AM, Alan Gauld wrote: It has reached the point that I'm back to looking for a new teaching language. ... But what else is there? that's the problem :-( Hi Alan, since this is off-topic from it's original thread, but I wanted to respond to it, I popped it into a new thread, I hope you don't mind (original was subject "iterators"). Not at all, I probably should have done that myself. I can imagine what you mean about a teaching language, and while I don't 1) teach CS or 2) know Python like you do... AND I don't know the alternatives... it still feels like the cleanest, most user-friendly language I've ever worked with. I agree although I don't teach CS and don't consider myself a Python guru by any means, but I have been programming for 40 years in over 20 languages so I do know a bit about the alternatives! :-) something to be said for letting novices play with real tools: instead of coming to the end of their one-semester computer class feeling like they just played with legos, they can feel like they got some (minor) feel for building a house. Absolutely, and that's why I first chose Python for my tutor. I needed a language that students could go away and actually use for real work - unlike Logo, or even Lisp and Smalltalk. (I know you can do real work in all of those but they are hardly mainstream, and the leap from learning to practicality is quite big IMHO) An interesting question is, what's the goal (for those students, probably the majority in a required comp sci course) who aren't going to do a lot of programming in the future? I hope CS students will be doing a lot of programming! :-) But the target for my tutor was that group who had no formal CS training, and indeed no math training beyond high school, but needed to program to achieve their objectives. Think IT operations staff or sys admins or even non CS academics doing stats etc (This was pre R of course...) So I needed to be able to avoid technical concepts and yet be able to back-fill those concepts when needed. Python did that in v1 and to a lesser degree in v2. But in V3 too many of the academic features seem to escape from the shadows and hit the newbie in the face. fields... Anyway, I'm sorta loving this language, and it feels like a decent way "in" to all of those goals. I still love Python as a language for my own use. In fact I'm currently working on another book just now that's focused on using Python in practical contexts, but it's not a pure beginners book. And it would be much harder to write a pure beginners book now than it was 15 years ago when I did my first. There is so much more to explain to get quite basic things done. There are two caveats: one is, without this tutor list (and to a lesser extent, perhaps because I've relied on this so much), other online resources (stack overflow, the Python IRC channels, etc), it would be much harder to make sense of. But those are there, and don't seem in immediate danger of disappearing. The internet has changed how people learn. Wikipedia is a fantastic resource for the pure theory type stuff and user fora are great for practical help - although often with as much bad advice as good! Just because something works doesn't make it right! But the days of hunkering down with a single text book and bulldozing your way through are, thankfully, long gone. And the second... the documentation. I really want to love the documentation, but I can't. You should try learning C or Fortran from the DEC VAX manuals! :-) The Python docs are a model of clarity. But you do know how to read them. They are written for professionals. One of the primary targets of my tutor was to explain all of those concepts needed to read the docs and understand them. In that I was only partially successful. (if I'm trying to find something in the documentation, I almost always search it from Google), So does everyone else. Python was created in the internet age. Search engines were assumed to exist and users were expected to use them. it often doesn't give any examples Yes thats one area that could be im[proved. The subprocess model is one exception. I think it would be great if every module page had an accompanying examples page. But no, I'm not volunteering to write them! :-) And there's the rub, everything in Python is done by volunteers. Who wants to spend there day writing examples for a manual page when they could be writing real code? Getting volunteers to document Open Source projects is always a challenge. Python is better served than many. Commercial projects hire professional Technical Authors to wrie the docs and thus tend to be of much higher quality. But you often pay as much for the docs as for the software! learning process which involves not understanding a disconcerting amount of what's in front of me the slow, plodding forward approach that is the alternative generally of
Re: [Tutor] string indexing
On 19/01/14 19:53, Mark Lawrence wrote: On 19/01/2014 19:34, Keith Winston wrote: Erm, getting what you want from help can be work. Help(find) # doesn't work at all. How would Python know whether you want find for gettext, mmap, str, xml.etree.ElementTree.Element or xml.etree.ElementTree.ElementTree? Absolutely, but a newbie doesn't even guess that more than one find would exist. Or even that there would need to be more than one. It's the same word so why doesn't it just work for everything?! After all len() seems to do it that way... That's why help() can be hard work, as Keith says, it's not always obvious to beginners what to ask for help with. My bad for not making that clear in my original post... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Naming variables
On Sun, Jan 19, 2014 at 9:21 AM, spir wrote:
> I guess (not sure) python optimises access of dicts used as scopes (also of
> object attributes) by interning id-strings and thus beeing able to replace
> them by hash values already computed once for interning, or other numeric
A string object caches its hash, but initially it isn't computed (-1).
On the `dict` lookup fast path, you have a cached hash, where the
string wasn't probed to a different table index by a hash collision,
and the string is interned with the same address (CPython ID) as the
key in the table.
CPython setattr is implemented by calling PyObject_SetAttr, which
interns the name. The string will be used by subsequently interned
strings. Code objects intern strings, but those will already have been
instantiated for the module, and we're dealing with dynamic strings
here like `"year" + str(1900)`. That leaves dynamic code that you
compile/exec.
years = type('Years', (), {})
setattr(years, 'year' + str(1900), [])
s1 = next(s for s in vars(years) if s == 'year1900')
Compile a code object containing the string 'year1900' as a constant:
code = compile('"year1900"', '', 'exec')
s2 = next(s for s in code.co_consts if s == 'year1900')
The code object interned the string constant because it's all name
characters (ASCII letters, numbers, and underscore):
>>> s2 is s1
True
You could also call sys.intern to get the interned string, but it
isn't worth the cost of the call each time:
>>> s3 = 'year' + str(1900)
>>> s3 is s1
False
>>> s4 = sys.intern(s3)
>>> s4 is s1
True
Thankfully a dict with only string keys uses an efficient equality
comparison, so all of this is really a moot point:
http://hg.python.org/cpython/file/3.3/Objects/stringlib/eq.h
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] Understanding Classes
Hello Tutorians, Looked all over the net for class tutorials Unable to understand the "self" argument Attempting to visual classes I have searched high and low, for easy to follow tutorials regarding classes. Although I grok the general concept of classes, I am unable to visually understand what exactly "self" does, or why it is even necessary. It seems very "magic" to me. Also I am having the most difficult with the "__init__()" method in classes, and why that is also required. Keep in mind that I am a visual person (maybe I should have been a graphic designer), therefore most programming concepts flow irritatingly slow for me. -- Regards, Christian Alexander ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Question on os.popen
Hello,
I am using os.popen repeatedly to run Unix shell commands within my Python
program. To be more specific, I am running in a loop which could iterate as
many times as there are lines in an input file - in this example, close to
150 iterations. Each loop has two calls to os.popen.
It works fine for the first few loops and it stops with the following error
message:
IOError: [Errno 4] Interrupted system call
I read about os.popen in
http://docs.python.org/2/library/subprocess.html#subprocess.Popen and used
the "buffer" argument to specify 4096 as the buffer size: os.popen(command,
"r", 4096)
This time it probably ran for a few more iterations than before and stopped
with the same error message. This time it also output the following
messages:
IOError: [Errno 4] Interrupted system call
Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found)
Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found)
Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found)
It always seems to error at the following line:
"part2 = f.read()" in the code-snippet below, after a few iterations. Does
popen use any system resources that need to be closed/released after each
execution? I didn't find any such information in the document though.
for i in range(0, length):
if (self.fiDictList[i]['filename'] == filename):
mmls_cmd = "mmls -i " + imgtype +" "+image +" | grep
\"02:\""
# f = os.popen(mmls_cmd) <<< Original line
f = os.popen(mmls_cmd, 'r', 4096)
part2 = f.read() # << This is where it shows error
after getting here 4 times.
part2_list = part2.split()
part2_start = part2_list[2]
if (redirect_file == True):
icat_cmd = "icat -o "+part2_start+ " "+ image + " " +
self.fiDictList[i]['inode'] + ' > ' + outfile
print(">> D: Executing iCAT command: ", icat_cmd)
f2 = os.popen(icat_cmd)
else:
return
I am not sure where I am going wrong. Isn't the way I am reading the
popen's output correct? But if so, why does it work for the first few
iterations? Any tips appreciated.
Thanks, in advance.
-SM
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Understanding Classes
On 19/01/14 21:59, Christian Alexander wrote: Looked all over the net for class tutorials Unable to understand the "self" argument Attempting to visual classes If you read my OOP tutorial there is a section there specifically about self. And the v3 tutor includes an introduction to the formal visualisation technique for OOP called UML. The diagrams illustrating the designs may help. http://www.alan-g.me.uk/l2p/tutclass.htm I have searched high and low, for easy to follow tutorials regarding classes. Although I grok the general concept of classes, Do you also grok the concept of objects? Classes on their own are fairly useless (unless you are using Java) it is only when you create a universe of objects from those classes that they become useful. If you can repeat to us your understanding of classes and their relationship with objects that will help us understand your level and shape our responses accordingly. to visually understand what exactly "self" does, or why it is even necessary. It seems very "magic" to me. When you define a class you define the data (attributes) that the class instances will have. Each instance will have a copy of the data defined in the __init__() method. You also define a set of operations or methods that are associated with the class. Those methods are shared by the instances. Note the difference. Instances get a copy of the attributes but they all share the methods. Thus when you invoke a method on an instance the instance relays that call to the class. For the class to know which instance is being operated on, and for the method to be able to access the correct instance's data it needs a reference to the instance. That reference is typically called 'self' or 'this'. (In some languages it's fixed but in Python self is only a convention, you can use any name you like). You can make the call to the class explicit and it will still work. See below: # define a class class MyClass: def __init__(self,x): self.x = x def myMethod(self): print(self.x) # create some instances ObjA = MyClass(2) ObjB = MyClass(4) ObjC = MyClass(6) # send some messages/call methods objA.myMethod() # call from the instance MyClass.myMethod(ObjB) # call explicitly to the class objC.myMethod() # direct again All 3 calls do the same thing except the middle one passes the object identifier directly to the class whereas the first and last both do that internally within the object structure. difficult with the "__init__()" method in classes, > and why that is also required. It is not *required* as such. You can create a class without an init but it's unusual. When you create an instance of a class it creates a data structure in memory referenced by the name of the instance. But that structure is empty, it has no data. So to populate the data for the instances you must initialize it. That's what __init__() does. It takes the arguments you provide and applies them to the instance along with any static data definitions you may define. In the example we create an instance variable, x, within the instances and assign the value of the argument passed to init. Like any other method the actual code lives in the class so we could initialize it by calling init like so: MyClass.__init__(objC, 66) which is almost the same as doing: objC = MyClass(66) The difference is that the first case requires the object ObjC to already exist, the second example creates a new instance and then calls init on that instance. Keep in mind that I am a visual person (maybe I should have been a graphic designer), therefore most programming concepts flow irritatingly slow for me. Most programming concepts have visual representations, its just that program code being text tends to lead programmers to be verbally based. But algorithms, state machines, logic, data structures, GUIs, formal requirements and OOP all have well established visual representations, and in many cases they are formalized so that, with the right tools, you can create code purely visually. If the above doesn't clarify things, and I suspect it won't entirely, then please do express your understanding so far in your own words and we'll try to clarify things from there. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] string indexing
On Sun, Jan 19, 2014 at 3:50 PM, Alan Gauld wrote: >> How would Python know whether you want find for gettext, mmap, str, >> xml.etree.ElementTree.Element or xml.etree.ElementTree.ElementTree? > > > Absolutely, but a newbie doesn't even guess that more than one find would > exist. Or even that there would need to be more than one. That's exactly it. I'm just getting to the point of being able to understand how much I don't know, and (I'm only a little embarrassed to admit) Alan's empty-string example was an "ah-ha" moment for me. I expect Help will be a great deal more useful now (of course, as I type that I realize I could have used the class name, help(str.find), instead of an impromptu instance. Another little ah-ha). And of course, the instant I understood all that, the point that Mark made became obvious. But I didn't see it before. -- Keith ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question on os.popen
On 19/01/14 23:36, SM wrote: I read about os.popen in http://docs.python.org/2/library/subprocess.html#subprocess.Popen This doesn't answer the question but I'm curious. If you read about os.popen in the subprocess module docs why did you use it? The subprocess module replaces all the os.popen calls with the generally superior subprocess.Popen class. Now, I don't know if using subprocess instead of os would fix things in this case but it seems an odd choice? I'm curious why you chose to go with os.popen? BTW you don't tell us which OS you are using (or which Python version), that may be pertinent to the answer. I'm assuming it's some variant of *nix but which one? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question on os.popen
Hi Alan, Thanks for your reply. My answer to why I am using os.popen could be a lame one - I have used it extensively in various places before and it has been working well and so was hung up on using it. Now I replaced it by subprocess.check_output with appropriate parameters and it seems to be working. Does that mean this is one of the limitations of os.popen? I am not sure. Sorry for not giving details on the OS and python version I am using: Ubuntu and Python3. Thanks, SM On Sun, Jan 19, 2014 at 8:20 PM, Alan Gauld wrote: > On 19/01/14 23:36, SM wrote: > > I read about os.popen in >> http://docs.python.org/2/library/subprocess.html#subprocess.Popen >> > > This doesn't answer the question but I'm curious. > If you read about os.popen in the subprocess module docs why did > you use it? The subprocess module replaces all the os.popen calls > with the generally superior subprocess.Popen class. > > Now, I don't know if using subprocess instead of os would fix > things in this case but it seems an odd choice? I'm curious why > you chose to go with os.popen? > > BTW you don't tell us which OS you are using (or which Python > version), that may be pertinent to the answer. I'm assuming > it's some variant of *nix but which one? > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > 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] Question on os.popen
On Sun, Jan 19, 2014 at 6:36 PM, SM wrote: > > This time it probably ran for a few more iterations than before and stopped > with the same error message. This time it also output the following > messages: > > IOError: [Errno 4] Interrupted system call > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found) > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found) > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not found) I can't help with these (NTFS?) Attribute errors from "The Sleuth Kit" digital forensics tools. In Python 3.3, `IOError` is an alias for `OSError`, and EINTR (i.e. errno.errorcode[4]) is exposed directly as `InterruptedError`. So you must be running a previous version. I see you're using `print` as a function, so I'll guess you're using 3.2. In 3.2, `os.popen` is implemented via `subprocess.Popen`: http://hg.python.org/cpython/file/cef745775b65/Lib/os.py#l776 For example, it uses the following for 'r' mode: proc = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, bufsize=buffering) return _wrap_close(io.TextIOWrapper(proc.stdout), proc) If you're sticking to `os.popen`, you'll need to retry the read in case of an interrupted system call. I recommend you switch to `Popen` directly and call `communicate`. This retries reading `stdout` using the helper function `_eintr_retry_call`: http://hg.python.org/cpython/file/cef745775b65/Lib/subprocess.py#l452 def _eintr_retry_call(func, *args): while True: try: return func(*args) except (OSError, IOError) as e: if e.errno == errno.EINTR: continue raise More simply, use `subprocess.check_output`, which calls `communicate` for you. You can pass `shell=True` if you really need it. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question on os.popen
SM Wrote in message: > Sorry for not giving details on the OS and python version I am using: Ubuntu > and Python3 On Sun, Jan 19, 2014 at 8:20 PM, Alan Gauld wrote: On 19/01/14 23:36, SM wrote: >> I read about os.popen in >> http://docs.python.org/2/library/subprocess.html#subprocess.Popen > Please don't top-post. If you're using Python 3.x, why aren't you using the corresponding docs page? In the upper left corner of that page is a dropdown you can use to get to 3.3 for example. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question on os.popen
Eryksun: Thanks for your reply. Yes, as I mentioned in my reply to Allen, I used subprocess.check_output and it worked for me. -SM On Sun, Jan 19, 2014 at 11:33 PM, eryksun wrote: > On Sun, Jan 19, 2014 at 6:36 PM, SM wrote: > > > > This time it probably ran for a few more iterations than before and > stopped > > with the same error message. This time it also output the following > > messages: > > > > IOError: [Errno 4] Interrupted system call > > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not > found) > > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not > found) > > Attribute not found in file (tsk_fs_attrlist_get: Attribute 128 not > found) > > I can't help with these (NTFS?) Attribute errors from "The Sleuth Kit" > digital forensics tools. > > In Python 3.3, `IOError` is an alias for `OSError`, and EINTR (i.e. > errno.errorcode[4]) is exposed directly as `InterruptedError`. So you > must be running a previous version. I see you're using `print` as a > function, so I'll guess you're using 3.2. > > In 3.2, `os.popen` is implemented via `subprocess.Popen`: > > http://hg.python.org/cpython/file/cef745775b65/Lib/os.py#l776 > > For example, it uses the following for 'r' mode: > > proc = subprocess.Popen(cmd, > shell=True, > stdout=subprocess.PIPE, > bufsize=buffering) >return _wrap_close(io.TextIOWrapper(proc.stdout), proc) > > If you're sticking to `os.popen`, you'll need to retry the read in > case of an interrupted system call. > > I recommend you switch to `Popen` directly and call `communicate`. > This retries reading `stdout` using the helper function > `_eintr_retry_call`: > > http://hg.python.org/cpython/file/cef745775b65/Lib/subprocess.py#l452 > > def _eintr_retry_call(func, *args): > while True: > try: > return func(*args) > except (OSError, IOError) as e: > if e.errno == errno.EINTR: > continue > raise > > More simply, use `subprocess.check_output`, which calls `communicate` > for you. You can pass `shell=True` if you really need it. > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question on os.popen
> In the upper left corner of that page is a dropdown you can use to get to 3.3 for example. Thanks for that info. On Sun, Jan 19, 2014 at 11:42 PM, Dave Angel wrote: > SM Wrote in message: > > Sorry for not giving details on the OS and python version I am using: > Ubuntu and Python3 > > > On Sun, Jan 19, 2014 at 8:20 PM, Alan Gauld n.ga...@btinternet.com> wrote: > On 19/01/14 23:36, SM wrote: > > >> I read about os.popen in > >> http://docs.python.org/2/library/subprocess.html#subprocess.Popen > > > > Please don't top-post. > > If you're using Python 3.x, why aren't you using the corresponding > docs page? In the upper left corner of that page is a dropdown > you can use to get to 3.3 for example. > > -- > DaveA > > ___ > 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
