Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 02:37:35 +0800, Ma Xiaojun wrote: For pure procedural paradigm, I haven't seen much advantages of Python. Nice syntax with a minimum of boiler plate -- executable pseudo-code, as they say. Extensive library support -- batteries included. These are both good advantages. Yes, Python has true OOP but I don't like this argument since I don't like Java-ism true OOP. Java is not the best example of OOP. In some ways, it is a terrible example of OOP: some values are not objects, classes are not first-class values, and the language is horribly verbose. There are good reasons for some of these things, but good reasons or bad, Java is *not* the exemplar of OOP that some Java coders believe. In some ways, Python is a more pure OOP language than Java: everything in Python is an object, including classes themselves. In other ways, Python is a less pure and more practical language. You don't have to wrap every piece of functionality in a class. Python encourages you to write mixed procedural, functional and object oriented code, whatever is best for the problem you are trying to solve, which is very much in contrast to Java: http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of- nouns.html Yes, Python has much more libraries. But it seems that Python is more useful and suitable in CLI and Web applications. That is fair. All languages have their strengths and weaknesses. I wouldn't use Python to program low-level device driver code, and I wouldn't write a web-app in C. People are still discussing whether to replace tkinter with wxPython or not. VB and VFP people are never bothered with such issue. Which people? People can discuss any rubbish they like. For many reasons, tkinter will not be replaced. For the standard library, it is a good, stable, powerful but not cutting-edge GUI library. If you don't like it, you can install a third-party framework like wxPython. Using tkinter is not compulsory. In the case of VB and VFP, they aren't bothered by such issues because they're used to closed-source, proprietary programming where you use what you are given and like it. In the open-source world, if you don't like what you are given, you find something else, and if you can't find it, you make it yourself. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a callable for any value?
On Wed, 29 May 2013 12:46:19 -0500, Croepha wrote: Is there anything like this in the standard library? class AnyFactory(object): def __init__(self, anything): self.product = anything def __call__(self): return self.product def __repr__(self): return %s.%s(%r) % (self.__class__.__module__, self.__class__.__name__, self.product) my use case is: collections.defaultdict(AnyFactory(collections.defaultdict( AnyFactory(None That's not a use-case. That's a code snippet. What does it mean? Why would you write such an ugly thing? What does it do? I get a headache just looking at it. I *think* it's a defaultdict that returns a defaultdict on KeyError, where the *second* defaultdict returns None. from collections import defaultdict defaultdict(lambda: defaultdict(lambda: None)) looks more reasonable to me. I don't know why you need to wrap such a simple pair of functions in a class. This is not Java. http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of-nouns.html (Twice in one day I have linked to this.) I'm not sure why you care about the repr of the AnythingFactory object. You stuff it directly into the defaultdict, where you are very unlikely to need to inspect it. You only ever see the defaultdicts they return, and they already have a nice repr. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
Steven D'Aprano writes: On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote: Let's suppose someone is told to compare floating point numbers by seeing if the absolute value of the difference is less than some epsilon. Which is usually the wrong way to do it! Normally one would prefer *relative* error, not absolute: # absolute error: abs(a - b) epsilon # relative error: abs(a - b)/a epsilon ... I wonder why floating-point errors are not routinely discussed in terms of ulps (units in last position). There is a recipe for calculating the difference of two floating point numbers in ulps, and it's possible to find the previous or next floating point number, but I don't know of any programming language having built-in support for these. Why isn't this considered the most natural measure of a floating point result being close to a given value? The meaning is roughly this: how many floating point numbers there are between these two. close enough if abs(ulps(a, b)) 3 else not close enough equal if ulps(a, b) == 0 else not equal There must be some subtle technical issues here, too, but it puzzles me that this measure of closeness is not often even discussed when absolute and relative error are discussed - and computed using the same approximate arithmetic whose accuracy is being measured. Scary. Got light? -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
Can ypou tell me how to install MySQLdb in python 3 using pip? pip install MySQLdb doesnt find the module. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 3:42 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote: Let's suppose someone is told to compare floating point numbers by seeing if the absolute value of the difference is less than some epsilon. Which is usually the wrong way to do it! Normally one would prefer *relative* error, not absolute: # absolute error: abs(a - b) epsilon # relative error: abs(a - b)/a epsilon I was picking an epsilon based on a, though, which comes to pretty much the same thing as the relative error calculation you're using. But using relative error also raises questions: - what if a is negative? - why relative to a instead of relative to b? - what if a is zero? The first, at least, is easy to solve: take the absolute value of a. One technique I saw somewhere is to use the average of a and b. But probably better is to take the lower absolute value (ie the larger epsilon). However, there's still the question of what epsilon should be - what percentage of a or b you take to mean equal - and that one is best answered by looking at the original inputs. Take these guys, for instance. Doing the same thing I was, only with more accuracy. http://www.youtube.com/watch?v=ZNiRzZ66YN0 ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote: I wonder why floating-point errors are not routinely discussed in terms of ulps (units in last position). There is a recipe for calculating the difference of two floating point numbers in ulps, and it's possible to find the previous or next floating point number, but I don't know of any programming language having built-in support for these. That is an excellent question! I think it is because the traditional recipes for close enough equality either pre-date any standardization of floating point types, or because they're written by people who are thinking about abstract floating point numbers and not considering the implementation. Prior to most compiler and hardware manufacturers standardizing on IEEE 754, there was no real way to treat float's implementation in a machine independent way. Every machine laid their floats out differently, or used different number of bits. Some even used decimal, and in the case of a couple of Russian machines, trinary. (Although that's going a fair way back.) But we now have IEEE 754, and C has conquered the universe, so it's reasonable for programming languages to offer an interface for accessing floating point objects in terms of ULPs. Especially for a language like Python, which only has a single float type. I have a module that works with ULPs. I may clean it up and publish it. Would there be interest in seeing it in the standard library? Why isn't this considered the most natural measure of a floating point result being close to a given value? The meaning is roughly this: how many floating point numbers there are between these two. There are some subtleties here also. Firstly, how many ULP should you care about? Three, as you suggest below, is awfully small, and chances are most practical, real-world calculations could not justify 3 ULP. Numbers that we normally care about, like 0.01mm, probably can justify thousands of ULP when it comes to C-doubles, which Python floats are. Another subtlety: small-but-positive numbers are millions of ULP away from small-but-negative numbers. Also, there are issues to do with +0.0 and -0.0, NANs and the INFs. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 2:18 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Which people? People can discuss any rubbish they like. For many reasons, tkinter will not be replaced. For the standard library, it is a good, stable, powerful but not cutting-edge GUI library. If you don't like it, you can install a third-party framework like wxPython. Using tkinter is not compulsory. I'm new to tkinter and find tkdocs.com seems quite good. But tkdocs.com's Python code sample is in Python 3. And wxPython doesn't support Python 3 yet. ( May not be big issue but it's kind of bad. ) I observation about tkinter is that it seems lack of sophisticated features. For example, there is nothing like DataWindow in PowerBuilder? Python's IDLE is written in tkinter. But anyone willing to use IDLE is a successful example of tkinter? I actually use Gedit more than PyDev, etc. But the non-fancy state of IDLE does reflect something, I guess. In the case of VB and VFP, they aren't bothered by such issues because they're used to closed-source, proprietary programming where you use what you are given and like it. In the open-source world, if you don't like what you are given, you find something else, and if you can't find it, you make it yourself. I doesn't mean that choices are bad. I just kind of doubt that whether Python with a open source GUI toolkit can cover the features provided by VB standard controls and some external Windows built-in controls. I'm almost sure that tkinter lacks the features provided by sophisticated controls. I have limited knowledge to VFP. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
Steven D'Aprano writes: On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote: I wonder why floating-point errors are not routinely discussed in terms of ulps (units in last position). There is a recipe for calculating the difference of two floating point numbers in ulps, and it's possible to find the previous or next floating point number, but I don't know of any programming language having built-in support for these. ... But we now have IEEE 754, and C has conquered the universe, so it's reasonable for programming languages to offer an interface for accessing floating point objects in terms of ULPs. Especially for a language like Python, which only has a single float type. Yes, that's what I'm thinking, that there is now a ubiquitous floating point format or two, so the properties of the format could be used. I have a module that works with ULPs. I may clean it up and publish it. Would there be interest in seeing it in the standard library? Yes, please. There are some subtleties here also. Firstly, how many ULP should you care about? Three, as you suggest below, is awfully small, and chances are most practical, real-world calculations could not justify 3 ULP. Numbers that we normally care about, like 0.01mm, probably can justify thousands of ULP when it comes to C-doubles, which Python floats are. I suppose this depends on the complexity of the process and the amount of data that produced the numbers of interest. Many individual floating point operations are required to be within an ulp or two of the mathematically correct result, I think, and the rounding error when parsing a written representation of a number should be similar. Either these add up to produce large errors, or the computation is approximate in other ways in addition to using floating point. One could develop a kind of sense for such differences. Ulps could be a tangible measure when comparing different algorithms. (That's what I tried to do with them in the first place. And that's how I began to notice their absence when floating point errors are discussed.) Another subtlety: small-but-positive numbers are millions of ULP away from small-but-negative numbers. Also, there are issues to do with +0.0 and -0.0, NANs and the INFs. The usual suspects ^_^ and no reason to dismiss the ulp when the competing kinds of error have their corresponding subtleties. A matter of education, I'd say. Thank you much for an illuminating discussion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On 05/29/2013 04:30 AM, nagia.rets...@gmail.com wrote: What makes us o sure it is a pymysql issue and not python's encoding issue? The original traceback, which showed that the encoding error was happening in /opt/python3/lib/python3.3/site-packages/pymysql/cursors.py, line 108. As was said, you solve that by passing a charset=utf-8 to the connection string. So doing that solved the encoding problem (a query is now being successfully built and sent to mysql) and went on to expose another problem (bug) in your code, but I cannot tell what that is, since the error happened in a subprocess and the traceback got sent to /dev/null. I suspect is has something to do with how the query results are being returned, or it could have something to do with the query itself. Python DB API does not specify exactly which style of prepared statements should be used by a given third-party module. So differences in syntax between how pymysql and MysqlDB define the variables could be the problem. In any case your course is clear. Run pelatologio.py outside of your templating system and see what the traceback says exactly now that the charset issue is fixed. -- http://mail.python.org/mailman/listinfo/python-list
Can anyone please help me in understanding the following python code
Code :
-
def mergeSort(alist):
print(Splitting ,alist)
if len(alist)1:
mid = len(alist)//2
lefthalf = alist[:mid]
righthalf = alist[mid:]
mergeSort(lefthalf)
mergeSort(righthalf)
i=0
j=0
k=0
while ilen(lefthalf) and jlen(righthalf):
if lefthalf[i]righthalf[j]:
alist[k]=lefthalf[i]
i=i+1
else:
alist[k]=righthalf[j]
j=j+1
k=k+1
while ilen(lefthalf):
alist[k]=lefthalf[i]
i=i+1
k=k+1
while jlen(righthalf):
alist[k]=righthalf[j]
j=j+1
k=k+1
print(Merging ,alist)
alist = [54,26,93,17,77,31,44,55,20]
mergeSort(alist)
print(alist)
Output:
---
('Splitting ', [54, 26, 93, 17, 77, 31, 44, 55, 20])
('Splitting ', [54, 26, 93, 17])
('Splitting ', [54, 26])
('Splitting ', [54])
('Merging ', [54])
('Splitting ', [26])
('Merging ', [26])
('Merging ', [26, 54])
('Splitting ', [93, 17])
('Splitting ', [93])
('Merging ', [93])
('Splitting ', [17])
('Merging ', [17])
('Merging ', [17, 93])
('Merging ', [17, 26, 54, 93])
('Splitting ', [77, 31, 44, 55, 20])
('Splitting ', [77, 31])
('Splitting ', [77])
('Merging ', [77])
('Splitting ', [31])
('Merging ', [31])
('Merging ', [31, 77])
('Splitting ', [44, 55, 20])
('Splitting ', [44])
('Merging ', [44])
('Splitting ', [55, 20])
('Splitting ', [55])
('Merging ', [55])
('Splitting ', [20])
('Merging ', [20])
('Merging ', [20, 55])
('Merging ', [20, 44, 55])
('Merging ', [20, 31, 44, 55, 77])
('Merging ', [17, 20, 26, 31, 44, 54, 55, 77, 93])
[17, 20, 26, 31, 44, 54, 55, 77, 93]
Question:
-
Function mergeSort is called only once, but it is getting recursively executed
after the printing the last statement print(Merging ,alist). But don't
recursion taking place except at these places mergeSort(lefthalf),
mergeSort(righthalf)
Sometimes the function execution directly starts from i=0,j=0,k=0 . Not sure
how.
Can anyone please help me out here?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thu, May 30, 2013 at 7:48 PM, bhk...@gmail.com wrote: Function mergeSort is called only once, but it is getting recursively executed after the printing the last statement print(Merging ,alist). But don't recursion taking place except at these places mergeSort(lefthalf), mergeSort(righthalf) Sometimes the function execution directly starts from i=0,j=0,k=0 . Not sure how. When it says Splitting with a single-element list, it then immediately prints Merging and returns (because all the rest of the code is guarded by the 'if'). Execution then continues where it left off, in the parent. One good way to get an idea of what's going on is to add a recursion depth parameter. Keep all the rest of the code the same, but change the print and recursion lines to be like this: def mergeSort(alist,depth): print(%*cSplitting %r%(depth*2,' ',alist)) # ... mergeSort(lefthalf,depth+1) mergeSort(righthalf,depth+1) # ... print(%*cMerging %r%(depth*2,' ',alist)) mergeSort(alist,0) That'll indent everything according to the depth of the call stack. (Also, I changed your 'print's to be compatible with Python 2 and Python 3; you seemed to have Python 3 style function calls and a Python 2 interpreter.) Hopefully that'll make clearer what's going on! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
bhk755 at gmail.com writes: Function mergeSort is called only once, but it is getting recursively executed after the printing the last statement print(Merging ,alist). But don't recursion taking place except at these places mergeSort(lefthalf), mergeSort(righthalf) Sometimes the function execution directly starts from i=0,j=0,k=0 . Not sure how. Maybe you should tell us first what output you would have expected. It's not really clear from your question what confuses you. Doesn't the algorithm do what it's supposed to do? When does the function start from i=0, j=0, k=0 ? What exactly is the output then ? Maybe you are confused by the fact that the algorithm is recursive twice. It first goes through the lefthand branch, then only on its way out it works on the righthand branch. So the recursion through mergeSort is not started only once as you say, but twice (after finishing the recursion through mergeSort(lefthand), another recursion is kicked off by calling mergeSort(righthand). Best, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Thanks for the reply Chris. I am newbie to python, so please excuse me if I am asking chilly questions. Can you please explain more about the following sentence. When it says Splitting with a single-element list, it then immediately prints Merging and returns (because all the rest of the code is guarded by the 'if'). Execution then continues where it left off, in the parent. Because I am not sure how the control can go back to top of the function unless there is no loops there. Also, Can you please let me know how did you found out that I am using Python 2 Interpreter. Bharath -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
bhk755 at gmail.com writes: Thanks for the reply Chris. I am newbie to python, so please excuse me if I am asking chilly questions. Can you please explain more about the following sentence. When it says Splitting with a single-element list, it then immediately prints Merging and returns (because all the rest of the code is guarded by the 'if'). Execution then continues where it left off, in the parent. Because I am not sure how the control can go back to top of the function unless there is no loops there. It doesn't. The function simply returns and execution resumes in the parent, i.e. in the calling function at depth-1, where it left off. In Python, a return None is implied when a function falls off its end. Also, Can you please let me know how did you found out that I am using Python 2 Interpreter. print as a statement (without parentheses) only works in Python 2, in Python 3 print is a function. Bharath -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thu, May 30, 2013 at 8:19 PM, bhk...@gmail.com wrote:
Thanks for the reply Chris.
I am newbie to python, so please excuse me if I am asking chilly questions.
All questions are welcome!
Can you please explain more about the following sentence.
When it says Splitting with a single-element list, it then
immediately prints Merging and returns (because all the rest of the
code is guarded by the 'if'). Execution then continues where it left
off, in the parent.
The code goes like this:
1) Print Splitting
2) If there's more than one element in the list:
2a) Divide the list in half
2b) Call self on each half
2c) Merge
3) Print Merging
In step 2b, all the steps from 1 through 3 are executed again (twice).
Soon, those calls will just output Splitting followed by Merging;
and then we go back to 2c. That's why it *seems* that the code goes
from 3 to 2c. You'll notice that the call depth decreases when this
happens.
Because I am not sure how the control can go back to top of the function
unless there is no loops there.
Also, Can you please let me know how did you found out that I am using Python
2 Interpreter.
That one is actually based on my crystal ball. Here on python-list, we
issue them to all our top respondents; they're extremely useful. I'll
let you in on part of the secret of how this works, though.
In Python 2, 'print' is (by default) a statement. When you give it
something in parentheses, it sees a tuple:
print(Splitting ,alist)
('Splitting ', [54, 26, 93, 17, 77, 31, 44, 55, 20])
In Python 3, 'print' is a function. It takes arguments, and prints out
each argument, separated by spaces.
print(Splitting ,alist)
Splitting [17, 20, 26, 31, 44, 54, 55, 77, 93]
You can make Python 2 behave the same way by putting this at the top
of your program:
from __future__ import print_function
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
Τη Πέμπτη, 30 Μαΐου 2013 12:29:56 μ.μ. UTC+3, ο χρήστης Michael Torrie έγραψε: On 05/29/2013 04:30 AM, nagia.rets...@gmail.com wrote: What makes us o sure it is a pymysql issue and not python's encoding issue? The original traceback, which showed that the encoding error was happening in /opt/python3/lib/python3.3/site-packages/pymysql/cursors.py, line 108. As was said, you solve that by passing a charset=utf-8 to the connection string. So doing that solved the encoding problem (a query is now being successfully built and sent to mysql) and went on to expose another problem (bug) in your code, but I cannot tell what that is, since the error happened in a subprocess and the traceback got sent to /dev/null. I suspect is has something to do with how the query results are being returned, or it could have something to do with the query itself. Python DB API does not specify exactly which style of prepared statements should be used by a given third-party module. So differences in syntax between how pymysql and MysqlDB define the variables could be the problem. In any case your course is clear. Run pelatologio.py outside of your templating system and see what the traceback says exactly now that the charset issue is fixed. Good morning Michael, I'am afraid as much as you dont want to admin it that the moment i append the charset directive into the connections tring i receive a huge error which it can be displayed in: http://superhost.gr/cgi-bin/pelatologio.py This is run directly isolated form the templating system. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
Τη Πέμπτη, 30 Μαΐου 2013 1:53:33 μ.μ. UTC+3, ο χρήστης nagia@gmail.com
έγραψε:
Τη Πέμπτη, 30 Μαΐου 2013 12:29:56 μ.μ. UTC+3, ο χρήστης Michael Torrie έγραψε:
On 05/29/2013 04:30 AM, nagia.rets...@gmail.com wrote:
What makes us o sure it is a pymysql issue and not python's encoding
issue?
The original traceback, which showed that the encoding error was
happening in
/opt/python3/lib/python3.3/site-packages/pymysql/cursors.py, line 108.
As was said, you solve that by passing a charset=utf-8 to the
connection string.
So doing that solved the encoding problem (a query is now being
successfully built and sent to mysql) and went on to expose another
problem (bug) in your code, but I cannot tell what that is, since the
error happened in a subprocess and the traceback got sent to /dev/null.
I suspect is has something to do with how the query results are being
returned, or it could have something to do with the query itself.
Python DB API does not specify exactly which style of prepared
statements should be used by a given third-party module. So differences
in syntax between how pymysql and MysqlDB define the variables could be
the problem.
In any case your course is clear. Run pelatologio.py outside of your
templating system and see what the traceback says exactly now that the
charset issue is fixed.
Good morning Michael,
I'am afraid as much as you dont want to admin it that the moment i append the
charset directive into the connections tring i receive a huge error which it
can be displayed in:
http://superhost.gr/cgi-bin/pelatologio.py
This is run directly isolated form the templating system.
AttributeError: 'NoneType' object has no attribute 'id'
args = ('NoneType' object has no attribute 'id',)
with_traceback = built-in method with_traceback of AttributeError object
is the error while i have no id varibale just an 'ID' inside:
cur.execute('''SELECT ID FROM clients WHERE name = %s''', (name,) )
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On 30 May 2013 10:48, bhk...@gmail.com wrote:
Question:
-
Function mergeSort is called only once, but it is getting recursively
executed after the printing the last statement print(Merging ,alist). But
don't recursion taking place except at these places mergeSort(lefthalf),
mergeSort(righthalf)
Sometimes the function execution directly starts from i=0,j=0,k=0 . Not sure
how.
Here's some different code; it does the same thing but in a less weird way:
##
def mergeSort(alist, depth=1):
# If the piece we have to sort is [i] or [], then we have no sorting to do
if len(alist) = 1:
# Returning what we were given
# Make a new list from it, though, because we are nice
print({padding}return {list}\n.format(padding= *depth*8,
list=alist))
return alist[:]
# Split along the middle
mid = len(alist)//2
# We have two halves
lefthalf = alist[:mid]
righthalf = alist[mid:]
# Which we sort, so we have two sorted halves
print({padding}lefthalf = mergesort({list})\n.format(padding=
*depth*8, list=lefthalf))
lefthalf = mergeSort(lefthalf, depth+1)
print({padding}righthalf = mergesort({list})\n.format(padding=
*depth*8, list=righthalf))
righthalf = mergeSort(righthalf, depth+1)
# We want to return a sorted alist from our two lists
# We'll add the items to here
new_list = []
# We'll go through adding the smallest to new_list
while lefthalf and righthalf:
# Lefthalf has the smaller item, so we pop it off into new_list
if lefthalf[0] righthalf[0]:
new_list.append(lefthalf.pop(0))
# Righthalf has the smaller item, so we pop it off into new_list
else:
new_list.append(righthalf.pop(0))
# One of our lists isn't empty, so just add them on
new_list += lefthalf + righthalf
print({padding}return {list}\n.format(padding= *depth*8, list=new_list))
return new_list
print(Start mergesort({list}):\n.format(list=[2, 4, 0, 1]))
sorted_list = mergeSort([2, 4, 0, 1])
print(Our final result: {list}.format(list=sorted_list))
##
And it gives
##
Start mergesort([2, 4, 0, 1]):
lefthalf = mergesort([2, 4])
lefthalf = mergesort([2])
return [2]
righthalf = mergesort([4])
return [4]
return [2, 4]
righthalf = mergesort([0, 1])
lefthalf = mergesort([0])
return [0]
righthalf = mergesort([1])
return [1]
return [0, 1]
return [0, 1, 2, 4]
Our final result: [0, 1, 2, 4]
##
Hopefully this code is a little easier to understand - the original
changes the list while it is running the algorithm and mine makes new
lists. The algorithm is very similar, and what you learn applies to
both.
You can see in the output (thanks Chris Angelico) that the main
function is always running. It runs *two* other instances: lefthalf
and righthalf.
So the mergesort([2, 4, 0, 1]) runs lefthalf = mergesort([2, 4])
mergesort([2, 4]) runs lefthalf = mergesort([2])
mergesort([2]) gives back [2] to mergesort([2, 4])
mergesort([2, 4]) goes OH! I can continue now and runs righthalf
= mergesort([4])
mergesort([4]) gives back [4] to mergesort([2, 4])
mergesort([2, 4]) goes OH! I can continue now and gives back [2,
4] to mergesort([2, 4, 0, 1])
mergesort([2, 4, 0, 1]) goes OH! I can continue now and runs
righthalf = mergesort([0, 1])
mergesort([0, 1]) runs lefthalf = mergesort([0])
mergesort([0]) gives back [0] to mergesort([0, 1])
mergesort([0, 1]) goes OH! I can continue now and runs righthalf
= mergesort([1])
mergesort([1]) gives back [1] to mergesort([0, 1])
mergesort([0, 1]) goes OH! I can continue now and gives back [0,
1] to mergesort([2, 4, 0, 1])
mergesort([2, 4, 0, 1]) goes OH! I can continue now and gives back
[0, 1, 2, 4]
DONE.
Does that help you see the flow?
Exactly the same flow happens for your code. The difference is that
instead of returning a list, mergesort *sorts* a list, and then that
is used to replace items in the original list. Personally, their way
is a little silly (and mine is inefficient, so use neither).
Question: Why did you rewrite the code?
Answer: Revising is boring.
Question: Sometimes the function execution directly starts from
i=0,j=0,k=0 . Not sure how.
Answer: That's not a question. Anyhow:
i, j and k are LOCAL to a function. mergesort([2, 4, 0, 1]) has a
different i, j and k than mergesort([0, 1]), They never use each
other's i, j and k. Hence for each recursion they run i=0, j=0, k=0
and they are set to 0 within the function.
Does this help?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On 30 May 2013 11:19, bhk...@gmail.com wrote: Also, Can you please let me know how did you found out that I am using Python 2 Interpreter. Do you have access to a Python3 interpreter? If so, try running it and your output will look like: Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] Splitting [54, 26] Splitting [54] Merging [54] Splitting [26] Merging [26] ... BLAH BLAH BLAH Which is obviously much nicer. This is how Chris knew the code was written for Python3. Therefore I would suggest you use Python3 - not all code runs on both! The proper way to write the prints for Python2 is without the brackets: print Merging ,alist But the methods Chris and I have used work the same on both so are probably better in this case. They're more complicated, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On Thu, May 30, 2013 at 8:53 PM, nagia.rets...@gmail.com wrote: Good morning Michael, I'am afraid as much as you dont want to admin it that the moment i append the charset directive into the connections tring i receive a huge error which it can be displayed in: http://superhost.gr/cgi-bin/pelatologio.py This is run directly isolated form the templating system. Your valid character set names can be found here: https://github.com/petehunt/PyMySQL/blob/master/pymysql/charset.py I found this simply by googling 'pymysql' and working through the call tree. Find what you want. Use it. You can probably get this information from the docs, too. Read them. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
User Input
Hi, I'm having trouble oh how prompt the user to enter a file name and how to set up conditions. For example, if there's no file name input by the user, a default is returned -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30 May 2013 12:42, Eternaltheft eternalth...@gmail.com wrote:
Hi, I'm having trouble oh how prompt the user to enter a file name and
how to set up conditions. For example, if there's no file name input by the
user, a default is returned
Are you using raw_input? It returns an empty string if the user enters
nothing, so you can just use an if.
filename = raw_input('file name: ')
if not filename:
filename = 'your default'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
Τη Πέμπτη, 30 Μαΐου 2013 2:33:56 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: On Thu, May 30, 2013 at 8:53 PM, nagia.rets...@gmail.com wrote: Good morning Michael, I'am afraid as much as you dont want to admin it that the moment i append the charset directive into the connections tring i receive a huge error which it can be displayed in: http://superhost.gr/cgi-bin/pelatologio.py This is run directly isolated form the templating system. Your valid character set names can be found here: https://github.com/petehunt/PyMySQL/blob/master/pymysql/charset.py I found this simply by googling 'pymysql' and working through the call tree. Find what you want. Use it. You can probably get this information from the docs, too. Read them. ChrisA I cant fucking believe it. The moen i switched charset = 'utf-8' = charset = 'utf8' all started to work properly! Thank you very much Chris, i cnat belive i was lookign 3 days for that error and it was a matter of a dash removal.My God! -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On Thursday, May 30, 2013 7:33:41 PM UTC+8, Eternaltheft wrote: Hi, I'm having trouble oh how prompt the user to enter a file name and how to set up conditions. For example, if there's no file name input by the user, a default is returned Thanks for such a fast reply! and no im not using raw input, im just using input. does raw_input work on python 3? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On Thu, May 30, 2013 at 9:48 PM, Eternaltheft eternalth...@gmail.com wrote:
On Thursday, May 30, 2013 7:33:41 PM UTC+8, Eternaltheft wrote:
Hi, I'm having trouble oh how prompt the user to enter a file name and how
to set up conditions. For example, if there's no file name input by the
user, a default is returned
Thanks for such a fast reply! and no im not using raw input, im just using
input. does raw_input work on python 3?
No, on Python 3 just use input. In Python 2, input() is a dangerous
function that evaluates the entered text and raw_input() is the safe
one; in Python 3, raw_input got renamed to input(). Go ahead and use
input the way Fabio used raw_input.
By the way, there's a handy compact notation for what Fabio wrote:
filename = raw_input('file name: ') or 'your default'
Can be very handy!
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30/05/2013 12:48, Eternaltheft wrote: On Thursday, May 30, 2013 7:33:41 PM UTC+8, Eternaltheft wrote: Hi, I'm having trouble oh how prompt the user to enter a file name and how to set up conditions. For example, if there's no file name input by the user, a default is returned Thanks for such a fast reply! and no im not using raw input, im just using input. does raw_input work on python 3? In Python 2 it's called raw_input and in Python 3 it's called input. Python 2 does have a function called input, but it's not recommended (it's dangerous because it's equivalent to eval(raw_input()), which will evaluate _whatever_ is entered). -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30 May 2013 12:58, Eternaltheft eternalth...@gmail.com wrote: On Thursday, May 30, 2013 7:33:41 PM UTC+8, Eternaltheft wrote: Hi, I'm having trouble oh how prompt the user to enter a file name and how to set up conditions. For example, if there's no file name input by the user, a default is returned Thanks for such a fast reply! and no im not using raw input, im just using input. does raw_input work on python 3? On python 2, the function to prompt the user for input and return a string is raw_input. On python 3 that function has been renamed to input. However on python 2 input is something else. It also evaluates the input as a python expression. That makes it unsafe to use in most circumstances. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
Ok thanks guys. but when i use
filename = input('file name: ')
if not filename: #i get filename is not defined
return(drawBoard) #possible to return function when no file input from user?
--
http://mail.python.org/mailman/listinfo/python-list
Python toplevel in a Web page
Hello, I wonder if I can find some source code example of a Python 3 toplevel box in a Web page. Something simple, no mySQL, no Django hammer, etc. Just the basics of the technology to get the content of a small text editor in which the user writes some Python script, to be analyzed (eval'ed) then whose result is to be written in another text box. Simple, pythonistic. Thanks for the pointer, franck -- http://mail.python.org/mailman/listinfo/python-list
Re: MySQL dymanic query in Python
On Wednesday, May 29, 2013 3:32:51 PM UTC+5:30, Fábio Santos wrote: On 29 May 2013 10:13, RAHUL RAJ omrahu...@gmail.com wrote: Can anyone tell me the proper way in which I can execute dynamic MySQL queries in Python? I want to do dynamic queries for both CREATE and INSERT statement. Here is my attempted code: sql=create table %s (%%s, %%s, %%s ... ) % (tablename,''.join(fields)+' '.join(types)) cur.execute(sql) where 'field' is the fieldnames stored in a list and 'types' are the fieldtypes stored in a list. You need to join the fields and the field types. Use zip(). Then join with commas. fields_and_types = ['%s %s' % (field, type) for field, type in zip(fields, types)] what_goes_between_the_parens = ', '.join(fields_and_types) sql = 'create table %s (%s)' % (tablename, what_goes_between_the_parens) See where that gets you. Fantastic! It worked, Thanks :) -- http://mail.python.org/mailman/listinfo/python-list
Is this code correct?
#!/usr/bin/python3
# coding=utf-8
import cgitb; cgitb.enable()
import cgi, os, sys
from http import cookies
# initialize cookie
cookie = cookies.SimpleCookie( os.environ.get('HTTP_COOKIE') )
cookie.load( cookie )
nikos = cookie.get('nikos')
# if visitor cookie does exist
if nikos:
msg = ΑΠΟ ΤΗΝ ΕΠΟΜΕΝΗ ΕΠΙΣΚΕΨΗ ΣΟΥ ΘΑ ΣΕ ΥΠΟΛΟΓΙΖΩ ΩΣ ΕΠΙΣΚΕΠΤΗ
ΑΥΞΑΝΟΝΤΑΣ ΤΟΝ ΜΕΤΡΗΤΗ!
cookie['nikos'] = 'admin'
cookie['nikos']['path'] = '/'
cookie['nikos']['expires'] = -1 #this cookie will expire now
else:
msg = ΑΠΟ ΔΩ ΚΑΙ ΣΤΟ ΕΞΗΣ ΔΕΝ ΣΕ ΕΙΔΑ, ΔΕΝ ΣΕ ΞΕΡΩ, ΔΕΝ ΣΕ ΑΚΟΥΣΑ! ΘΑ
ΕΙΣΑΙ ΠΛΕΟΝ Ο ΑΟΡΑΤΟΣ ΕΠΙΣΚΕΠΤΗΣ!!
cookie['nikos'] = 'admin'
cookie['nikos']['path'] = '/'
cookie['nikos']['expires'] = 60*60*24*30*12 #this cookie
will expire in a year
#needed line, script does *not* work without it
sys.stdout = os.fdopen(1, 'w', encoding='utf-8')
print( cookie )
print ( Content-type: text/html; charset=utf-8\n )
print( msg )
sys.exit(0)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python teaching book recommendations: 3.3+ and with exercises
On Sat, May 4, 2013 at 12:54 AM, TP wing...@gmail.com wrote: Or maybe Think Python. A *lot* drier presentation than Python for Kids -- after all, the subtitle which I forgot to mention is How to Think Like a Computer Scientist. Newer than Summerfield , but only 1/3 the length . Since I've only skimmed both I find it hard to recommend one over the other. Many thanks to those who responded. A decision has been reached, and Think Python is being used. We'll see how it goes! I knew I could trust this list for good advice :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30 May 2013 13:24, Eternaltheft eternalth...@gmail.com wrote:
Ok thanks guys. but when i use
filename = input('file name: ')
if not filename: #i get filename is not defined
return(drawBoard) #possible to return function when no file input
from user?
I don't really understand what you mean. Do you mean that you're getting a
stack trace?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On Thu, May 30, 2013 at 10:25 PM, Νίκος Γκρ33κ supp...@superhost.gr wrote: #!/usr/bin/python3 # coding=utf-8 (chomp a whole lot of code without any indication of what it ought to do) Why not run it and see? If it does what it ought to, it's correct; if it does something different, it's not. Why do you expect us to do your basic testing for you? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On Thu, May 30, 2013 at 10:19 PM, Eternaltheft eternalth...@gmail.com wrote:
Ok thanks guys. but when i use
filename = input('file name: ')
if not filename: #i get filename is not defined
return(drawBoard) #possible to return function when no file input from
user?
Do you really want to return there? What function is this defined in?
I think you probably want what Fabio originally said: that if not
filename (which, in this context, means if the user hit Enter
without typing anything), assign something to filename.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log maybe it is correct but it wont run, perhaps somethign with linux? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
sorry about that, i got confused xD. yeah it works good now. what i meant to say was can i return a function that i made, if the user inputs nothing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Thanks Chris, Wolfgang and Joshua for your replies. --- In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output Splitting followed by Merging; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output Merging. Also, please look into the following output, before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] left half before split [44] right half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] left half before split [55] right half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] - In the above output, the control goes to HERE AFTER SPLIT after the Merging statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thursday, May 30, 2013 6:09:20 PM UTC+5:30, bhk...@gmail.com wrote: Thanks Chris, Wolfgang and Joshua for your replies. --- In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output Splitting followed by Merging; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output Merging. Also, please look into the following output for the same program with more print statements, -- before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] left half before split [44] right half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] left half before split [55] right half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] --- In the above output, the control goes to HERE AFTER SPLIT after the Merging statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
In article mailman.2395.1369891346.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: # Wrong, don't do this! x = 0.1 while x != 17.3: print(x) x += 0.1 Actually, I wouldn't do that with integers either. There are too many ways that a subsequent edit could get it wrong and go infinite, so I'd *always* use an inequality for that: x = 1 while x 173: print(x) x += 1 There's a big difference between these two. In the first case, using less-than instead of testing for equality, you are protecting against known and expected floating point behavior. In the second case, you're protecting against some vague, unknown, speculative future programming botch. So, what *is* the right behavior if somebody were to accidentally drop three zeros into the source code: x = 1000 while x 173: print(x) x += 1 should the loop just quietly not execute (which is what it will do here)? Will that make your program correct again, or will it simply turn this into a difficult to find bug? If you're really worried about that, why not: x = 1 while x != 173: assert 172 print(x) x += 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
In article qotk3mhx78l@ruuvi.it.helsinki.fi, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: I wonder why floating-point errors are not routinely discussed in terms of ulps (units in last position). Analysis of error is a complicated topic (and is much older than digital computers). These sorts of things come up in the real world, too. For example, let's say I have two stakes driven into the ground 1000 feet apart. One of them is near me and is my measurement datum. I want to drive a third stake which is 1001 feet away from the datum. Do I measure 1 foot from the second stake, or do I take out my super-long tape measure and measure 1001 feet from the datum? -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thursday, May 30, 2013 6:09:20 PM UTC+5:30, bhk...@gmail.com wrote: Thanks Chris, Wolfgang and Joshua for your replies. --- In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output Splitting followed by Merging; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output Merging. Also, please look into the following output for the same program with more print statements, -- before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] left half before split [44] right half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] left half before split [55] right half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] --- In the above output, the control goes to HERE AFTER SPLIT after the Merging statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 3:34:09 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: On Thu, May 30, 2013 at 10:25 PM, Νίκος Γκρ33κ supp...@superhost.gr wrote: #!/usr/bin/python3 # coding=utf-8 (chomp a whole lot of code without any indication of what it ought to do) Why not run it and see? If it does what it ought to, it's correct; if it does something different, it's not. Why do you expect us to do your basic testing for you? ChrisA But i cannot test it locally, i just write the code upload it on my remote server and run it from there. But h=this doenst seem to be a python issue, if it is ill correct it myself, it says somehtign about some suexec -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On Thu, May 30, 2013 at 10:39 PM, bhk...@gmail.com wrote: Chris, Can you please let me know what makes the control of the program code go to 2c after the output Merging. It goes like this: 1. [eight element list] 2a. [eight element list] 2b. 1. [four element list] 2b. 2a. [four element list] 2b. 2b.1. [two element list] 2b. 2b.2a. [two element list] 2b. 2b.2b. [two element list] 2b. 2b.2b.1. [one element list] 2b. 2b.2b.2. [one element list] 2b. 2b.2b.3. [one element list] 2b. 2b.2c. [two element list] 2b. 2b.3. [two element list] ... etc etc etc ... Notice how control actually flows from 1, to 2a, to 2b, to 2c, but in between, it goes back to 1? That's recursion. There are four separate function calls here, which you can see going down the page. Each time it gets to step 2b, a whole new thread starts, and the previous one doesn't do anything till the inner one reaches step 3 and finishes. That's why the indented output can help; eyeball them going down and you'll see that they don't do anything until the inner one finishes. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, May 30, 2013 at 10:40 PM, Roy Smith r...@panix.com wrote: if somebody were to accidentally drop three zeros into the source code: x = 1000 while x 173: print(x) x += 1 should the loop just quietly not execute (which is what it will do here)? Will that make your program correct again, or will it simply turn this into a difficult to find bug? If you're really worried about that, why not: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 05/30/2013 08:37 AM, Eternaltheft wrote:
sorry about that, i got confused xD. yeah it works good now.
what i meant to say was can i return a function that i made, if the user inputs
nothing?
There wouldn't be anything to stop you. However, if you have multiple
returns from the same function, it's usually wise to return the same
type of information from each of them. That's why Chris suggested
simply assigning to filename in the if clause.
But without the whole function, and maybe even a description of what the
function is expected to do, we can only guess.
Your comments still make no sense to me,
filename = input('file name: ')
if not filename: #i get filename is not defined
But filename IS defined, immediately above. If it were undefined, you'd
not be able to test it here. Big difference between not defined and
is empty string.
return(drawBoard) #possible to return function when no file input
from user?
If drawBoard is a function object, it's certainly possible to return it.
But again, without seeing the rest of the function, and maybe how it's
intended to be used, I can't confirm whether it makes sense.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
Thanks Chris, Wolfgang and Joshua for your replies. In step 2b, all the steps from 1 through 3 are executed again (twice). Soon, those calls will just output Splitting followed by Merging; and then we go back to 2c. That's why it *seems* that the code goes from 3 to 2c. You'll notice that the call depth decreases when this happens Chris, Can you please let me know what makes the control of the program code go to 2c after the output Merging. Also, please look into the following output for the same program with more print statements, -- before calling main mergesort Splitting [54, 26, 93, 17, 77, 31, 44, 55, 20] left half before split [54, 26, 93, 17] right half before split [77, 31, 44, 55, 20] Splitting [54, 26, 93, 17] left half before split [54, 26] right half before split [93, 17] Splitting [54, 26] left half before split [54] right half before split [26] Splitting [54] Merging [54] Splitting [26] Merging [26] HERE AFTER SPLIT left half after split [54] right half after split [26] Merging [26, 54] Splitting [93, 17] left half before split [93] right half before split [17] Splitting [93] Merging [93] Splitting [17] Merging [17] HERE AFTER SPLIT left half after split [93] right half after split [17] Merging [17, 93] HERE AFTER SPLIT left half after split [26, 54] right half after split [17, 93] Merging [17, 26, 54, 93] Splitting [77, 31, 44, 55, 20] left half before split [77, 31] right half before split [44, 55, 20] Splitting [77, 31] left half before split [77] right half before split [31] Splitting [77] Merging [77] Splitting [31] Merging [31] HERE AFTER SPLIT left half after split [77] right half after split [31] Merging [31, 77] Splitting [44, 55, 20] ft half before split [44] ght half before split [55, 20] Splitting [44] Merging [44] Splitting [55, 20] eft half before split [55] ight half before split [20] Splitting [55] Merging [55] Splitting [20] Merging [20] HERE AFTER SPLIT left half after split [55] right half after split [20] Merging [20, 55] HERE AFTER SPLIT left half after split [44] right half after split [20, 55] Merging [20, 44, 55] HERE AFTER SPLIT left half after split [31, 77] right half after split [20, 44, 55] Merging [20, 31, 44, 55, 77] HERE AFTER SPLIT left half after split [17, 26, 54, 93] right half after split [20, 31, 44, 55, 77] Merging [17, 20, 26, 31, 44, 54, 55, 77, 93] after calling main mergesort [17, 20, 26, 31, 44, 54, 55, 77, 93] --- In the above output, the control goes to HERE AFTER SPLIT after the Merging statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On Thu, May 30, 2013 at 10:31 PM, Νίκος Γκρ33κ supp...@superhost.gr wrote: This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log maybe it is correct but it wont run, perhaps somethign with linux? I don't know, why not ask on a Linux mailing list? Or have you run them out of patience too? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
yeah i found out why it wasn't defined before because i tried to put it into a function. this is my drawBoard function: import turtle as Turtle Turtle.title(Checkers) b = 75 def drawBoard(b): Turtle.speed(0) Turtle.up() Turtle.goto(-4 * b, 4 * b) Turtle.down() for i in range (8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b*2) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) drawBoard(b) Turtle.done() it draws an 8x8 board table. what i initially wanted to do was to return this function if nothing was inputted from the user. i hope that makes more sense :S -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On Thu, May 30, 2013 at 10:37 PM, Eternaltheft eternalth...@gmail.com wrote: sorry about that, i got confused xD. yeah it works good now. what i meant to say was can i return a function that i made, if the user inputs nothing? Sure! Anything you want to do, you can do :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 3:59:21 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: On Thu, May 30, 2013 at 10:31 PM, Νίκος Γκρ33κ supp...@superhost.gr wrote: This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log maybe it is correct but it wont run, perhaps somethign with linux? I don't know, why not ask on a Linux mailing list? Or have you run them out of patience too? ChrisA I though you guys might know because you do linux as well. i tried chown nikos:nikos ./koukos.py but doenst do the job either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On 30/05/2013 13:31, Νίκος Γκρ33κ wrote: This is my last question, everythign else is taken care of. i cant test thjis coe online because i receive this [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] suexec failure: could not open log file [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] fopen: Permission denied [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] Premature end of script headers: koukos.py [Thu May 30 15:29:33 2013] [error] [client 46.12.46.11] File does not exist: /home/nikos/public_html/500.shtml when i tail -F /usr/local/apache/logs/error_log maybe it is correct but it wont run, perhaps somethign with linux? Please ask questions unrelated to Python on a list that is unrelated to Python. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Can anyone please help me in understanding the following python code
On 05/30/2013 08:42 AM, bhk...@gmail.com wrote: SNIP lots of double-spaced googlegroups nonsense. Please read this http://wiki.python.org/moin/GoogleGroupsPython In the above output, the control goes to HERE AFTER SPLIT after the Merging statement which is of-course the last statement in the function.On what condition this is happening. Ideally as per my understanding, after the last statement of a function the control should come out of the function. Please correct me if I am wrong here. There is something with respect-to functions in python that I am not able to understand. I think you misunderstand recursion. And you should study it in a simpler example before trying to tackle that sort function. After the last statement of a function, or after an explicit return statement, the function does indeed return control to whoever called it. And if the call was in the middle of some other function, that's the place where execution will continue. Functions may nest this way to pretty large depths of complexity. If you're not sure you understand that, we should stop here. So in your reply, tell me if you can readily grasp function dfunc() calling cfunc(), which calls bfunc(), which calls afunc(). When afunc() returns, you'll be right in the middle of bfunc(), right after the call was made. Now to recursion. One can write a function which solves a particular problem by doing some of the work, but by calling on other functions which solve simpler subproblems. Recursion comes in when those other functions are simply instances of the same one. So instead of dfunc() calling cfunc(), we have rfunc() calling rfunc() calling rfunc() calling rfunc(). Let's take a classic problem for explaining recursion: factorial. We can write a simple function that solves the problem for 0: def afunc(n): if n == 0: return 1 else: throw-some-exception Silly function, I know. Now let's write one that solves it for one. def bfunc(n): if n == 1: return 1 * afunc(n-1) else: throw-some-exception Now for two: def bfunc(n): if n == 2: return 2 * bfunc(n-1) else: throw-some-exception Notice that each function calls the one above it to solve the simpler problem. Now if we wanted this to work for n=100, it would get really tedious. So let's see if we can write one function that handles all of these cases. def rfunc(n): if n == 0: return 1 else: return n * rfunc(n-1) Now if we call this with n==3, it'll make the zero check, then it'll call another function with the value 2. that one will in turn call another function with the value 1. And so on. So this function calls itself, as we say recursively. Now, for this simple case, we could have used a simple loop, or just called the library function. But it's a simple enough example to follow in its entirety (if I've been clear in my writing). Your mergeSort() function calls itself recursively, and each time it does, it passes a *smaller* list to be sorted. Eventually the calls recurse down to a list of size 1, which is already sorted by definition. The check for that is the line if len(alist)1: near the beginning of the function. That's analogous to my if n==0 line, although to match it most directly, I could have reversed the if/else and written the test as if n!=0 Chris showed you how to change your output so you could see the nesting levels. I have done that sort of thing in the past, and found it very useful. But first you have to understand nested functions, and simple recursion. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 4:05:00 μ.μ. UTC+3, ο χρήστης Mark Lawrence έγραψε: Please ask questions unrelated to Python on a list that is unrelated to Python. Okey, i will. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
On Thu, May 30, 2013 at 11:05 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Please ask questions unrelated to Python on a list that is unrelated to Python. Lemme guess, he's next going to ask on the PostgreSQL mailing list. I mean, that's unrelated to Python, right? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 05/30/2013 09:10 AM, Eternaltheft wrote: yeah i found out why it wasn't defined before because i tried to put it into a function. That's not a sentence, and it doesn't make sense in any permutation I can do on it. this is my drawBoard function: import turtle as Turtle Turtle.title(Checkers) b = 75 def drawBoard(b): Turtle.speed(0) Turtle.up() Turtle.goto(-4 * b, 4 * b) Turtle.down() for i in range (8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b*2) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) for i in range(1): Turtle.left(90) Turtle.forward(b) Turtle.left(90) for i in range (8): Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) Turtle.left(90) Turtle.forward(b) for i in range (1): Turtle.right(90) Turtle.forward(b) Turtle.right(90) for i in range(8): Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) Turtle.right(90) Turtle.forward(b) drawBoard(b) Turtle.done() it draws an 8x8 board table. what i initially wanted to do was to return this function if nothing was inputted from the user. i hope that makes more sense :S It makes sense if you're also returning a function object when the user does have something to say. But I can't see how you might be doing that, unless you're using a lambda to make up a custom function object. And you still don't show us the function that contains this input statement. Nor how it gets used. Is the user supposed to supply a value for b, and you put it in a variable called filename ? And perhaps you meant for your function to CALL drawBoard(), rather than returning the function object drawBoard. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this code correct?
Τη Πέμπτη, 30 Μαΐου 2013 4:36:11 μ.μ. UTC+3, ο χρήστης Chris Angelico έγραψε: Lemme guess, he's next going to ask on the PostgreSQL mailing list. I mean, that's unrelated to Python, right? Well Chris, i'am not that stupid :) I intend to ask questions unrelated to Python to a list unrelated to Python but related to my subject, whish is 'suexec', that would mean a linux list. -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
do you think ti would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30/05/2013 15:03, Eternaltheft wrote: do you think ti would be better if i call drawBoard? How would I know if you don't quote any context? -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On 05/30/2013 05:47 AM, Νίκος Γκρ33κ wrote: The moen i switched charset = 'utf-8' = charset = 'utf8' all started to work properly! Glad you have it working. Perhaps this should be a lesson to you, Nick. Chris was able to spot your problem by READING THE DOCUMENTATION, which he probably found through some quick searching on Google. These are things you can and should do too. As well as looking at the source code of the modules you may have downloaded and are using, and understanding how the code works (or fits together) and how to debug. You seem to have a tendency to try to attack your problems with rather blunt instruments, and then come to the list where one of the list members invariable does the footwork for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On Fri, May 31, 2013 at 12:35 AM, Michael Torrie torr...@gmail.com wrote: On 05/30/2013 05:47 AM, Νίκος Γκρ33κ wrote: The moen i switched charset = 'utf-8' = charset = 'utf8' all started to work properly! Glad you have it working. Perhaps this should be a lesson to you, Nick. Chris was able to spot your problem by READING THE DOCUMENTATION, which he probably found through some quick searching on Google. These are things you can and should do too. As well as looking at the source code of the modules you may have downloaded and are using, and understanding how the code works (or fits together) and how to debug. Well, actually I didn't find the documentation when I did those quick web searches, which is why I ended up looking at the source. That probably doubled the time requirement, and roughly doubled the minimum skill points to cast this spell (programming is an RPG, right?), but if he's actively using the module, he probably knows where to find its docs. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
And perhaps you meant for your function to CALL drawBoard(), rather than returning the function object drawBoard. DaveA do you think it would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
And perhaps you meant for your function to CALL drawBoard(), rather than returning the function object drawBoard. DaveA do you think it would be better if i call drawBoard? -- http://mail.python.org/mailman/listinfo/python-list
Re: User Input
On 30 May 2013 15:47, Eternaltheft eternalth...@gmail.com wrote: And perhaps you meant for your function to CALL drawBoard(), rather than returning the function object drawBoard. DaveA do you think it would be better if i call drawBoard? Please read http://www.catb.org/esr/faqs/smart-questions.html, or anything similar you can find. Start from the beginning. 1) What are you doing? Not what are you doing now but, from the top, what is the goal you are trying to achieve? 2) How have you tried to do it? Code would be nice here too, but don't just send really large blocks of irrelevant code. For example, your drawBoard function would be better surmised as: def drawBoard(b): Turtle.speed(0) Turtle.up() Turtle.goto(-4 * b, 4 * b) Turtle.down() for i in range (8): Turtle.forward(b) Turtle.right(90) ... # etc, drawing a board 3) What are you stuck on? In this case, you are stuck on what to do after you call input(stuff), if I understand. What do you want to do - not how do you want to do it but what is it that you are doing? 4) Finally, we should understand what calling drawBoard is for. Ask us again and we'll be much more likely to give good answers. -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pyknon: Simple Python library to generate music in a hacker friendly way.
Thanks a lot, Sir. Just what I was looking for. This is a fantastic library for python. -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of pySerial
On 30/05/2013 02:32, Ma Xiaojun wrote: I've already mailed the author, waiting for reply. For Windows people, downloading a exe get you pySerial 2.5, which list_ports and miniterm feature seems not included. To use 2.6, download the tar.gz and use standard setup.py install to install it (assume you have .py associated) . There is no C compiling involved in the installation process. For whether Python 3.3 is supported or not. I observed something like: http://paste.ubuntu.com/5715275/ . miniterm works for Python 3.3 at this time. The problem there is that 'desc' is a bytestring, but the regex pattern can match only a Unicode string (Python 3 doesn't let you mix bytestrings and Unicode string like a Python 2). The simplest fix would probably be to decode 'desc' to Unicode. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/30/2013 05:58 AM, Chris Angelico wrote: On Thu, May 30, 2013 at 10:40 PM, Roy Smith r...@panix.com wrote: if somebody were to accidentally drop three zeros into the source code: x = 1000 while x 173: print(x) x += 1 should the loop just quietly not execute (which is what it will do here)? Will that make your program correct again, or will it simply turn this into a difficult to find bug? If you're really worried about that, why not: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the far, far worse scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 1:02 AM, Ethan Furman et...@stoneleaf.us wrote: On 05/30/2013 05:58 AM, Chris Angelico wrote: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the far, far worse scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Doing nothing is much safer than getting stuck in an infinite loop. And yes, I have done exactly that, though not in Python. Don't forget, your start/stop figures mightn't be constants, so you might not see it in testing. I can't imagine ANY scenario where you'd actually *want* the infinite loop behaviour, while there are plenty where you want it to skip the loop, and would otherwise have to guard it with an if. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: On Fri, May 31, 2013 at 1:02 AM, Ethan Furman et...@stoneleaf.us wrote: On 05/30/2013 05:58 AM, Chris Angelico wrote: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the far, far worse scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Then more fool you for editing live code. By the way, this is Python. Editing live code is not easy, if it's possible at all. But even when possible, it's certainly not sensible. You don't insist on your car mechanic giving your car a grease and oil change while you're driving at 100kmh down the freeway, and you shouldn't insist that your developers modify your code while it runs. In any case, your arguing about such abstract, hypothetical ideas that, frankly, *anything at all* might be said about it. What if Ctrl-C causes some great disaster? can be answered with an equally hypothetical What if Ctrl-C prevents some great disaster? Doing nothing is much safer than getting stuck in an infinite loop. I disagree. And I agree. It all depends on the circumstances. But, given that we are talking about Python where infinite loops can be trivially broken out of, *in my experience* they are less-worse than silently doing nothing. I've occasionally written faulty code that enters an infinite loop. When that happens, it's normally pretty obvious: something which should complete in a millisecond is still running after ten minutes. That's a clear, obvious, *immediate* sign that I've screwed up, which leads to me fixing the problem. On the other hand, I've occasionally written faulty code that does nothing at all. The specific incident I am thinking of, I wrote a bunch of doctests which *weren't being run at all*. For nearly two weeks (not full time, but elapsed time) I was developing this code, before I started to get suspicious that *none* of the tests had failed, not even once. I mean, I'm not that good a programmer. Eventually I put in some deliberate errors, and they still didn't fail. In actuality, nearly every test was failing, my entire code base was rubbish, and I just didn't know it. So, in this specific case, I would have *much* preferred an obvious failure (such as an infinite loop) than code that silently does the wrong thing. We've drifted far from the original topic. There is a distinct difference between guarding against inaccuracies in floating point calculations: # Don't do this! total = 0.0 while total != 1.0: total += 0.1 and guarding against typos in source code: total = 90 # Oops, I meant 0 while total != 10: total += 1 The second case is avoidable by paying attention when you code. The first case is not easily avoidable, because it reflects a fundamental difficulty with floating point types. As a general rule, defensive coding does not extend to the idea of defending against mistakes in your code. The compiler, linter or unit tests are supposed to do that. Occasionally, I will code defensively when initialising tedious data sets: prefixes = ['y', 'z', 'a', 'f', 'p', 'n', 'µ', 'm', 'k', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y'] assert len(prefixes) == 16 but that's about as far as I go. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
suppose I now want the app natively on my phone (because that's all the rage). It's an iPhone. Oh. Apple doesn't support Python. Okay, rewrite the works, including business logic, in Objective C. Now I want it on my android phone. Those are gadgets, not work tools. As a professional programmer I'm afraid you're going to soon find yourself out of work if you really see things that way. As a domain expert, I come from the end-user side of enterprise applications and again; those are not tools for screenworkers to get actual work done, but consumer crap for fad-driven gadget-addicted kids (regardless of nominal age). I honestly used to feel that way about graphical user interfaces. A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Google App Engine dev_appserver and pdb?
Is there a way to use pdb to debug Google apps written in Python? When I start the development system to run the app test like this - './google_appengine/dev_appserver.py' './test' - I'd like to send the program into debug. I couldn't see anything in the documentation how to do this. If I do this - python -mpdb './google_appengine/dev_appserver.py' './test' - then dev_appserver.py goes into debug but doesn't know anything about test. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
On Fri, May 31, 2013 at 2:40 AM, Wolfgang Keller felip...@gmx.net wrote: A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). My ten fingers stay on my keyboard, which looks somewhat thus: http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg See the red dot in the middle? Mouse. See the keys all around it? My hands are all over that. I can casually mouse and keyboard at the same time. Doesn't bother me. THIS is a professional programmer's workspace. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On May 30, 5:58 pm, Chris Angelico ros...@gmail.com wrote: The alternative would be an infinite number of iterations, which is far far worse. There was one heavyweight among programming teachers -- E.W. Dijkstra -- who had some rather extreme views on this. He taught that when writing a loop of the form i = 0 while i n: some code i += 1 one should write the loop test as i != n rather than i n, precisely because if i got erroneously initialized to some value greater than n, (and thereby broke the loop invariant), it would loop infinitely rather than stop with a wrong result. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 05/30/2013 08:56 AM, Chris Angelico wrote: On Fri, May 31, 2013 at 1:02 AM, Ethan Furman et...@stoneleaf.us wrote: On 05/30/2013 05:58 AM, Chris Angelico wrote: If you iterate from 1000 to 173, you get nowhere. This is the expected behaviour; this is what a C-style for loop would be written as, it's what range() does, it's the normal thing. Going from a particular starting point to a particular ending point that's earlier than the start results in no iterations. The alternative would be an infinite number of iterations, which is far far worse. If the bug is the extra three zeros (maybe it should have been two), then silently skipping the loop is the far, far worse scenario. With the infinite loop you at least know something went wrong, and you know it pretty darn quick (since you are testing, right? ;). You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Doing nothing is much safer than getting stuck in an infinite loop. And yes, I have done exactly that, though not in Python. Don't forget, your start/stop figures mightn't be constants, so you might not see it in testing. I can't imagine ANY scenario where you'd actually *want* the infinite loop behaviour, while there are plenty where you want it to skip the loop, and would otherwise have to guard it with an if. We're not talking about skipping the loop on purpose, but on accident. Sure, taking a system down is no fun -- on the other hand, how much data corruption can occur before somebody realises there's a problem, and then how long to track it down to a silently, accidently, skipped loop? -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On 05/30/2013 08:40 AM, Chris Angelico wrote: but if he's actively using the module, he probably knows where to find its docs. One would hope, but alas one probably hopes in vain. I'm not sure he wants to spend the time to read the code he's using and understand. He's in too much of a hurry to simply get a result. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun damage3...@gmail.com wrote: On Thu, May 30, 2013 at 10:49 AM, rusi rustompm...@gmail.com wrote: Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) def mktable(m,n): return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)] def prettyrow(r): return joinw(['%d*%d=%d' % ele for ele in r],'\t') def prettytable(t): return joinw([prettyrow(r) for r in t],'\n') Wait a minute! Isn't the most nature way of doing/thinking generating 9x9 multiplication table two nested loop? Thats like saying that the most natur(al) way of using a car is to attach a horse to it. Sure if all you've seen are horse-carriages then a horseless carriage will seem nonsensical. Once you get used to horseless carriages the horsed ones would seem quite a nuisance [global warming aside!!] The only problem with this analogy is that you have to imagine the world of horse/horseless 'cars' in 1900 and not 2013. Likewise in the world of programming, 90% of programmers think imperative/OO programming is natural while functional programming is strange. Just wait 10 years and see if things are not drastically different! I understand that using join, we don't need to worry about one element doesn't need white space issue. And that's it. More evidence of the above! join like list-comprehensions are tools for functional programming and not merely ways of writing loops in short. The key difference between the two is seen not in the code you write but in the natural language (English) you use to describe it: Wait a minute! Isn't the most nature way of doing/thinking generating 9x9 multiplication table two nested loop? You associate the primal (f)act of thinking about programming with *doing* the generating. By contrast the functional programmer thinks about what *is* the result. Please also note the difference in emphasis in your code and mine. Rewriting to make it more obvious: # The main multiplication table building function def multtable(m,n): return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)] # The 'icing' to get it into the shape you want def joinw(l,sep): return sep.join(l) def prettytable(t): return joinw([joinw(['%d*%d=%d' % ele for ele in r],'\t') for r in t],'\n') The call that puts them together: print prettytable(multtable(6,7)) The nice thing about the last is that it separates three things: 1. Computing the actual table 2. The string form of that table that looks the way we want 3. Printing that string And I can see each of these separately: In [2]: multtable(2,3) Out[2]: [[(1, 1, 1), (1, 2, 2)], [(2, 1, 2), (2, 2, 4)], [(3, 1, 3), (3, 2, 6)]] In [3]: prettytable(_) Out[3]: '1*1=1\t1*2=2\n2*1=2\t2*2=4\n3*1=3\t3*2=6' In [4]: print _ 1*1=1 1*2=2 2*1=2 2*2=4 3*1=3 3*2=6 --- I would be pleasantly surprised if the double nested loop you think natural, allowed for such a modular separation! -- http://mail.python.org/mailman/listinfo/python-list
THRINAXODON BURTS AN AXON!
THRINAXODON HAS JUST ENTERED THE WORLD OF REASON-RALLY. SUCH WILD BEASTS AS PETER NYIKOS, PZ MYERS, RICHARD DAWKINS, DR. EVIL, JOHN S. WILKINS, JERRY COYNE, MARK ISAAK, SKYEYES, BUDIKKA666, FIDEL TUBARE, SBAELNAVE, BOB CASANOVA, JOHN HARSHMAN, DAVID IAIN GREIG, AND JILLERY WERE THERE. THEY WERE MISREPRESENTING, AND DISTORTING THE TRUTH!!! THRINAXODON REPORTS THIS LIVE. == Thrinaxodon scaring this guy, to DEATH. http://www.youtube.com/watch?v=9Zlzin6PIo8 == Thrinaxodon, in the form of prion, infecting this person's temporal lobe, and causing DEATH SLOWLY http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/CJD_spongios... ___ ___ YE EVILUTIONISTS, THEY INFECT THE SOUL AND GIVE YOU NIGHTMARES. THEY GIVE YOU... EVVVOOLUTIONISTS DESEASE! ___ _ PROOF OF LIFE AFTER DEATH http://media.tumblr.com/tumblr_lxlws5u4tE1qjlz5q.jpg ___ __ === = THRINAXODON KILLS A RABBIT WITH A COUPLE OTHER PEOPLE http://upload.wikimedia.org/wikipedia/commons/7/74/La_Chasse_au_furet... === -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Fri, May 31, 2013 at 2:58 AM, rusi rustompm...@gmail.com wrote: On May 30, 5:58 pm, Chris Angelico ros...@gmail.com wrote: The alternative would be an infinite number of iterations, which is far far worse. There was one heavyweight among programming teachers -- E.W. Dijkstra -- who had some rather extreme views on this. He taught that when writing a loop of the form i = 0 while i n: some code i += 1 one should write the loop test as i != n rather than i n, precisely because if i got erroneously initialized to some value greater than n, (and thereby broke the loop invariant), it would loop infinitely rather than stop with a wrong result. And do you agree or disagree with him? :) I disagree with Dijkstra on a number of points, and this might be one of them. When you consider that the obvious Pythonic version of that code: for i in range(n,m): some code loops over nothing and does not go into an infinite loop (or throw an exception) when n = m, you have to at least acknowledge that I'm in agreement with Python core code here :) That doesn't mean it's right, of course, but it's at least a viewpoint that someone has seen fit to enshrine in important core functionality. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:12 AM, rusi rustompm...@gmail.com wrote:
You associate the primal (f)act of thinking about programming with
*doing* the generating.
By contrast the functional programmer thinks about what *is* the
result.
I wish you'd explain that to my boss :) He often has trouble
understanding why sometimes I put two syntactic statements on one
line, such as:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
In Python, that would probably be done with a list comprehension or
some other form of filtered iteration, and is to my mind a single
operation - iterate over all the marked foo is just as much a valid
loop header as iterate over all the foo. This is a simple example,
and what you say about thinking about what *is* the result doesn't
really translate well into a C++ example, but the broader concept
applies: there's a difference between code as the compiler/interpreter
sees it and code as the programmer sees it, and there is not always a
1:1 correspondence of statements.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Encodign issue in Python 3.3.1 (once again)
On Fri, May 31, 2013 at 3:01 AM, Michael Torrie torr...@gmail.com wrote: On 05/30/2013 08:40 AM, Chris Angelico wrote: but if he's actively using the module, he probably knows where to find its docs. One would hope, but alas one probably hopes in vain. I'm not sure he wants to spend the time to read the code he's using and understand. He's in too much of a hurry to simply get a result. Wonder how much less exciting this mailing list would be if he switched to decaf... *ducks for cover* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 1:28 AM, Chris Angelico ros...@gmail.com wrote:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
This is interesting!
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:46 AM, Ma Xiaojun damage3...@gmail.com wrote:
On Fri, May 31, 2013 at 1:28 AM, Chris Angelico ros...@gmail.com wrote:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
This is interesting!
Yeah, but that's C++. It won't work in Python without this directive:
from __future__ import braces
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
usage of os.posix_fadvise
Antoine Pitrou wrote:
Hi,
Wolfgang Maier wolfgang.maier at biologie.uni-freiburg.de writes:
Dear all,
I was just experimenting for the first time with os.posix_fadvise(), which
is new in Python3.3 . I'm reading from a really huge file (several GB) and I
want to use the data only once, so I don't want OS-level page caching. I
tried os.posix_fadvise with the os.POSIX_FADV_NOREUSE and with the
os.POSIX_FADV_DONTNEED flags, but neither seemed to have any effect on the
caching behaviour of Ubuntu (still uses all available memory to page cache
my I/O).
Specifically, I was trying this:
import os
fd = os.open('myfile', os.O_RDONLY)
# wasn't sure about the len parameter in fadvise,
# so thought I just use it on the first 4GB
os.posix_fadvise(fd, 0, 40, os.POSIX_FADV_NOREUSE) # or DONTNEED
The Linux version of man posix_fadvise probably holds the answer:
In kernels before 2.6.18, POSIX_FADV_NOREUSE had the same semantics
as POSIX_FADV_WILLNEED. This was probably a bug; since kernel
2.6.18, this flag is a no-op.
POSIX_FADV_DONTNEED attempts to free cached pages associated with the
specified region. This is useful, for example, while streaming large
files. A program may periodically request the kernel to free cached
data that has already been used, so that more useful cached pages are
not discarded instead.
So, in summary:
- POSIX_FADV_NOREUSE doesn't do anything on (modern) Linux kernels
- POSIX_FADV_DONTNEED must be called *after* you are done with a range of
data, not before you read it (note that I haven't tested to confirm it :-))
Regards
Antoine.
Hi Antoine,
you're right and thanks a lot for this great piece of information.
The following quick check works like a charm now:
fo = open('myfile', 'rb')
chunk_size = 16184
last_flush = 0
d = fo.read(chunk_size)
pos = chunk_size
while d:
... d = fo.read(chunk_size)
... pos += chunk_size
... if pos 20:
... print ('another 2GB read, flushing')
... os.posix_fadvise(fo.fileno(), last_flush, last_flush+pos,
os.POSIX_FADV_DONTNEED)
... last_flush += pos
... pos = 0
With this page caching for my huge file (30 GB in that case) still occurs,
of course, but it never occupies more than 2 GB of memory. This way it
should interfere less with cached data of other applications.
Have to test carefully how much that improves overall performance of the
system, but for the moment I'm more than happy!
Best wishes,
Wolfgang
P.S.: Maybe these new os module features could use a bit more documentation?
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 10:28 pm, Chris Angelico ros...@gmail.com wrote:
On Fri, May 31, 2013 at 3:12 AM, rusi rustompm...@gmail.com wrote:
You associate the primal (f)act of thinking about programming with
*doing* the generating.
By contrast the functional programmer thinks about what *is* the
result.
I wish you'd explain that to my boss :) He often has trouble
understanding why sometimes I put two syntactic statements on one
line, such as:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
In Python, that would probably be done with a list comprehension or
some other form of filtered iteration, and is to my mind a single
operation - iterate over all the marked foo is just as much a valid
loop header as iterate over all the foo. This is a simple example,
and what you say about thinking about what *is* the result doesn't
really translate well into a C++ example, but the broader concept
applies: there's a difference between code as the compiler/interpreter
sees it and code as the programmer sees it, and there is not always a
1:1 correspondence of statements.
ChrisA
I had a blog post about line-length in programs
http://blog.languager.org/2012/10/layout-imperative-in-functional.html
followed by an interesting discussion on the haskell mailing list
http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec
The comment by Alexander Solla was insightful and is probably what you
are saying.
[Probably!! I am not sure what you are saying!]
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
functional VS imperative? mechanical thinking VS mathematical thinking? Sounds interesting. -- http://mail.python.org/mailman/listinfo/python-list
Python and GIL
Hi, Can somebody explain to me how would you proceed in releasing the GIL and whether you think it will have consequences? Thanks Ana -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:59 AM, rusi rustompm...@gmail.com wrote:
On May 30, 10:28 pm, Chris Angelico ros...@gmail.com wrote:
On Fri, May 31, 2013 at 3:12 AM, rusi rustompm...@gmail.com wrote:
You associate the primal (f)act of thinking about programming with
*doing* the generating.
By contrast the functional programmer thinks about what *is* the
result.
I wish you'd explain that to my boss :) He often has trouble
understanding why sometimes I put two syntactic statements on one
line, such as:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
In Python, that would probably be done with a list comprehension or
some other form of filtered iteration, and is to my mind a single
operation - iterate over all the marked foo is just as much a valid
loop header as iterate over all the foo. This is a simple example,
and what you say about thinking about what *is* the result doesn't
really translate well into a C++ example, but the broader concept
applies: there's a difference between code as the compiler/interpreter
sees it and code as the programmer sees it, and there is not always a
1:1 correspondence of statements.
ChrisA
I had a blog post about line-length in programs
http://blog.languager.org/2012/10/layout-imperative-in-functional.html
followed by an interesting discussion on the haskell mailing list
http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec
The comment by Alexander Solla was insightful and is probably what you
are saying.
[Probably!! I am not sure what you are saying!]
Unfortunately a lot of your code specifics don't mean much to me
because I don't speak Haskell, but you are making several similar
points. A line of code should not be defined by the language's syntax,
but by the programmer's intention. A Python example might be:
for x in filter(lambda x: x%5 and x%6,range(40)):
# do something with the numbers that don't count by 5 or 6
Stupid example, but it still puts the conditional inside the loop
header. I'm sure you can come up with a more useful case!
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and GIL
On Fri, May 31, 2013 at 4:14 AM, Ana Marija Sokovic sokovic.anamar...@gmail.com wrote: Hi, Can somebody explain to me how would you proceed in releasing the GIL and whether you think it will have consequences? You release the GIL in C-level code when you don't need to work with Python objects for a while. Simple example is when you need to wait for something - for instance, if you attempt to read from a pipe, you can release the GIL before reading, then reacquire it afterward. The consequence is that you can't do anything with Python objects till you reacquire it. It's like any other resource-guarding mutex lock. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On Thu, May 30, 2013 at 12:26 PM, Mok-Kong Shen mok-kong.s...@t-online.de wrote: Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. The bytes object can be viewed as a sequence of ints. So if b is a bytes object of non-zero length, then b[0] is an int in range(0, 256). -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 11:36 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. This is a subjective view of course... My problem is not method vs function but the order. Ive seen/used join dozens of times. Yet I find .join([apple,bear,cat]) backkwards as compared to [apple,bear,cat].join() The consistency is a separate question -- not arguing about that. Just that I dont like the look -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 12:44 PM, Chris Angelico ros...@gmail.com wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) The reason I like having the shorter argument first (at least for function calls) is for when I'm reading the code. If I'm interested in the second argument, then to find it I have to scan over the first argument. I would rather scan over something short like '\n' than something longer like a list comprehension. It sounds like a trivial thing, but it really does make it easier to find where an expression starts and ends when the expression is short. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On 30 mai, 20:42, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, May 30, 2013 at 12:26 PM, Mok-Kong Shen
mok-kong.s...@t-online.de wrote:
Am 27.05.2013 17:30, schrieb Ned Batchelder:
On 5/27/2013 10:45 AM, Mok-Kong Shen wrote:
From an int one can use to_bytes to get its individual bytes,
but how can one reconstruct the int from the sequence of bytes?
The next thing in the docs after int.to_bytes is int.from_bytes:
http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes
I am sorry to have overlooked that. But one thing I yet wonder is why
there is no direct possibilty of converting a byte to an int in [0,255],
i.e. with a constrct int(b), where b is a byte.
The bytes object can be viewed as a sequence of ints. So if b is a
bytes object of non-zero length, then b[0] is an int in range(0, 256).
Well, Python now speaks only integer, the rest is
commodity and there is a good coherency.
bin(255)
'0b'
oct(255)
'0o377'
255
255
hex(255)
'0xff'
int('0b', 2)
255
int('0o377', 8)
255
int('255')
255
int('0xff', 16)
255
0b
255
0o377
255
255
255
0xff
255
type(0b)
class 'int'
type(0o377)
class 'int'
type(255)
class 'int'
type(0xff)
class 'int'
jmf
--
http://mail.python.org/mailman/listinfo/python-list
OpenMP uses only 1 core as soon as numpy is loaded
I use openMp in a C-extension that has an interface with Python.
In its simplest form I do this:
== code ==
#pragma omp parallel
{
#pragma omp for
for(int i=0; i10; i++)
{
// multiply some matrices in C
}
}
== end of code ==
This all works fine, and it uses the number of cores I have. But if I import
numpy in my python session BEFORE I run the code, then it uses only 1 core (and
omp_num_procs also returns 1 core, instead of the maximum of 8 cores).
So how does numpy affect openMp, and does it have anything to do with the GIL
or something? I don't use any Python object in my parallel region.
Any help would be appreciated!
Wout
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to get an integer from a sequence of bytes
On 5/30/2013 2:26 PM, Mok-Kong Shen wrote: Am 27.05.2013 17:30, schrieb Ned Batchelder: On 5/27/2013 10:45 AM, Mok-Kong Shen wrote: From an int one can use to_bytes to get its individual bytes, but how can one reconstruct the int from the sequence of bytes? The next thing in the docs after int.to_bytes is int.from_bytes: http://docs.python.org/3.3/library/stdtypes.html#int.from_bytes I am sorry to have overlooked that. But one thing I yet wonder is why there is no direct possibilty of converting a byte to an int in [0,255], i.e. with a constrct int(b), where b is a byte. Presumably you want this to work: int(b'\x03') 3 But you also want this to work: int(b'7') 7 These two interpretations are incompatible. If b'\x03' becomes 3, then shouldn't b'\x37' become 55? But b'\x37' is b'7', and you want that to be 7. --Ned. M. K. Shen -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On Thu, 30 May 2013 16:40:52 +, Steven D'Aprano wrote: On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote: You're assuming you can casually hit Ctrl-C to stop an infinite loop, meaning that it's trivial. It's not. Not everything lets you do that; or possibly halting the process will halt far more than you intended. What if you're editing live code in something that's had uninterrupted uptime for over a year? Then more fool you for editing live code. Ouch! That came out much harsher than it sounded in my head :( Sorry Chris, that wasn't intended as a personal attack against you, just as a comment on the general inadvisability of modifying code on the fly while it is being run. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
On 2013-05-30, Chris Angelico ros...@gmail.com wrote: On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: # Wrong, don't do this! x = 0.1 while x != 17.3: print(x) x += 0.1 Actually, I wouldn't do that with integers either. I propose borrowing the concept of significant digits from the world of Physics. The above has at least three significant digits. With that scheme x would approximately equal 17.3 when 17.25 = x 17.35. But I don't see immediately how to calculate 17.25 and 17.35 from 17.3, 00.1 and 3 significant digits. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 30/05/2013 19:44, Chris Angelico wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) Ha,Ha! The join method is one of the (for me) ugly features of python. You can sweep it under the carpet with a one-line join function and then write clean and pretty code: #joinwith def joinw(l,sep): return sep.join(l) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) -- http://mail.python.org/mailman/listinfo/python-list
