Re: can some one help me with my code. thanks
Le 20/01/12 20:30, Vincent Vande Vyvre a écrit :
Le 20/01/12 19:49, Tamanna Sultana a écrit :
can some one help me??
I would like to create a function that, given a bin, which is a list
(example below), generates averages for the numbers separated by a
string 'end'. I am expecting to have 4 averages from the above bin,
since there are 4 sets of numbers separated by 4 'end' strings
['2598.95165', '2541.220308', '221068.0401', 'end', '4834.581952',
'1056.394859', '3010.609563', '2421.437603', '4619.861889',
'746.040504', '268.3881793', '379.3934898', '1252.527752',
'11459.88522', '4862.167506', '506.924289', '634.6737389',
'496.4679199', '17941.59143', '919.4998935', '7247.610974',
'1166.053214', '47360.91508', '855.2426137', '4020.444585',
'4469.896904', '2615.874982', '19862.92009', '2379.619573',
'1203.268956', '4399.589212', '6838.825864', '1848.407564',
'3527.198403', '33976.85042', '818.8722263', '634.6652078',
'469.2685928', '4864.830004', '5103.222941', '1011.239929',
'829.9915382', '8571.237936', '3301.953656', '14594.47385',
'25688.83822', '4024.393045', '4163.775185', '1775.894366',
'3682.012227', '3371.092883', '6651.509488', '7906.092773',
'7297.133447', 'end', '4566.874299', 'end', '4255.700077',
'1857.648393', '11289.48095', '2070.981805', '1817.505094',
'1892.256615', '1757.0048', '59458.46328', '778.5755201', '54987.32423',
'2245.172711', '722.2619663', '5116.616632', '3427.865861',
'17973.07118', '14398.74281', '66313.92115', '11585.24151',
'45294.03043', '6524.744077', '25958.80015', '593.3786209',
'2899.040703', '85577.21342', '153576.2633', '5852.008444',
'563.0265409', '70796.45356', '565.2123689', '6560.030116',
'2668.934414', '418.666014', '5216.392132', '760.894589', '8072.957639',
'346.5905371', 'end']
If you can give me some lead to fix the code I wrote below that will be great:
def average(bin):
num=[]
total = 0.0
count=0
for number in bin:
while True:
if number!='end':
number=float(number)
total += float(number)
count+=1
avg = total/count
if number=='end':
break
num.append(avg)
return num
Thnx
That's works:
bin =['2598.95165', '2541.220308', '221068.0401', 'end',
'4834.581952',
'1056.394859', '3010.609563', '2421.437603', '4619.861889',
'2668.934414', '418.666014', '5216.392132', '760.894589',
'8072.957639',
'346.5905371', 'end']
avg = []
sp = ",".join(bin).split(',end')
for part in sp:
vals = part.split(',')
sum_ = 0
for v in vals:
if v:
sum_ += float(v)
else:
continue
avg.append(sum_ / len(vals))
print avg
OOps, that's works but the result is false.
There is a final comma in "part" which causes a supernumerary
element (empty) in vals.
Correction:
averages = []
items = []
for item in bin:
def get_average(vals):
return sum(vals) / len(vals)
try:
items.append(float(item))
except ValueError:
averages.append(get_average(items))
items = []
print averages
This assume the last element of bin is always "end".
--
Vincent V.V.
Oqapy . Qarte+7 . PaQager
--
http://mail.python.org/mailman/listinfo/python-list
Re: Please don't use "setuptools", the "rotten .egg" install system.
John Nagle writes: > On 1/19/2012 12:56 AM, Lele Gaifax wrote: >> John Nagle writes: >> >>> "egg" files are usually more trouble than they're worth. >> >> I find it really funny you say so, just after another thread where you >> proved yourself unable to come up with a working Python environment >> lacking an already packaged RPM of version 2.7... > > I can do it, I just have better things to do than system > administration. The fact that Python doesn't "just work" is > part of why it's losing market share. Hopefully whining and asserting doubtful things here are not "the [only] better things" you have to do :-) >> I know "egg" are not standard, but these days are still the only way to >> install Python-related stuff that includes precompiled stuff > > If it can be built with "python setup.py build", go that way. I wasn't able to make the point clear: imagine you wrote one beatiful web widget built in Flash, what would you prefer, distribute just that widget with your Python module that uses it, or forcing the recipient to have a Flash compiler on its own and compile it every time you install the package? If the latter, why are you running on RH instead of (say) Gentoo?? > A "setup.py" script, invoked with the correct Python, reliably > knows which Python it is supposed to update. "egg" files > usually have trouble with that. Never had that problem, but please, define "usually" and "trouble". > Prebuilt systems should use the installer for the distro, and work > with yum, apt-get, or the Windows installer as appropriate. Why should I, when one format fits 'em all? I'm not against "proprietary" mechanism, but I surely see the benefit of an easier way of deploying my custom packages. > It does seem to be necessary to install the development tools > on a Linux system just to get various Python packages to install. > Major packages are still all over the place. > PyPy is just a directory of links, not a repository like CPAN. You surely meant PyPI there... but even then, I cannot see the point. It's evidently easy enough pushing there yet-another-link pointing to a prebuilt egg... > Python sort of slips through the cracks. Nobody is doing > the work to make PyPy handle these problems, and Python isn't > important enough for MySQL, etc. to support the connector for > the language. (They support Perl, C, Java, etc., but not > Python.) Yet another OT argument but... hopefully nobody is forcing you to stay on the losing side of the market :-) Anyway, to me MySQL isn't important enough for Python, there are way better DB engines out there to invest my time with. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the very simplest way to run some Python from a button on a web page?
Tim Roberts wrote: > tinn...@isbd.co.uk wrote: > > > >I want to run a server side python script when a button on a web page > >is clicked. This is on a LAMP server - apache2 on xubuntu 11.10. > > > >I know I *could* run it as a CGI script but I don't want to change the > >web page at all when the button is clicked (I'll see the effect > >elsewhere on the screen anyway) so normal CGI isn't ideal. > > It seems what you're after is AJAX. If you are using a Javascript > framework like jQuery, it's easy to fire off an asynchronous request back > to your server that leaves the existing page alone. If you aren't, then I > think the easiest method is to use an invisible . From Javascript, > you can set the "src" property of the to fire off a request while > leaving the rest of the page alone. > OK, thanks, I'd sort of found that the answer seems to be AJAX but now you have confirmed it I'll start looking harder. > You could spend the rest of your career reading all of the good web > material on AJAX. :-) -- Chris Green -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the very simplest way to run some Python from a button on a web page?
Chris Angelico wrote: > On Sun, Jan 22, 2012 at 3:36 PM, Tim Roberts wrote: > > It seems what you're after is AJAX. If you are using a Javascript > > framework like jQuery, it's easy to fire off an asynchronous request back > > to your server that leaves the existing page alone. > > If you aren't using a framework, look up the XMLHttpRequest object - > that's what does the work. As Tim says, there's no lack of good > material on the subject. > OK, thanks both, with those pointers I think I'm on the way. -- Chris Green -- http://mail.python.org/mailman/listinfo/python-list
PEP: add __sum__ method
hi all, could you consider adding __sum__ method, e.g. Python sum(a) checks does a have attribute __sum__ and if it has, then a.__sum__() is invoked instead of Python sum(a). (for my soft FuncDesigner it would be very essential, I guess for many other soft as well, e.g. for PuLP, who has to use lpSum, because ordinary Python sum slows it very much, as well as my funcs, and for large-scale problems max recursion depth is exeeded). Regards, D. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP: add __sum__ method
On Sun, 22 Jan 2012 03:15:48 -0800, dmitrey wrote: > hi all, > could you consider adding __sum__ method, e.g. Python sum(a) checks does > a have attribute __sum__ and if it has, then a.__sum__() is invoked > instead of Python sum(a). > (for my soft FuncDesigner it would be very essential, I guess for many > other soft as well, e.g. for PuLP, who has to use lpSum, because > ordinary Python sum slows it very much, as well as my funcs, and for > large-scale problems max recursion depth is exeeded). Regards, D. A cautious +0.5 on that. I think I would need to see more detailed justification before making it +1. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Splitting a file from specific column content
Hi all, I have a text file approximately 20mb in size and contains about one million lines. I was doing some processing on the data but then the data rate increased and it takes very long time to process. I import using numpy.loadtxt, here is a fragment of the data ; 0.06 -0.0004 0.71 0.0028 0.79 0.0044 0.86 0.0104 . . . First column is the timestamp in seconds and second column is the data. File contains 8seconds of measurement, and I would like to be able to split the file into 3 parts seperated from specific time locations. For example I want to divide the file into 3 parts, first part containing 3 seconds of data, second containing 2 seconds of data and third containing 3 seconds. Splitting based on file size doesn't work that accurately for this specific data, some columns become missing and etc. I need to split depending on the column content ; 1 - read file until first character of column1 is 3 (3 seconds) 2 - save this region to another file 3 - read the file where first characters of column1 are between 3 to 5 (2 seconds) 4 - save this region to another file 5 - read the file where first characters of column1 are between 5 to 5 (3 seconds) 6 - save this region to another file I need to do this exactly because numpy.loadtxt or genfromtxt doesn't get well with missing columns / rows. I even tried the invalidraise parameter of genfromtxt but no luck. I am sure it's a few lines of code for experienced users and I would appreciate some guidance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
In article , Yigit Turgut wrote: > Hi all, > > I have a text file approximately 20mb in size and contains about one > million lines. I was doing some processing on the data but then the > data rate increased and it takes very long time to process. I import > using numpy.loadtxt, here is a fragment of the data ; > > 0.06 -0.0004 > 0.71 0.0028 > 0.79 0.0044 > 0.86 0.0104 > . > . > . > > First column is the timestamp in seconds and second column is the > data. File contains 8seconds of measurement, and I would like to be > able to split the file into 3 parts seperated from specific time > locations. For example I want to divide the file into 3 parts, first > part containing 3 seconds of data, second containing 2 seconds of data > and third containing 3 seconds. I would do this with standard unix tools: grep '^[012]' input.txt > first-three-seconds.txt grep '^[34]' input.txt > next-two-seconds.txt grep '^[567]' input.txt > next-three-seconds.txt Sure, it makes three passes over the data, but for 20 MB of data, you could have the whole job done in less time than it took me to type this. As a sanity check, I would run "wc -l" on each of the files and confirm that they add up to the original line count. -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22/01/2012 14:32, Yigit Turgut wrote: Hi all, I have a text file approximately 20mb in size and contains about one million lines. I was doing some processing on the data but then the data rate increased and it takes very long time to process. I import using numpy.loadtxt, here is a fragment of the data ; 0.06 -0.0004 0.71 0.0028 0.79 0.0044 0.86 0.0104 . . . First column is the timestamp in seconds and second column is the data. File contains 8seconds of measurement, and I would like to be able to split the file into 3 parts seperated from specific time locations. For example I want to divide the file into 3 parts, first part containing 3 seconds of data, second containing 2 seconds of data and third containing 3 seconds. Splitting based on file size doesn't work that accurately for this specific data, some columns become missing and etc. I need to split depending on the column content ; 1 - read file until first character of column1 is 3 (3 seconds) 2 - save this region to another file 3 - read the file where first characters of column1 are between 3 to 5 (2 seconds) 4 - save this region to another file 5 - read the file where first characters of column1 are between 5 to 5 (3 seconds) 6 - save this region to another file I need to do this exactly because numpy.loadtxt or genfromtxt doesn't get well with missing columns / rows. I even tried the invalidraise parameter of genfromtxt but no luck. I am sure it's a few lines of code for experienced users and I would appreciate some guidance. Here's a solution in Python 3: input_path = "..." section_1_path = "..." section_2_path = "..." section_3_path = "..." with open(input_path) as input_file: try: line = next(input_file) # Copy section 1. with open(section_1_path, "w") as output_file: while line[0] < "3": output_file.write(line) line = next(input_file) # Copy section 2. with open(section_2_path, "w") as output_file: while line[5] < "5": output_file.write(line) line = next(input_file) # Copy section 3. with open(section_3_path, "w") as output_file: while True: output_file.write(line) line = next(input_file) except StopIteration: pass -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22 January 2012 15:19, MRAB wrote:
> Here's a solution in Python 3:
>
> input_path = "..."
> section_1_path = "..."
> section_2_path = "..."
> section_3_path = "..."
>
> with open(input_path) as input_file:
> try:
> line = next(input_file)
>
> # Copy section 1.
> with open(section_1_path, "w") as output_file:
> while line[0] < "3":
> output_file.write(line)
> line = next(input_file)
>
> # Copy section 2.
> with open(section_2_path, "w") as output_file:
> while line[5] < "5":
> output_file.write(line)
> line = next(input_file)
>
> # Copy section 3.
> with open(section_3_path, "w") as output_file:
> while True:
> output_file.write(line)
> line = next(input_file)
> except StopIteration:
> pass
> --
> http://mail.python.org/mailman/listinfo/python-list
Or more succintly (but not tested):
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
with open(input_path) as input_file:
lines = iter(input_file)
for end, path in sections:
with open(path, "w") as output_file:
for line in lines:
if line >= end:
break
output_file.write(line)
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On Sun, 22 Jan 2012 05:25:25 +, Steven D'Aprano wrote: > Or they've been writing Python code since before version 2.2 when True > and False were introduced, and so they are used to the "while 1" idiom > and never lost the habit. That would be me. As per a now-ancient suggestion on this mailing list (I believe it was by Tim Peters), I've also been known to use a non-empty, literal Python string as a self-documenting, forever-True value in the typical loop-and-a- half cnstruct: while "the temperature is too big": temperature = get_temperature() if temperature <= threshold: break process_temperature(temperature) This way, even though the loop condition is buried inside the loop (which could be longer than four lines), it is apparent as soon as I encounter the loop. With the advent of the "with" statement, though, these loops are slowly disappearing. -- Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22/01/2012 15:39, Arnaud Delobelle wrote:
On 22 January 2012 15:19, MRAB wrote:
Here's a solution in Python 3:
input_path = "..."
section_1_path = "..."
section_2_path = "..."
section_3_path = "..."
with open(input_path) as input_file:
try:
line = next(input_file)
# Copy section 1.
with open(section_1_path, "w") as output_file:
while line[0]< "3":
output_file.write(line)
line = next(input_file)
# Copy section 2.
with open(section_2_path, "w") as output_file:
while line[5]< "5":
output_file.write(line)
line = next(input_file)
# Copy section 3.
with open(section_3_path, "w") as output_file:
while True:
output_file.write(line)
line = next(input_file)
except StopIteration:
pass
--
http://mail.python.org/mailman/listinfo/python-list
Or more succintly (but not tested):
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
with open(input_path) as input_file:
lines = iter(input_file)
for end, path in sections:
with open(path, "w") as output_file:
for line in lines:
if line>= end:
break
output_file.write(line)
Consider the condition "line >= end".
If it's true, then control will break out of the inner loop and start
the inner loop again, getting the next line.
But what of the line which caused it to break out? It'll be lost.
--
http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On 22/01/2012 16:05, Dan Sommers wrote: On Sun, 22 Jan 2012 05:25:25 +, Steven D'Aprano wrote: Or they've been writing Python code since before version 2.2 when True and False were introduced, and so they are used to the "while 1" idiom and never lost the habit. That would be me. As per a now-ancient suggestion on this mailing list (I believe it was by Tim Peters), I've also been known to use a non-empty, literal Python string as a self-documenting, forever-True value in the typical loop-and-a- half cnstruct: while "the temperature is too big": temperature = get_temperature() if temperature<= threshold: break process_temperature(temperature) This way, even though the loop condition is buried inside the loop (which could be longer than four lines), it is apparent as soon as I encounter the loop. And the output of "dis" shows that it's optimised to a forever loop. With the advent of the "with" statement, though, these loops are slowly disappearing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On Jan 22, 4:45 pm, Roy Smith wrote: > In article > , > Yigit Turgut wrote: > > Hi all, > > > I have a text file approximately 20mb in size and contains about one > > million lines. I was doing some processing on the data but then the > > data rate increased and it takes very long time to process. I import > > using numpy.loadtxt, here is a fragment of the data ; > > > 0.06-0.0004 > > 0.710.0028 > > 0.790.0044 > > 0.860.0104 > > . > > . > > . > > > First column is the timestamp in seconds and second column is the > > data. File contains 8seconds of measurement, and I would like to be > > able to split the file into 3 parts seperated from specific time > > locations. For example I want to divide the file into 3 parts, first > > part containing 3 seconds of data, second containing 2 seconds of data > > and third containing 3 seconds. > > I would do this with standard unix tools: > > grep '^[012]' input.txt > first-three-seconds.txt > grep '^[34]' input.txt > next-two-seconds.txt > grep '^[567]' input.txt > next-three-seconds.txt > > Sure, it makes three passes over the data, but for 20 MB of data, you > could have the whole job done in less time than it took me to type this. > > As a sanity check, I would run "wc -l" on each of the files and confirm > that they add up to the original line count. This works and is very fast but it missed a few hundred lines unfortunately. On Jan 22, 5:19 pm, MRAB wrote: > On 22/01/2012 14:32, Yigit Turgut wrote: > > Hi all, > > > I have a text file approximately 20mb in size and contains about one > > million lines. I was doing some processing on the data but then the > > data rate increased and it takes very long time to process. I import > > using numpy.loadtxt, here is a fragment of the data ; > > > 0.06-0.0004 > > 0.710.0028 > > 0.790.0044 > > 0.860.0104 > > . > > . > > . > > > First column is the timestamp in seconds and second column is the > > data. File contains 8seconds of measurement, and I would like to be > > able to split the file into 3 parts seperated from specific time > > locations. For example I want to divide the file into 3 parts, first > > part containing 3 seconds of data, second containing 2 seconds of data > > and third containing 3 seconds. Splitting based on file size doesn't > > work that accurately for this specific data, some columns become > > missing and etc. I need to split depending on the column content ; > > > 1 - read file until first character of column1 is 3 (3 seconds) > > 2 - save this region to another file > > 3 - read the file where first characters of column1 are between 3 to > > 5 (2 seconds) > > 4 - save this region to another file > > 5 - read the file where first characters of column1 are between 5 to > > 5 (3 seconds) > > 6 - save this region to another file > > > I need to do this exactly because numpy.loadtxt or genfromtxt doesn't > > get well with missing columns / rows. I even tried the invalidraise > > parameter of genfromtxt but no luck. > > > I am sure it's a few lines of code for experienced users and I would > > appreciate some guidance. > > Here's a solution in Python 3: > > input_path = "..." > section_1_path = "..." > section_2_path = "..." > section_3_path = "..." > > with open(input_path) as input_file: > try: > line = next(input_file) > > # Copy section 1. > with open(section_1_path, "w") as output_file: > while line[0] < "3": > output_file.write(line) > line = next(input_file) > > # Copy section 2. > with open(section_2_path, "w") as output_file: > while line[5] < "5": > output_file.write(line) > line = next(input_file) > > # Copy section 3. > with open(section_3_path, "w") as output_file: > while True: > output_file.write(line) > line = next(input_file) > except StopIteration: > pass With the following correction ; while line[5] < "5": should be while line[0] < "5": This works well. On Jan 22, 5:39 pm, Arnaud Delobelle wrote: > On 22 January 2012 15:19, MRAB wrote: > > Here's a solution in Python 3: > > > input_path = "..." > > section_1_path = "..." > > section_2_path = "..." > > section_3_path = "..." > > > with open(input_path) as input_file: > >try: > >line = next(input_file) > > ># Copy section 1. > >with open(section_1_path, "w") as output_file: > >while line[0] < "3": > >output_file.write(line) > >line = next(input_file) > > ># Copy section 2. > >with open(section_2_path, "w") as output_file: > >while line[5] < "5": > >output_file.write(line) > >line = next(input_file) > > ># Copy section 3. > >with open(section_3_path, "w") as output_file: > >while T
Re: bufsize in subprocess
On 2012-01-22 00:27, Chris Rebert wrote:
On Sat, Jan 21, 2012 at 9:45 PM, wrote:
Is this the expected behavior?
Yes. `.read()` [with no argument] on a file-like object reads until
EOF. See http://docs.python.org/library/stdtypes.html#file.read
Right, got it now.
You want proc.stdout.readline().
Yes, or a for loop, this works for me now:
import subprocess
com = ['/bin/ls', '-l', '/usr/bin']
with subprocess.Popen(com, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT) as proc:
for line in proc:
print('out: ' + str(line, 'utf8'))
--
Yves. http://www.SollerS.ca/
http://ipv6.SollerS.ca
http://blog.zioup.org/
--
http://mail.python.org/mailman/listinfo/python-list
Looking under Python's hood: Will we find a high performance or clunky engine?
What does Python do when presented with this code?
py> [line.strip('\n') for line in f.readlines()]
If Python reads all the file lines first and THEN iterates AGAIN to do
the strip; we are driving a Fred flintstone mobile. If however Python
strips each line of the lines passed into readlines in one fell swoop,
we made the correct choice.
Which is it Pythonistas? Which is it?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22/01/2012 16:17, Yigit Turgut wrote:
[snip]
On Jan 22, 5:39 pm, Arnaud Delobelle wrote:
[snip]
Or more succintly (but not tested):
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
with open(input_path) as input_file:
lines = iter(input_file)
for end, path in sections:
with open(path, "w") as output_file:
for line in lines:
if line>= end:
break
output_file.write(line)
--
Arnaud
Good idea. Especially when dealing with variable numbers of sections.
But somehow I got ;
("5", "section_2")
TypeError: 'tuple' object is not callable
That's due to missing commas:
sections = [
("3", "section_1"),
("5", "section_2"),
("\xFF", "section_3")
]
--
http://mail.python.org/mailman/listinfo/python-list
Re: bufsize in subprocess
import subprocess
com = ['/bin/ls', '-l', '/usr/bin']
with subprocess.Popen(com, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
as proc:
for line in proc.stdout:
print('out: ' + str(line, 'utf8'))
--
Yves. http://www.SollerS.ca/
http://ipv6.SollerS.ca
http://blog.zioup.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On Jan 22, 6:56 pm, MRAB wrote:
> On 22/01/2012 16:17, Yigit Turgut wrote:
> [snip]
>
>
>
>
>
>
>
> > On Jan 22, 5:39 pm, Arnaud Delobelle wrote:
> [snip]
> >> Or more succintly (but not tested):
>
> >> sections = [
> >> ("3", "section_1")
> >> ("5", "section_2")
> >> ("\xFF", "section_3")
> >> ]
>
> >> with open(input_path) as input_file:
> >> lines = iter(input_file)
> >> for end, path in sections:
> >> with open(path, "w") as output_file:
> >> for line in lines:
> >> if line>= end:
> >> break
> >> output_file.write(line)
>
> >> --
> >> Arnaud
>
> > Good idea. Especially when dealing with variable numbers of sections.
> > But somehow I got ;
>
> > ("5", "section_2")
> > TypeError: 'tuple' object is not callable
>
> That's due to missing commas:
>
> sections = [
> ("3", "section_1"),
> ("5", "section_2"),
> ("\xFF", "section_3")
> ]
Thank you.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
Am 22.01.2012 16:50, schrieb Rick Johnson:
What does Python do when presented with this code?
py> [line.strip('\n') for line in f.readlines()]
If Python reads all the file lines first and THEN iterates AGAIN to do
the strip; we are driving a Fred flintstone mobile. If however Python
strips each line of the lines passed into readlines in one fell swoop,
we made the correct choice.
Which is it Pythonistas? Which is it?
You aren't one (considering how vocal you are in arguing for changes to
the language)?
So: shouldn't you be able to answer your own question?
--
--- Heiko.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On 1/22/12 3:50 PM, Rick Johnson wrote:
What does Python do when presented with this code?
py> [line.strip('\n') for line in f.readlines()]
If Python reads all the file lines first and THEN iterates AGAIN to do
the strip; we are driving a Fred flintstone mobile. If however Python
strips each line of the lines passed into readlines in one fell swoop,
we made the correct choice.
Which is it Pythonistas? Which is it?
The .readlines() method is an old API that predates the introduction of
iterators to Python. The modern way to do this in one iteration is to use the
file object as an iterator:
[line.strip('\n') for line in f]
--
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On Sun, Jan 22, 2012 at 8:50 AM, Rick Johnson
wrote:
>
> What does Python do when presented with this code?
>
> py> [line.strip('\n') for line in f.readlines()]
>
> If Python reads all the file lines first and THEN iterates AGAIN to do
> the strip; we are driving a Fred flintstone mobile. If however Python
> strips each line of the lines passed into readlines in one fell swoop,
> we made the correct choice.
>
> Which is it Pythonistas? Which is it?
>
>
Two iterations. And since that is the only possible way to do this, you
are correct, the language is terribly archaic. I suggest you switch to
Ruby ASAP.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 01/22/12 08:45, Roy Smith wrote: I would do this with standard unix tools: grep '^[012]' input.txt> first-three-seconds.txt grep '^[34]' input.txt> next-two-seconds.txt grep '^[567]' input.txt> next-three-seconds.txt Sure, it makes three passes over the data, but for 20 MB of data, you could have the whole job done in less time than it took me to type this. If you wanted to do it in one pass using standard unix tools, you can use: sed -n -e'/^[0-2]/w first-three.txt' -e'/^[34]/w next-two.txt' -e'/^[5-7]/w next-three.txt' -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
I stand humbled. On Jan 22, 2012, at 2:25 PM, Tim Chase wrote: > On 01/22/12 08:45, Roy Smith wrote: >> I would do this with standard unix tools: >> >> grep '^[012]' input.txt> first-three-seconds.txt >> grep '^[34]' input.txt> next-two-seconds.txt >> grep '^[567]' input.txt> next-three-seconds.txt >> >> Sure, it makes three passes over the data, but for 20 MB of data, you >> could have the whole job done in less time than it took me to type this. > > > If you wanted to do it in one pass using standard unix tools, you can use: > > sed -n -e'/^[0-2]/w first-three.txt' -e'/^[34]/w next-two.txt' -e'/^[5-7]/w > next-three.txt' > > -tkc > > > -- Roy Smith r...@panix.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 01/22/12 13:26, Roy Smith wrote: If you wanted to do it in one pass using standard unix tools, you can use: sed -n -e'/^[0-2]/w first-three.txt' -e'/^[34]/w next-two.txt' -e'/^[5-7]/w next-three.txt' I stand humbled. In all likelyhood, you stand *younger*, not so much humbled ;-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On Jan 22, 2012, at 2:34 PM, Tim Chase wrote: > On 01/22/12 13:26, Roy Smith wrote: >>> If you wanted to do it in one pass using standard unix >>> tools, you can use: >>> >>> sed -n -e'/^[0-2]/w first-three.txt' -e'/^[34]/w >>> next-two.txt' -e'/^[5-7]/w next-three.txt' >>> >> I stand humbled. > > In all likelyhood, you stand *younger*, not so much humbled ;-) Oh, yeah? That must explain my grey hair and bifocals. I go back to Unix v6 in 1977. Humbled it is. -- Roy Smith r...@panix.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22 January 2012 16:09, MRAB wrote:
> On 22/01/2012 15:39, Arnaud Delobelle wrote:
[...]
>> Or more succintly (but not tested):
>>
>>
>> sections = [
>> ("3", "section_1")
>> ("5", "section_2")
>> ("\xFF", "section_3")
>> ]
>>
>> with open(input_path) as input_file:
>> lines = iter(input_file)
>> for end, path in sections:
>> with open(path, "w") as output_file:
>> for line in lines:
>> if line>= end:
>> break
>> output_file.write(line)
>>
> Consider the condition "line >= end".
>
> If it's true, then control will break out of the inner loop and start
> the inner loop again, getting the next line.
>
> But what of the line which caused it to break out? It'll be lost.
Of course you're correct - my reply was too rushed. Here's a
hopefully working version (but still untested :).
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
with open(input_path) as input_file:
line, lines = "", iter(input_file)
for end, path in sections:
with open(path, "w") as output_file:
output_file.write(line)
for line in lines:
if line >= end:
break
output_file.write(line)
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Trouble with internationalized path under windows
I have a problem which ought to have an obvious solution, but I haven't found one despite searching for many hours. The problem occurs on Windows. This is a version of my problem reduced to its essentials: I have a file foo.py:: import bar and a file bar.py : baz = 42 If I store these two files in say C:\Users\Admin\test everything works fine. If I store them in C:\Users\Admin\testф, I get an import error when running foo.py. The letter at the end of test is a Russian "F", if it looks strange on your terminal. Am using WIndows 7 with a Swedish locale. The program uses Unicode successfully internally, and the Windows help says that the locale only applies to non-Unicode programs. I have tried with using characters from the Latin-1 character set in the path, ones that are not in the ASCII character set. In this case, things work fine. What am missing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On Jan 22, 9:37 pm, Roy Smith wrote: > On Jan 22, 2012, at 2:34 PM, Tim Chase wrote: > > > On 01/22/12 13:26, Roy Smith wrote: > >>> If you wanted to do it in one pass using standard unix > >>> tools, you can use: > > >>> sed -n -e'/^[0-2]/w first-three.txt' -e'/^[34]/w > >>> next-two.txt' -e'/^[5-7]/w next-three.txt' > > >> I stand humbled. > > > In all likelyhood, you stand *younger*, not so much humbled ;-) > > Oh, yeah? That must explain my grey hair and bifocals. I go back to Unix > v6 in 1977. Humbled it is. Those times were much better IMHO (: -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
On Sun, Jan 22, 2012 at 12:08 PM, Jacob Hallén wrote: > I have a problem which ought to have an obvious solution, but I haven't found > one despite searching for many hours. The problem occurs on Windows. > > This is a version of my problem reduced to its essentials: > > I have a file foo.py:: > > import bar > > and a file bar.py : > > baz = 42 > > If I store these two files in say C:\Users\Admin\test everything works fine. > > If I store them in C:\Users\Admin\testф, I get an import error when running > foo.py. The letter at the end of test is a Russian "F", if it looks strange on > your terminal. What's the ImportError message say? And what version of Python are you using? Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
On 1/22/2012 2:08 PM, Jacob Hallén wrote: > Am using WIndows 7 with a Swedish locale. The program uses Unicode > successfully internally, and the Windows help says that the locale only > applies to non-Unicode programs. I have tried with using characters from the > Latin-1 character set in the path, ones that are not in the ASCII character > set. In this case, things work fine. If it's a character you can type on your terminal, you shouldn't have issues, but pasting other characters doesn't work (they're converted to other characters). Despite Unicode being used for everything else, the terminal on Windows still uses a locale-dependent code page for character encoding. There is supposed to be a UTF-8 code page (cp65001), but it's not supported by Python (3.3 is planned to support it), and it doesn't even seem to work, at least for me. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
The grep solution is not cross-platform, and not really an answer to a
question about python.
The by-line iteration examples are inefficient and bad practice from a
numpy/vectorization perspective.
I would advice to do it the numpythonic way (untested code):
breakpoints = [3, 5, 7]
data = np.loadtxt('data.txt')
time = data[:,0]
indices = np.searchsorted(time, breakpoints)
chunks = np.split(data, indices, axis=0)
for i, d in enumerate(chunks):
np.savetxt('data'+str(i)+'.txt', d)
Not sure how it compared to the grep solution in terms of performance,
but that should be quite a non-issue for 20mb of data, and its sure to
blow the by-line iteration out of the water. If you want to be more
efficient, you are going to have to cut the text-to-numeric parsing
out of the loop, which is the vast majority of the computational load
here; but if thats possible at all depends on how structured your
timestamps are; there must be a really compelling performance gain to
justify throwing the elegance of the np.split based solution out of
the window, in my opinion.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
On Jan 22, 2:08 pm, Jacob Hallén wrote: > If I store these two files in say C:\Users\Admin\test everything works fine. > > If I store them in C:\Users\Admin\testф, I get an import error when running > foo.py. The letter at the end of test is a Russian "F", if it looks strange on > your terminal. If *only* i had a penny for every problem that Unicode caused... maybe i could i buy a 76,000 sqft mansion, because, people should not be forced to sleep in the same room twice! Unicode is just another Utopian nightmare. When will the lemmings realize that character encoding IS NOT the root of the problem? You will NEVER find the holy grail of encodings that will solve the collaborative issue because the PROBLEM is multiplicity! Self induced! -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a file from specific column content
On 22/01/2012 19:58, Arnaud Delobelle wrote:
On 22 January 2012 16:09, MRAB wrote:
On 22/01/2012 15:39, Arnaud Delobelle wrote:
[...]
Or more succintly (but not tested):
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
with open(input_path) as input_file:
lines = iter(input_file)
for end, path in sections:
with open(path, "w") as output_file:
for line in lines:
if line>= end:
break
output_file.write(line)
Consider the condition "line>= end".
If it's true, then control will break out of the inner loop and start
the inner loop again, getting the next line.
But what of the line which caused it to break out? It'll be lost.
Of course you're correct - my reply was too rushed. Here's a
hopefully working version (but still untested :).
sections = [
("3", "section_1")
("5", "section_2")
("\xFF", "section_3")
]
[snip]
Missing commas! :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
* Ian Kelly [2012-01-22 19:29]:
> On Sun, Jan 22, 2012 at 8:50 AM, Rick Johnson
> wrote:
>
> >
> > What does Python do when presented with this code?
> >
> > py> [line.strip('\n') for line in f.readlines()]
> >
> > If Python reads all the file lines first and THEN iterates AGAIN to do
> > the strip; we are driving a Fred flintstone mobile. If however Python
> > strips each line of the lines passed into readlines in one fell swoop,
> > we made the correct choice.
> >
> > Which is it Pythonistas? Which is it?
I cannot understand why it is so important for you to store
lines out of a textfile in a list without '\n'.
have you ever considered the *pros* of leaving '\n' ?
> >
> >
> Two iterations. And since that is the only possible way to do this, you
> are correct, the language is terribly archaic. I suggest you switch to
> Ruby ASAP.
why there is only one possibility to do so? in a second i found this
''.join(open('test').readlines()).split('\n')
and if you don't like python, then stick to ruby. who cares???
--
Michael Poeltl
Computational Materials Physics voice: +43-1-4277-51409
Univ. Wien, Sensengasse 8/12 fax: +43-1-4277-9514 (or 9513)
A-1090 Wien, AUSTRIA cmp.mpi.univie.ac.at
---
ubuntu-11.10 | vim-7.3 | python-3.2.2 | mutt-1.5.21 | elinks-0.12
---
On Sun, Jan 22, 2012 at 8:50 AM, Rick Johnson wrote:
What does Python do when presented with this code?
py> [line.strip('\n') for line in f.readlines()]
If Python reads all the file lines first and THEN iterates AGAIN to do
the strip; we are driving a Fred flintstone mobile. If however Python
strips each line of the lines passed into readlines in one fell swoop,
we made the correct choice.
Which is it Pythonistas? Which is it?Two iterations. And since that is the only possible way to do this, you are correct, the language is terribly archaic. I suggest you switch to Ruby ASAP.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
Sunday 22 January 2012 you wrote: > On Sun, Jan 22, 2012 at 12:08 PM, Jacob Hallén > > wrote: > > I have a problem which ought to have an obvious solution, but I haven't > > found one despite searching for many hours. The problem occurs on > > Windows. > > > > This is a version of my problem reduced to its essentials: > > > > I have a file foo.py:: > > > > import bar > > > > and a file bar.py : > > > > baz = 42 > > > > If I store these two files in say C:\Users\Admin\test everything works > > fine. > > > > If I store them in C:\Users\Admin\testф, I get an import error when > > running foo.py. The letter at the end of test is a Russian "F", if it > > looks strange on your terminal. > > What's the ImportError message say? And what version of Python are you > using? > > Cheers, > Chris I'm using Python 2.7.2. I'm getting "ImportError: No module named bar". This is what I can see when running from the command prompt. If I run from the file manager the command window goes away too quickly for me to see the error. Idle is unable to open files in the directory at all. Cheers Jacob Hallén -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On 22 January 2012 20:57, Michael Poeltl wrote:
> > Two iterations. And since that is the only possible way to do this, you
> > are correct, the language is terribly archaic. I suggest you switch to
> > Ruby ASAP.
> why there is only one possibility to do so? in a second i found this
> ''.join(open('test').readlines()).split('\n')
>
> and if you don't like python, then stick to ruby. who cares???
I'm pretty sure that was sarcasm, but as was said before ".readlines()" is
superfluous and the original comment was wrong.
''.join(open('test').readlines()).split('\n')
==
''.join(open('test')).split('\n')
==
open('test').read().split('\n')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
Sunday 22 January 2012 you wrote: > On Sun, Jan 22, 2012 at 12:08 PM, Jacob Hallén > > wrote: > > I have a problem which ought to have an obvious solution, but I haven't > > found one despite searching for many hours. The problem occurs on > > Windows. > > > > This is a version of my problem reduced to its essentials: > > > > I have a file foo.py:: > > > > import bar > > > > and a file bar.py : > > > > baz = 42 > > > > If I store these two files in say C:\Users\Admin\test everything works > > fine. > > > > If I store them in C:\Users\Admin\testф, I get an import error when > > running foo.py. The letter at the end of test is a Russian "F", if it > > looks strange on your terminal. > I should add that I'm changing the path name by using the file manager in Windows (this is Windows 7 btw) and changing my keyboard to a Russian keyboard. This is a standard Windows i18n facility. Jacob Hallén -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On 01/22/2012 08:50 AM, Rick Johnson wrote:
>
> What does Python do when presented with this code?
>
> py> [line.strip('\n') for line in f.readlines()]
>
> If Python reads all the file lines first and THEN iterates AGAIN to do
> the strip; we are driving a Fred flintstone mobile. If however Python
> strips each line of the lines passed into readlines in one fell swoop,
> we made the correct choice.
>
> Which is it Pythonistas? Which is it?
You're doing it wrong, obviously. I'm actually surprised that an expert
such as yourself would read a file in this way. In any language.
Surely you would iterate over the file object which is the obvious way
to do it.
I guess we'll chalk this up as another python pitfall. Looking forward
to your programming language which will prevent such things while
maintaining the purity and beauty of Python's ideals.
--
http://mail.python.org/mailman/listinfo/python-list
building foo.pyd, _initfoo vs. initfoo
Hi all.
Usually I work on Linux and all my cmake-built Python extensions working there
without trouble. Now these things need to work on Windows as well. While the
code itself compiles fine, linking and loading makes trouble.
First of, to successfully link everything with mingw (g++-4.4.0, somewhat
oldish) I had to define:
-DPy_ENABLE_SHARED -DPy_BUILD_CORE
Not sure if this makes sense, but if it works, fine by me. Now, loading the
module is different.
First attempts of loading the module failed miserably until I found out that
Python expects files with a .pyd suffix. Very innovative to throw off the
layman. Took that hurdle.
Finally, on load of foo.pyd, I get:
"Import Error: dynamic module does not define init function (initfoo)"
As this module loads fine in Linux, there is an initfoo() defined. Checking
with `nm`, I find two things:
1. The function name is mangled (__Z12initfoov)
-> the module is compiled with g++, but I believed that PyMODINIT_FUNC
includes the 'extern "C"' apparatus?
2. Manually enclosing the init function with 'extern "C" {}" still yields the
same error
-> the function name also comes with a leading underscore '_', i.e.
"_initfoo", not "initfoo"
Could someone knowledge with Windows and MinGW help me to sort this out? Tools
used: cmake-2.8.3, mingw-? with gcc-4.4 and Python-2.7.2 from python.org.
Thanks
Daniel
--
http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
On 01/22/2012 01:52 PM, Rick Johnson wrote: > On Jan 22, 2:08 pm, Jacob Hallén wrote: > >> If I store these two files in say C:\Users\Admin\test everything works fine. >> >> If I store them in C:\Users\Admin\testф, I get an import error when running >> foo.py. The letter at the end of test is a Russian "F", if it looks strange >> on >> your terminal. > > If *only* i had a penny for every problem that Unicode caused... maybe > i could i buy a 76,000 sqft mansion, because, people should not be > forced to sleep in the same room twice! > > Unicode is just another Utopian nightmare. When will the lemmings > realize that character encoding IS NOT the root of the problem? You > will NEVER find the holy grail of encodings that will solve the > collaborative issue because the PROBLEM is multiplicity! Self induced! Um, face palm. I'm so embarrassed for you Rick. The problem appears not be with programming or handling character sets or anything like that. Then you go on to say let's stick to English? Just wow. At least you are being entertaining for now. I once argued to limit Python identifiers to latin letters only, but at least that made some sort of sense (lowest-common denominator) and it had nothing to do with running in an internationalized environment or dealing with unicode or utf-8 -encoded text files. The OP's problem definitely sounds like a Python bug on Windows to me. I've never had similar problems on other internationalized OS's like Linux or OS X. How can you be Python's savior when you want to discount out of hand at least have of Python's users? -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
Jacob Hallén sotospeak.se> writes: > > I have a problem which ought to have an obvious solution, but I haven't found > one despite searching for many hours. The problem occurs on Windows. You may be running into the brokenness of the Python import system prior to 3.2. See http://bugs.python.org/issue3080 -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On Jan 22, 6:38 pm, Michael Torrie wrote:
> On 01/22/2012 08:50 AM, Rick Johnson wrote:
>
>
>
> > What does Python do when presented with this code?
>
> > py> [line.strip('\n') for line in f.readlines()]
>
> > If Python reads all the file lines first and THEN iterates AGAIN to do
> > the strip; we are driving a Fred flintstone mobile. If however Python
> > strips each line of the lines passed into readlines in one fell swoop,
> > we made the correct choice.
>
> > Which is it Pythonistas? Which is it?
>
> You're doing it wrong, obviously. I'm actually surprised that an expert
> such as yourself would read a file in this way. In any language.
> Surely you would iterate over the file object which is the obvious way
> to do it.
That's just the point. If an expert such as myself can make a simple
mistake as this, then one can only expect that the neophytes are going
to suffer greatly. I wonder how many tutorials are out there in WWW
still teaching old ways of writing Python code? Old ways that have
been superseded by newer versions.
> I guess we'll chalk this up as another python pitfall. Looking forward
> to your programming language which will prevent such things while
> maintaining the purity and beauty of Python's ideals.
Purity is a myth perpetrated by those who are blinded by their own
sanctimonious ideals of self worth. Any language that vows to be
"pure" (in a backwards compatible sense) is doomed to bitrot.
Programming languages and creators have a father and daughter
relationship.
The creator (father) wants his language (daughter) to be pure forever
and ever. You can lock her away in a tower with a titanium chastity
belt and stick your head in the sand but sooner or later a prince
charming (evolution) is going to come along and defile her. Will you
have the strength to realize that your daughters life is more
important than your feeble attachments to nostalgic purity?
The fact is, Python's purity has been defiled already. And although we
must give GvR the credit he deserves for making these long overdue
changes, he did not go far enough. Essentially he has accepted his
daughter will not longer be pure but he refuses to acknowledge the new
communion. His internal drive to evolve hath waxed cold. He has the
license plate and the job title and that seems to be enough. Where is
the passion?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking under Python's hood: Will we find a high performance or clunky engine?
On 01/22/2012 06:04 PM, Rick Johnson wrote: > That's just the point. If an expert such as myself can make a simple > mistake as this, then one can only expect that the neophytes are going > to suffer greatly. I wonder how many tutorials are out there in WWW > still teaching old ways of writing Python code? Old ways that have > been superseded by newer versions. Well that's that then. Everything is good. > Programming languages and creators have a father and daughter > relationship. > > The creator (father) wants his language (daughter) to be pure forever > and ever. Good thing you are so funny, or back into the plonk file you would go. You're welcome to fork and deflower our pure Python if you want (you seem to be quite stuck on sex metaphors). Please feel free. Looking forward to your less-virginal take on the language. Seems like you know what's best, and only you can save and ravish Python at the same time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble with internationalized path under windows
On Jan 22, 6:47 pm, Michael Torrie wrote: > I once argued to limit Python identifiers to latin letters only, but at > least that made some sort of sense (lowest-common denominator) and it > had nothing to do with running in an internationalized environment or > dealing with unicode or utf-8 -encoded text files. > [...] > How can you be Python's savior when you want to discount out of hand at > least [half] of Python's users? I don't want to limit ANYONE's usage of Python, quite the contrary. My crusade against Unicode is to the benefit of all peoples of this planet. Actually my crusade is even greater than Unicode itself. It's a crusade for unity. The problem with humans is that we just simply accept most things too easily. We never stop to ask ourselves "why"? Did you know that when a driver's car breaks down on a lonely county road he has a significantly higher chance of receiving help from passers-by than a driver broke down on a busy highway? Why does this happen? I'll tell you why -- and it's not because "country folk" are more helpful than "city folk". The reason is blind acceptance. The reason is lack of inquisitiveness. Many of the folks who drive by on the major freeway want to stop and help, but they don't because they convince themselves that since SO MANY folks are driving by, surely *somebody* will stop and help. Well, the problem is, everyone imagines the same outcome and the poor sap broke down on the interstate NEVER receives any help. The fact is, Unicode is nothing more than a monkey patch for language multiplicity. A multiplicity that is perpetuated on the masses due to a blind adherence to the cult of xenophobia. My mission is plant seeds of inquisitiveness in the minds of these people. To help them understand that they do not need to suffer the under the pain of multiplicity any longer. And finally, to help them understand that we must destroy multiplicity before we can evolve to the next level. -- http://mail.python.org/mailman/listinfo/python-list
Re: while True or while 1
On Jan 23, 2:05 am, Dan Sommers wrote: > As per a now-ancient suggestion on this mailing list (I believe it was by > Tim Peters), I've also been known to use a non-empty, literal Python > string as a self-documenting, forever-True value in the typical loop-and-a- > half cnstruct: > > while "the temperature is too big": I don't think I've ever encountered this before, but I like it :) Cheers! -- http://mail.python.org/mailman/listinfo/python-list
__future__ and __rdiv__
Hello everybody, I hope somebody could help me with this problem. If this is not the right place to ask, please direct me to the right place and apologies. I am using Python 2.7 and I am writing some code I want to work on 3.x as well. The problem can be reproduced with this code: # from __future__ import division class Number(object): def __init__(self,number): self.number=number def __rdiv__(self,other): return other/self.number print 10/Number(5) It prints 2 as I expect. But if I uncomment the first line, I get: Traceback (most recent call last): File "test.py", line 8, in print 10/Number(5) TypeError: unsupported operand type(s) for /: 'int' and 'Number' Is this a bug or the __future__ division in 3.x changed the way operators are overloaded? Where can I read more? Massimo -- http://mail.python.org/mailman/listinfo/python-list
Re: __future__ and __rdiv__
On Sun, Jan 22, 2012 at 10:22 PM, Massimo Di Pierro < massimo.dipie...@gmail.com> wrote: > Hello everybody, > > I hope somebody could help me with this problem. If this is not the right > place to ask, please direct me to the right place and apologies. > I am using Python 2.7 and I am writing some code I want to work on 3.x as > well. The problem can be reproduced with this code: > > # from __future__ import division > class Number(object): >def __init__(self,number): >self.number=number >def __rdiv__(self,other): >return other/self.number > print 10/Number(5) > > It prints 2 as I expect. But if I uncomment the first line, I get: > > Traceback (most recent call last): > File "test.py", line 8, in >print 10/Number(5) > TypeError: unsupported operand type(s) for /: 'int' and 'Number' > > Is this a bug or the __future__ division in 3.x changed the way operators > are overloaded? Where can I read more? > > In Python 3, the / operator uses __truediv__ and the // operator uses __floordiv__. In Python 2, the / operator uses __div__, unless the future import is in effect, and then it uses __truediv__ like Python 3. http://docs.python.org/reference/datamodel.html#emulating-numeric-types Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: __future__ and __rdiv__
Thank you. I tried __rtruediv__ and it works. On Jan 23, 2012, at 12:14 AM, Ian Kelly wrote: > On Sun, Jan 22, 2012 at 10:22 PM, Massimo Di Pierro > wrote: > Hello everybody, > > I hope somebody could help me with this problem. If this is not the right > place to ask, please direct me to the right place and apologies. > I am using Python 2.7 and I am writing some code I want to work on 3.x as > well. The problem can be reproduced with this code: > > # from __future__ import division > class Number(object): >def __init__(self,number): >self.number=number >def __rdiv__(self,other): >return other/self.number > print 10/Number(5) > > It prints 2 as I expect. But if I uncomment the first line, I get: > > Traceback (most recent call last): > File "test.py", line 8, in >print 10/Number(5) > TypeError: unsupported operand type(s) for /: 'int' and 'Number' > > Is this a bug or the __future__ division in 3.x changed the way operators are > overloaded? Where can I read more? > > > In Python 3, the / operator uses __truediv__ and the // operator uses > __floordiv__. > In Python 2, the / operator uses __div__, unless the future import is in > effect, and then it uses __truediv__ like Python 3. > > http://docs.python.org/reference/datamodel.html#emulating-numeric-types > > Cheers, > Ian -- http://mail.python.org/mailman/listinfo/python-list
lxml to parse html
import lxml.html
myxml='''
'''
root=lxml.html.fromstring(myxml)
nodes1=root.xpath('//job[@DecreaseHour="1"]')
nodes2=root.xpath('//job[@ne_type="101"]')
print "nodes1=",nodes1
print "nodes2=",nodes2
what i get is:
nodes1=[] and
nodes2=[]
why nodes1 is []?nodes2=[],
it is so strange thing?why ?
--
http://mail.python.org/mailman/listinfo/python-list
lxml to parse html
import lxml.html
myxml='''
'''
root=lxml.html.fromstring(myxml)
nodes1=root.xpath('//job[@DecreaseHour="1"]')
nodes2=root.xpath('//job[@table="tpa_radio_sum"]')
print "nodes1=",nodes1
print "nodes2=",nodes2
>>>
nodes1= []
nodes2= [, , ]
would you mind to tell me why nodes1=[]??
--
http://mail.python.org/mailman/listinfo/python-list
