Re: Multi-dimensional list initialization
On 11/05/2012 10:07 PM, Chris Angelico wrote: On Tue, Nov 6, 2012 at 4:51 PM, Andrew Robinson wrote: I really don't think doing a shallow copy of lists would break anyone's program. Well, it's a change, a semantic change. It's almost certainly going to break _something_. But for the sake of argument, we can suppose that the change could be made. Would it be the right thing to do? Shallow copying by default would result in extremely weird behaviour. All the same confusion would result, only instead of comparing [None]*4 with [[None]]*4, there'd be confusion over the difference between [[None]]*4 and [[[None]]]*4. I don't think it would help anything, and it'd result in a lot more work for no benefit. ChrisA I don't follow. a=[ None ]*4 would give a=[ None, None, None, None ] as usual. All four None's would be the same object, but there are automatically 4 different pointers to it. Hence, a[0]=1 would give a=[ 1, None, None, None ] as usual. a=[ [None] ]*4 would give a=[ [None], [None], [None], [None] ] as usual BUT: a[0][0] = 1 would no longer give a=[ [1],[1],[1],[1] ] *Rather* it would give a=[ [1].[None].[None],[None] ] The None objects are all still the same one, BUT the lists themselves are different. Again, a=[ ["alpha","beta"] * 4 ] would give: a=[ ["alpha","beta"], ["alpha","beta"], ["alpha","beta"], ["alpha","beta"] ] All four strings, "alpha", are the same object -- but there are 5 different lists; The pointers inside the initial list are copied four times -- not the string objects; But the *lists* themselves are created new for each replication. If you nest it another time; [[[None]]]*4, the same would happen; all lists would be independent -- but the objects which aren't lists would be refrenced-- not copied. a=[[["alpha","beta"]]]*4 would yield: a=[[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']]] and a[0][0]=1 would give [[1],[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta' rather than a=[[1], [1], [1], [1]] Or at another level down: a[0][0][0]=1 would give: a=[[[1, 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']] ] rather than a=[[[1, 'beta']], [[1, 'beta']], [[1, 'beta']], [[1, 'beta']]] The point is, there would be no difference at all noticed in what data is found where in the array; the *only* thing that would change is that replacing an item by assignment would only affect the *location* assigned to -- all other locations would not be affected. That really is what people *generally* want. If the entire list is meant to be read only -- the change would affect *nothing* at all. See if you can find *any* python program where people desired the multiplication to have the die effect that changing an object in one of the sub lists -- changes all the objects in the other sub lists. I'm sure you're not going to find it -- and even if you do, it's going to be 1 program in 1000's. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coordination between developers in the Python project
On Tue, Nov 6, 2012 at 7:49 PM, Ian Kelly wrote: > On Mon, Nov 5, 2012 at 3:01 PM, Chris Angelico wrote: >> By "URL unshortening service" you mean a simple HTTP request to >> bit.ly:80, right? :) Though I admit there aren't many easy and >> convenient ways to do that without immediately following the 301 >> redirect. > > That's one way to do it. Although I find it a bit easier to just use > something like unshorten.com, which is the first Google hit for "url > unshortener". Assuming that you trust that site to not be hosting > malware itself. :-) A few years ago, I found myself bugged by URLs getting broken across multiple lines when shared across a MUD communication channel (80-character lines, with a header on each line, so there'd be between 65 and 75 usable characters per line), so I wrote a feature into my MUD client that would auto-shorten long URLs by passing them to tinyurl.com, and also "render" them on the other side - if it started http://tinyurl.com/ then the client would, on request, query tinyurl and snag the returned URL back into the display. For some reason it never occurred to me to do it any way other than direct socket operations in C. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Mon, 05 Nov 2012 21:51:24 -0800, Andrew Robinson wrote: > The most compact notation in programming really ought to reflect the > most *commonly* desired operation. Otherwise, we're really just making > people do extra typing for no reason. There are many reasons not to put minimizing of typing ahead of all other values: * Typically, code is written once and read many times. Minimizing typing might save you a second or two once, and then cost you many seconds every time you read the code. That's why we tell people to choose meaningful variable names, instead of naming everything "a" and "b". * Consistency of semantics is better than a plethora of special cases. Python has a very simple and useful rule: objects should not be copied unless explicitly requested to be copied. This is much better than having to remember whether this operation or that operation makes a copy. The answer is consistent: (pardon me for belabouring the point here) Q: Does [0]*10 make ten copies of the integer object? A: No, list multiplication doesn't make copies of elements. Q: How about [0.0]*10? A: No, the elements are never copied. Q: What if I use a singleton? Does [None]*10 try to copy? A: No, the elements are never copied. Q: How about things like file objects that can't be copied? A: No, the elements are never copied. Q: What about [[]]*10? A: No, the elements are never copied. Q: How about if the elements are subclasses of list? A: No, the elements are never copied. Q: What about other mutable objects like sets or dicts? A: No, the elements are never copied. Q: What about instances of custom classes? A: No, the elements are never copied. Q: What if they are old-style Classic classes? A: No, the elements are never copied. Q: What if I do some funny tricks with the metaclass? A: No, the elements are never copied. Q: How about on Tuesdays? I bet they're copied on Tuesdays. A: No, the elements are never copied. Your proposal throws away consistency for a trivial benefit on a rare use- case, and replaces it with a bunch of special cases: Q: What about [[]]*10? A: Oh yeah, I forgot about lists, they're copied. Q: How about if the elements are subclasses of list? A: Hmmm, that's a good one, I'm not actually sure. Q: How about if I use delegation to proxy a list? A: Oh no, they definitely won't be copied. Q: What about other mutable objects like sets or dicts? A: No, definitely not. Unless people complain enough. Q: What about instances of custom classes? A: That's a definite maybe. Q: How about on Tuesdays? I bet they're copied on Tuesdays. A: Only if you're in Belgium. Losing consistency in favour of saving a few characters for something as uncommon as list multiplication is a poor tradeoff. That's why this proposal has been rejected again and again and again every time it has been suggested. List multiplication [x]*n is conceptually equivalent to: newlist = [] for i in range(n): newlist.append(x) or if you prefer a list comp: [x for i in range(n)] This is nice and simple and efficient. Some objects cannot be copied at all. Copying other objects is slow and inefficient. Keeping list multiplication consistent, and fast, is MUCH more important than making it work as expected for the rare case of 2D arrays: [[0]*n]*m where there are other alternatives. > Further, list comprehensions take quite a bit longer to run than low > level copies; by a factor of roughly 10. SO, it really would be worth > implementing the underlying logic -- even if it wasn't super easy. Copying those elements does not come for free. It is true that list multiplication can be much faster than a list comp. But that's because the list multiply doesn't have to inspect the elements, copy them, or engage the iteration machinery. Avoiding copying gives you a big saving: [steve@ando ~]$ python3.3 -m timeit -s "x = range(1000)" "[x for _ in range(100)]" # not copied 10 loops, best of 3: 11.9 usec per loop [steve@ando utilities]$ python3.3 -m timeit -s "x = range(1000)" "[x[:] for _ in range(100)]" # copied 1 loops, best of 3: 103 usec per loop So there's a factor of ten difference right there. If list multiplication had to make copies, it would lose much of its speed advantage. For large enough lists, or complicated enough objects, it would become slower than a list comprehension. It would be even slower if list multiplication had to inspect each element first and decide whether or not to copy. > I really don't think doing a shallow copy of lists would break anyone's > program. Anyone who is currently using list multiplication with mutable objects is expecting that they will be the same object, and relying on that fact. Otherwise they wouldn't be using list multiplication. You're suggesting a semantic change. Therefore they will be
Re: Multi-dimensional list initialization
On Tue, Nov 6, 2012 at 1:21 AM, Andrew Robinson wrote: > If you nest it another time; > [[[None]]]*4, the same would happen; all lists would be independent -- but > the objects which aren't lists would be refrenced-- not copied. > > a=[[["alpha","beta"]]]*4 would yield: > a=[[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', > 'beta']]] > and a[0][0]=1 would give [[1],[['alpha', 'beta']], [['alpha', 'beta']], > [['alpha', 'beta' > rather than a=[[1], [1], [1], [1]] > > Or at another level down: a[0][0][0]=1 would give: a=[[[1, 'beta']], > [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']] ] > rather than a=[[[1, 'beta']], [[1, 'beta']], [[1, 'beta']], [[1, 'beta']]] You wrote "shallow copy". When the outer-level list is multiplied, the mid-level lists would be copied. Because the copies are shallow, although the mid-level lists are copied, their contents are not. Thus the inner-level lists would still be all referencing the same list. To demonstrate: >>> from copy import copy >>> class ShallowCopyList(list): ... def __mul__(self, number): ... new_list = ShallowCopyList() ... for _ in range(number): ... new_list.extend(map(copy, self)) ... return new_list ... >>> a = ShallowCopyList([[["alpha", "beta"]]]) >>> a [[['alpha', 'beta']]] >>> b = a * 4 >>> b [[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']]] >>> b[0][0][0] = 1 >>> b [[[1, 'beta']], [[1, 'beta']], [[1, 'beta']], [[1, 'beta']]] >>> b[0][0] = 1 >>> b [[1], [[1, 'beta']], [[1, 'beta']], [[1, 'beta']]] This shows that assignments at the middle level are independent with a shallow copy on multiplication, but assignments at the inner level are not. In order to achieve the behavior you describe, a deep copy would be needed. > That really is what people *generally* want. > If the entire list is meant to be read only -- the change would affect > *nothing* at all. The time and memory cost of the multiplication operation would become quadratic instead of linear. > See if you can find *any* python program where people desired the > multiplication to have the die effect that changing an object in one of the > sub lists -- changes all the objects in the other sub lists. > > I'm sure you're not going to find it -- and even if you do, it's going to be > 1 program in 1000's. Per the last thread where we discussed extremely rare scenarios, shouldn't you be rounding "1 in 1000s" up to 20%? ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe with python 3.x
Am 05.11.2012 20:39, schrieb Kwpolska: On Mon, Nov 5, 2012 at 8:34 PM, Monkey wrote: Hi, i wonderd if there is a way to convert a py-file to a exe-file with version 3.x of python. I know that it was possible till version 2.7.x. But is there a way to do it in version 3.x? Yours sincerely, Monkey -- http://mail.python.org/mailman/listinfo/python-list Use cx_Freeze: http://cx-freeze.sourceforge.net/ cx_Freeze is great as far as you don't need to use the latest Python version 3.3.0, because there is still a bug: http://sourceforge.net/p/cx-freeze/bugs/33/ I hope this will be fixed soon... -- http://mail.python.org/mailman/listinfo/python-list
Logging output to be redirected to a particular folder
Hi,
Below is the python code that I have. I want to redirect the output to my C
drive..myapp.log.
I am editing and creating scripts in IDLE and running it as a python shell or
module.
Can you help?
import logging
def main():
logging.basicConfig(Filename='c://myapp.log', level=logging.ERROR)
logging.debug('started debug')
logging.info('info printing')
logging.warning('test warning')
logging.debug('debug again')
logging.error('Error')
if __name__ == '__main__':
main()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Logging output to be redirected to a particular folder
[email protected] wrote: > Hi, > > Below is the python code that I have. I want to redirect the output to my > C drive..myapp.log. > > I am editing and creating scripts in IDLE and running it as a python shell > or module. > > Can you help? > > import logging > > def main(): >logging.basicConfig(Filename='c://myapp.log', level=logging.ERROR) Python is case-sensitive. Try: logging.basicConfig(filename='c://myapp.log', level=logging.ERROR) >logging.debug('started debug') >logging.info('info printing') >logging.warning('test warning') >logging.debug('debug again') >logging.error('Error') > > if __name__ == '__main__': >main() -- http://mail.python.org/mailman/listinfo/python-list
error
I am getting this error while running my programme.. : error: index is out of range I cannot find a valid reason for it in my prog can somebody suggest what may be possible reasons for this error.. The part of the code is : def addpoints (data, points, ix, iy): # makes a list of relevant points if 0 < ix < data.width and 0 < iy < data.height: point = data[ix, iy] if point != (0.0, 0.0, 0.0): points.append(point) return points for dx in xrange(-mask_size2, mask_size2 + 1): for dy in xrange(-mask_size2, mask_size2 + 1): ix, iy = x + dx, y + dy addpoints(data, points, ix , iy ) -- http://mail.python.org/mailman/listinfo/python-list
Re: error
On 11/06/2012 07:31 AM, inshu chauhan wrote: > I am getting this error while running my programme.. : > > error: index is out of range Please paste the whole error, including the traceback. It'll show you the line that had the error, as well as the calling sequence that got you there. > > I cannot find a valid reason for it in my prog can somebody suggest what > may be possible reasons for this error.. > > The part of the code is : > > def addpoints (data, points, ix, iy): # makes a list of relevant points > if 0 < ix < data.width and 0 < iy < data.height: > point = data[ix, iy] Tell us the type of the parameters. Perhaps data is of type Zanzibar, and the first subscript is the height, and the second is the width? Show us your class definition, since data is obviously not a built-in collection. > if point != (0.0, 0.0, 0.0): > points.append(point) > return points > > for dx in xrange(-mask_size2, mask_size2 + 1): > for dy in xrange(-mask_size2, mask_size2 + 1): What is the meaning and value of mask_size2 ? Is it a negative int? > ix, iy = x + dx, y + dy > addpoints(data, points, ix , iy ) > > BTW, this function's initial comment is incorrect. It doesn't make a list, it appends to one passed in. And there's no point in returning that list, since it has already been modified. By good convention, a simple function either returns a result or modifies its parameter, it shouldn't do both. Obviously there are exceptions for complex functions, but even then, for a single collection, it should either be modified in place, or created and returned, not both. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
RE: Multi-dimensional list initialization
Well said Steve, I agree with you... -Shambhu -Original Message- From: Steven D'Aprano [mailto:[email protected]] Sent: Tuesday, November 06, 2012 2:35 PM To: [email protected] Subject: Re: Multi-dimensional list initialization On Mon, 05 Nov 2012 21:51:24 -0800, Andrew Robinson wrote: > The most compact notation in programming really ought to reflect the > most *commonly* desired operation. Otherwise, we're really just > making people do extra typing for no reason. There are many reasons not to put minimizing of typing ahead of all other values: * Typically, code is written once and read many times. Minimizing typing might save you a second or two once, and then cost you many seconds every time you read the code. That's why we tell people to choose meaningful variable names, instead of naming everything "a" and "b". * Consistency of semantics is better than a plethora of special cases. Python has a very simple and useful rule: objects should not be copied unless explicitly requested to be copied. This is much better than having to remember whether this operation or that operation makes a copy. The answer is consistent: (pardon me for belabouring the point here) Q: Does [0]*10 make ten copies of the integer object? A: No, list multiplication doesn't make copies of elements. Q: How about [0.0]*10? A: No, the elements are never copied. Q: What if I use a singleton? Does [None]*10 try to copy? A: No, the elements are never copied. Q: How about things like file objects that can't be copied? A: No, the elements are never copied. Q: What about [[]]*10? A: No, the elements are never copied. Q: How about if the elements are subclasses of list? A: No, the elements are never copied. Q: What about other mutable objects like sets or dicts? A: No, the elements are never copied. Q: What about instances of custom classes? A: No, the elements are never copied. Q: What if they are old-style Classic classes? A: No, the elements are never copied. Q: What if I do some funny tricks with the metaclass? A: No, the elements are never copied. Q: How about on Tuesdays? I bet they're copied on Tuesdays. A: No, the elements are never copied. Your proposal throws away consistency for a trivial benefit on a rare use- case, and replaces it with a bunch of special cases: Q: What about [[]]*10? A: Oh yeah, I forgot about lists, they're copied. Q: How about if the elements are subclasses of list? A: Hmmm, that's a good one, I'm not actually sure. Q: How about if I use delegation to proxy a list? A: Oh no, they definitely won't be copied. Q: What about other mutable objects like sets or dicts? A: No, definitely not. Unless people complain enough. Q: What about instances of custom classes? A: That's a definite maybe. Q: How about on Tuesdays? I bet they're copied on Tuesdays. A: Only if you're in Belgium. Losing consistency in favour of saving a few characters for something as uncommon as list multiplication is a poor tradeoff. That's why this proposal has been rejected again and again and again every time it has been suggested. List multiplication [x]*n is conceptually equivalent to: newlist = [] for i in range(n): newlist.append(x) or if you prefer a list comp: [x for i in range(n)] This is nice and simple and efficient. Some objects cannot be copied at all. Copying other objects is slow and inefficient. Keeping list multiplication consistent, and fast, is MUCH more important than making it work as expected for the rare case of 2D arrays: [[0]*n]*m where there are other alternatives. > Further, list comprehensions take quite a bit longer to run than low > level copies; by a factor of roughly 10. SO, it really would be worth > implementing the underlying logic -- even if it wasn't super easy. Copying those elements does not come for free. It is true that list multiplication can be much faster than a list comp. But that's because the list multiply doesn't have to inspect the elements, copy them, or engage the iteration machinery. Avoiding copying gives you a big saving: [steve@ando ~]$ python3.3 -m timeit -s "x = range(1000)" "[x for _ in range(100)]" # not copied 10 loops, best of 3: 11.9 usec per loop [steve@ando utilities]$ python3.3 -m timeit -s "x = range(1000)" "[x[:] for _ in range(100)]" # copied 1 loops, best of 3: 103 usec per loop So there's a factor of ten difference right there. If list multiplication had to make copies, it would lose much of its speed advantage. For large enough lists, or complicated enough objects, it would become slower than a list comprehension. It would be even slower if list multiplication had to inspect each element first and decide whether or not to copy. > I really don't think doing a shallow copy of lists would break anyone's > program.
Base class and Derived class question
Hey guys, I'm trying to understand how is working base class and derived class. So, I have to files baseClass.py and derivedClass.py. baseClass.py : [CODE]class baseClass(): def bFunction(self): print "We are in a base class"[/CODE] derivedClass.py: [CODE]import baseClass as baseClassMod reload(baseClassMod) class derivedClass(baseClassMod): def dFunction(self): print "We are in a derived Class" [/CODE] buwhen I'm trying to run derivedClass.py I get this error : [CODE][COLOR=Red]TypeError: Error when calling the metaclass bases module.__init__() takes at most 2 arguments (3 given)[/COLOR][/CODE] Interesting thing is that if I run baseClass.py and then run : [CODE]class derivedClass(baseClass): def dFunction(self): print "We are in a derived Class"[/CODE] It works fine -- http://mail.python.org/mailman/listinfo/python-list
Base class and Derived class question
Hey guys, I'm trying to understand how is working base class and derived class. So, I have to files baseClass.py and derivedClass.py. baseClass.py : >>> class baseClass(): def bFunction(self): print "We are in a base class" derivedClass.py: >>>import baseClass as baseClassMod reload(baseClassMod) class derivedClass(baseClassMod): def dFunction(self): print "We are in a derived Class" buwhen I'm trying to run derivedClass.py I get this error : TypeError: Error when calling the metaclass bases module.__init__() takes at most 2 arguments (3 given) Interesting thing is that if I run baseClass.py and then run : >>>class derivedClass(baseClass): def dFunction(self): print "We are in a derived Class" It works fin -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
In article <[email protected]>, Steven D'Aprano wrote: > Shell do not [quote strings, etc] because they > are designed for lazy users and merely aim to be "good enough". Well, sort of. Or, perhaps more correctly, "Yes, but that's a good thing". Shells are designed to be interactive tools, where most commands get run once and thrown away. As such, you want everything to be easy to type, which largely means your fingers never leave the main part of the keyboard and you never have to reach for the shift key. The basic unix shell syntax was laid down in the days of the ASR-33. It was slow, hard to type on, and only had a single case of the alphabet (and missing a few pieces of punctuation). Saving keystrokes was an important consideration. Programming languages are designed to write programs. Not only will the code be {used, read, maintained} for a much longer period of time, it will be used by people other than the original author, and on inputs other than originally intended. It needs to be more robust. The problem is that shells got pressed into service as programming languages. At that, they suck. Sure, putting a few commands into a file for reuse was great. Adding a few bells and whistles like variables and conditional execution added greatly to the power of the tool. But, by the time we got to 100 (or 1000!) line shell scripts with functions, loops, arithmetic, etc, things had clearly gone off into the weeds. It's just the wrong tool for that. -- http://mail.python.org/mailman/listinfo/python-list
Re: delete value in list in indexing
On 11/06/2012 01:17 AM, Amit Agrawal wrote: > i want to delete list in upper and lower some specific value > > That question will have to be rephrased, in clearer English. What Python version are you using? What data do you start with, and what data do you want to end up with? Be specific with regards to types. For example, you might be asking: "I am using Python 2.81, on Windows 9. I have a program that's got two strings, the second of which is a single character. I'd like to produce a 3rd string which consists of all characters of the first string that do not match the single character supplied. Further, if the character is an ASCII alpha character, I'd like to do it without regards to ASCII uppercase/lowercase." or "I am using I have a program that has a list of ints, and a single value. I'd like to do an in-place removal of all numbers that are within 5 of the specified value." -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
On 11/06/2012 08:50 AM, [email protected] wrote: > Hey guys, > I'm trying to understand how is working base class and derived class. in what Python version ? > So, I have to files baseClass.py and derivedClass.py. > baseClass.py : class baseClass(): How did all those angle brackets get into the file? Are you confusing an interactive interpreter session with running source files? > def bFunction(self): This line isn't indented properly. It must be further from the left margin than the class declaration. > print "We are in a base class" > > derivedClass.py: import baseClass as baseClassMod > reload(baseClassMod) reload() isn't safe to use, and especially on a module that's been renamed while it was first imported. It's a trick to speed up debugging in the interactive interpreter, and when something goes wrong, you exit the interpreter and try again. > class derivedClass(baseClassMod): > def dFunction(self): > print "We are in a derived Class" > > buwhen I'm trying to run derivedClass.py I get this error : Again, what are you actually doing? Running that file, or playing around in the interpreter? > TypeError: Error when calling the metaclass bases > module.__init__() takes at most 2 arguments (3 given) > > Interesting thing is that if I run baseClass.py and then run : If you run baseClass.py, and get back to the bash prompt, then nothing will affect subsequent tests. class derivedClass(baseClass): > def dFunction(self): > print "We are in a derived Class" > It works fin Either use the interpreter or run from the shell. This mixing of the two is mighty confusing. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Nov 6, 2012 6:00 AM, "Andrew Robinson" wrote: > > On 11/05/2012 06:30 PM, Oscar Benjamin wrote: >> >> stuff = [[obj] * n] * m >> >> I thought that the multiplication of the inner list ([obj] * n) by m >> could create a new list of lists using copies. On closer inspection I >> see that the list being multiplied is in fact [[obj] * n] and that >> this list can only know that it is a list of lists by inspecting its >> element(s) which makes things more complicated. >> >> I retract my claim that this change would be easy to implement. > > In general, people don't use element multiplication (that I have *ever* seen) to make lists where all elements of the outer most list point to the same sub-*list* by reference. The most common use of the multiplication is to fill an array with a constant, or short list of constants; Hence, almost everyone has to work around the issue as the initial poster did by using a much longer construction. That's what I have seen as well. I've never seen an example where someone wanted this behaviour. > > The most compact notation in programming really ought to reflect the most *commonly* desired operation. Otherwise, we're really just making people do extra typing for no reason. It's not so much the typing as the fact that this a common gotcha. Apparently many people expect different behaviour here. I seem to remember finding this surprising at first. > > Further, list comprehensions take quite a bit longer to run than low level copies; by a factor of roughly 10. SO, it really would be worth implementing the underlying logic -- even if it wasn't super easy. > > I really don't think doing a shallow copy of lists would break anyone's program. > The non-list elements, whatever they are, can be left as reference copies -- but any element which is a list ought to be shallow copied. The behavior observed in the opening post where modifying one element of a sub-list, modifies all elements of all sub-lists is never desired as far as I have ever witnessed. It is a semantic change that would, I imagine, break many things in subtle ways. > > The underlying implementation of Python can check an object type trivially, and the only routine needed is a shallow list copy. So, no it really isn't a complicated operation to do shallow copies of lists. Yes but if you're inspecting the object to find out whether to copy it what do you test for? If you check for a list type what about subclasses? What if someone else has a custom list type that is not a subclass? Should there be a dunder method for this? I don't think it's such a simple problem. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: delete value in list in indexing
On 06/11/2012 06:17, Amit Agrawal wrote: i want to delete list in upper and lower some specific value I think you want to delete a slice so read about slicing here http://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
> in what Python version ? Python 2.7.3 > How did all those angle brackets get into the file? Are you confusing > > an interactive interpreter session with running source files? I've used angle brackets just for posting here,becauze this forum doesn't support [code][/code] I have a file called baseClass.py with code abouve and indentation is correct. Then I open python IDLE and type : import baseClass as baseClassMod reload(baseClassMod class derivedClass(baseClassMod): def dFunction(self): print "We are in a derived Class" After that i get the error above. But if I paste in Python IDLE a code from baseClass.py and just run: class derivedClass(baseClass): def dFunction(self): print "We are in a derived Class" it works perfectly. Why happen this? -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
Just got answer, I didn't call a class it's self. Correct code is: class derivedClass(baseClassMod.baseClass): def .. -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
On Tue, Nov 6, 2012 at 8:03 AM, wrote: > I've used angle brackets just for posting here,becauze this forum doesn't > support [code][/code] This is a Usenet group, not a web forum. > Just got answer, I didn't call a class it's self. Correct code is: > class derivedClass(baseClassMod.baseClass): > def .. Better style would be to import the class from the module in the first place: from baseClass import baseClass # ... class derivedClass(baseClass): # ... Better yet would be to put both classes in the same file in the first place. Python isn't Java, where each class is an independent compilation unit. There is no reason to put each class in its own separate module, and it tends to cause namespace confusion as you have discovered. -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
On Tuesday, November 6, 2012 4:35:47 PM UTC+1, Ian wrote: > On Tue, Nov 6, 2012 at 8:03 AM, > > > I've used angle brackets just for posting here,becauze this forum doesn't > > support [code][/code] > > > > This is a Usenet group, not a web forum. > > > > > Just got answer, I didn't call a class it's self. Correct code is: > > > class derivedClass(baseClassMod.baseClass): > > > def .. > > > > Better style would be to import the class from the module in the first place: > > > > from baseClass import baseClass > > > > # ... > > > > class derivedClass(baseClass): > > # ... > > > > Better yet would be to put both classes in the same file in the first > > place. Python isn't Java, where each class is an independent > > compilation unit. There is no reason to put each class in its own > > separate module, and it tends to cause namespace confusion as you have > > discovered. On Tuesday, November 6, 2012 4:35:47 PM UTC+1, Ian wrote: > On Tue, Nov 6, 2012 at 8:03 AM, > > > I've used angle brackets just for posting here,becauze this forum doesn't > > support [code][/code] > > > > This is a Usenet group, not a web forum. > > > > > Just got answer, I didn't call a class it's self. Correct code is: > > > class derivedClass(baseClassMod.baseClass): > > > def .. > > > > Better style would be to import the class from the module in the first place: > > > > from baseClass import baseClass > > > > # ... > > > > class derivedClass(baseClass): > > # ... > > > > Better yet would be to put both classes in the same file in the first > > place. Python isn't Java, where each class is an independent > > compilation unit. There is no reason to put each class in its own > > separate module, and it tends to cause namespace confusion as you have > > discovered. On Tuesday, November 6, 2012 4:35:47 PM UTC+1, Ian wrote: > > > I've used angle brackets just for posting here,becauze this forum doesn't > > support [code][/code] > > > > This is a Usenet group, not a web forum. > > > > > Just got answer, I didn't call a class it's self. Correct code is: > > > class derivedClass(baseClassMod.baseClass): > > > def .. > > > > Better style would be to import the class from the module in the first place: > > > > from baseClass import baseClass > > > > # ... > > > > class derivedClass(baseClass): > > # ... > > > > Better yet would be to put both classes in the same file in the first > > place. Python isn't Java, where each class is an independent > > compilation unit. There is no reason to put each class in its own > > separate module, and it tends to cause namespace confusion as you have > > discovered. Thank you for reply. Of course, import just a class from the module. The reason of have each class in separate file is that I have a base class with basic functionality and a lot of derived classes from it with custom functionality for each class. Also, the program is modular and periodically will need adding some new modules. So, for better organisation of all this stuff I have put them in separate files. -- http://mail.python.org/mailman/listinfo/python-list
Re: Base class and Derived class question
On 6/11/12 14:47:03, [email protected] wrote: > Hey guys, > I'm trying to understand how is working base class and derived class. > So, I have to files baseClass.py and derivedClass.py. > baseClass.py : > [CODE]class baseClass(): > def bFunction(self): > print "We are in a base class"[/CODE] > > derivedClass.py: > [CODE]import baseClass as baseClassMod > reload(baseClassMod) > > class derivedClass(baseClassMod): This line is wrong: baseClassMod is a module, not a class. You cannot derive a class from a module, only from another class. If you import baseClass as baseClassMod, then the name of the class defined inside the module is baseClassMod.baseClass, so this line should be: class derivedClass(baseClassMod.baseClass): > def dFunction(self): > print "We are in a derived Class" [/CODE] > > buwhen I'm trying to run derivedClass.py I get this error : > [CODE][COLOR=Red]TypeError: Error when calling the metaclass bases > module.__init__() takes at most 2 arguments (3 given)[/COLOR][/CODE] > > Interesting thing is that if I run baseClass.py and then run : > [CODE]class derivedClass(baseClass): > def dFunction(self): > print "We are in a derived Class"[/CODE] > It works fine Alternative solutions that also work: import baseClass class derivedClass(baseClass.baseClass): def dFunction(self): print "We are in a derived Class" Or you can import the class rather than the module: from baseClass import baseClass class derivedClass(baseClass): def dFunction(self): print "We are in a derived Class" If you're trying to learn about derived classes, then it might be a good idea to avoid learning about the pitfalls of importing at the same time. If you simply put both classes in the same file, the problem disappears: class baseClass(): def bFunction(self): print "We are in a base class" class derivedClass(baseClass): def dFunction(self): print "We are in a derived Class" instance = derivedClass() instance.bFunction() instance.dFunction() This works as you'd expect. Incidentally, the recommended way to avoid confusion between modules and classes it to use lower case names for your modules abd names with an initial capital for your classes, for example: class BaseClass(object): def bMethod(self): print "We are in a base class" class DerivedClass(BaseClass): def dMethod(self): print "We are in a derived Class" instance = DerivedClass() instance.bMethod() instance.dMethod() Hope this helps, -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: What the diferences : web.py Tornado Twisted ?!
On 2012-11-02 15:50:30 +, nepaul said: What the diferences : web.py Tornado Twisted ?! There really is a lot of material on this online, including numerous videos. But in my experience Tornado is basically a (really cool and easy to use) programmable web server whereas Twisted is a framework for building any kind of network server. I guess you could say one could use Twisted to build Tornado, but not the other way around. :) Just my 2c, haven't used web.py myself. Google is your friend and as always - concentrate on what you're trying to solve and then choose the right tool for the job, not the other way around. :-) hth, -flip -- -filipp http://unflyingobject.com "The future is here. It's just not evenly distributed yet." -- William Gibson -- http://mail.python.org/mailman/listinfo/python-list
RE: Obnoxious postings from Google Groups
Grant Edwards wrote: > On 2012-11-05, Roy Smith wrote: > > In article , > > Chris Angelico wrote: > > > >> It's nothing to do with operating system. File names are names, and > >> spaces in them are seldom worth the hassle unless you manipulate those > >> files solely using a GUI. > > > > That's a very ascii-esqe attitude. In a fully unicode world, I could > > easily see using U+00A0 (NO-BREAK SPACE) in file names, and still have > > space-delimited CLI work just fine. > > No, it wouldn't work just fine. You'd never know when looking at > names whether it was a "regular" space or a "no-break space", and > names would be visually ambiguous. Visually ambiguous names are > horrible. Not to mention that in the GUI I (usually) want the space to be a "break space". > > > But, yeah, in the world we live in today, I try to avoid spaces in > > filenames. But, instead of turning "My File Name" into MyFileName, I'll > > usually do it as My-File-Name or My_File_Name. ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Tue, 06 Nov 2012 08:52:36 -0500, Roy Smith wrote:
[putolin]
> Programming languages are designed to write programs. Not only will the
> code be {used, read, maintained} for a much longer period of time, it
> will be used by people other than the original author, and on inputs
> other than originally intended. It needs to be more robust.
>
> The problem is that shells got pressed into service as programming
> languages. At that, they suck. Sure, putting a few commands into a
> file for reuse was great. Adding a few bells and whistles like
> variables and conditional execution added greatly to the power of the
> tool. But, by the time we got to 100 (or 1000!) line shell scripts with
> functions, loops, arithmetic, etc, things had clearly gone off into the
> weeds. It's just the wrong tool for that.
Really?
I have just finished a 251 line bash shell script that builds my linux
distro from scratch. It uses other bash shell scripts that have more
lines per file/script and sources the individual package build bash
scripts. I used C for the package manager which is only non bash script
part of the entire package management system. The only thing I would
like to see in bash is to be able to return a string from a function.
--
http://mail.python.org/mailman/listinfo/python-list
RE: Obnoxious postings from Google Groups
Steven D'Aprano wrote: > > On Mon, 05 Nov 2012 14:47:47 -0500, Dennis Lee Bieber wrote: > [snip] > > Nevertheless, I do tend to prefer underscores to spaces, simply because I > often use naive tools that treat spaces as separators. That is, command > line shells. I visually prefer spaces but it is easier to work with underscores. Thankfully there are plenty of command line utilities for pattern renaming that let me shift to and from spaces as necessary. > > For what it's worth, you can enter any control character in Unix/Linux > systems with readline in bash using the C-q key combination. Newline > needs a bit of special treatment: you need to wrap the name in single > quotes to stop the newline from being interpreted as the end of the > command. > > [steve@ando temp]$ touch 'foo > bar' > > To enter the newline, I typed Ctrl-Q to tell bash to treat the next > character as a literal, and then typed Ctrl-J to get a newline. That sounds complicated, my version of bash lets me type 'foobar' for the same effect. ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
RE: Multi-dimensional list initialization
Ian Kelly wrote: > > On Tue, Nov 6, 2012 at 1:21 AM, Andrew Robinson > [snip] > > See if you can find *any* python program where people desired the > > multiplication to have the die effect that changing an object in one of the > > sub lists -- changes all the objects in the other sub lists. > > > > I'm sure you're not going to find it -- and even if you do, it's going to be > > 1 program in 1000's. > > Per the last thread where we discussed extremely rare scenarios, > shouldn't you be rounding "1 in 1000s" up to 20%? ;-) Actually, I would be surprised if it was even 1 in 1000. Of course, consistency makes it easier to learn and *remember*. I value that far more than a minor quirk that is unlikely to bother me now that I know of it. Well, at least not as long as I do not forget my morning coffee/tea :) ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
RE: Logging output to be redirected to a particular folder
Dennis Lee Bieber wrote: > > On Tue, 06 Nov 2012 13:26:11 +0100, Peter Otten <[email protected]> > declaimed the following in gmane.comp.python.general: > > > [email protected] wrote: [snip] > > > def main(): > > >logging.basicConfig(Filename='c://myapp.log', level=logging.ERROR) > > > > Python is case-sensitive. Try: > > > > logging.basicConfig(filename='c://myapp.log', level=logging.ERROR) > > > The double forward slashes might also be confusing... At the least, > unneeded... > > >>> import os.path > >>> print os.path.normpath("c://somefile.log") > c:\somefile.log > >>> print os.path.normpath("c:\\somefile.log") > c:\somefile.log > >>> print os.path.normpath("c:\\tryfile.log") > c:\tryfile.log > >>> print os.path.normpath("c:\tryfile.log") > c:ryfile.log > >>> print os.path.normpath("c:/tryfile.log") > c:\tryfile.log > >>> > > Doubling back-slashes is needed to avoid the problem of literal > escapes corrupting the intent... Or use the raw literal form r"c:\tryfile.log". I know several people that prefer to use forward slashes as it works in both Windows and *nix. ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
RE: who can give me some practical tutorials on django 1.4 or 1.5?
Levi Nie wrote: > > Who can give me some practical tutorials on django 1.4 or 1.5? > Thank you. Maybe this will help: http://gettingstartedwithdjango.com/resources/ ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: error
>From this line, "data" appears to be a class if 0 < ix < data.width and 0 < iy < data.height: >From this line, "data" appears to be a list, although a two dimensional list would be accessed as data[ix][iy] point = data[ix, iy] Also, returning a list from a function is a matter of preference. Some people argue that it should be returned to make it obvious. If you do not know the difference between what is mutable and what is not mutable, then return everything until you do. -- http://mail.python.org/mailman/listinfo/python-list
clicking on turtle
I have a problem with the standard "turtle" module. When a turtle has
a custom shape of type "compound", it doesn't seem to respond to click
events. No problem with polygon shapes.
Running python 3.2.3, turtle version 1.1b on Windows XP.
Here is my test file:
##
import turtle
square = ((0,0),(0,20),(20,20),(20,0))
turtle.addshape("sq1", square) # sq1 = polygon shape
s = turtle.Shape("compound")
s.addcomponent(square, "red")
turtle.addshape("sq2", s) # sq2 = compound shape
t1 = turtle.Turtle(shape="sq1")
t2 = turtle.Turtle(shape="sq2")
t2.fd(20) # set the turtles side by side
def click(x,y): print("click at",x,y)
t1.onclick(click)
t2.onclick(click)
turtle.mainloop()
##
When I run this and click on the black square (i.e. t1), the message
"click at..." gets printed on the console. When I click on the red
square (i.e. t2), nothing happens.
Bug or feature?
--Nicolas
--
http://mail.python.org/mailman/listinfo/python-list
clicking on turtle
I have a problem with the standard "turtle" module. When a turtle has
a custom shape of type "compound", it doesn't seem to respond to click
events. No problem with polygon shapes.
Running python 3.2.3, turtle version 1.1b on Windows XP.
Here is my test file:
##
import turtle
square = ((0,0),(0,20),(20,20),(20,0))
turtle.addshape("sq1", square) # sq1 = polygon shape
s = turtle.Shape("compound")
s.addcomponent(square, "red")
turtle.addshape("sq2", s) # sq2 = compound shape
t1 = turtle.Turtle(shape="sq1")
t2 = turtle.Turtle(shape="sq2")
t2.fd(20) # set the turtles side by side
def click(x,y): print("click at",x,y)
t1.onclick(click)
t2.onclick(click)
turtle.mainloop()
##
When I run this and click on the black square (i.e. t1), the message
"click at..." gets printed on the console. When I click on the red
square (i.e. t2), nothing happens.
Bug or feature?
--Nicolas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 11/06/2012 06:35 AM, Oscar Benjamin wrote: > In general, people don't use element multiplication (that I have *ever* seen) to make lists where all elements of the outer most list point to the same sub-*list* by reference. The most common use of the multiplication is to fill an array with a constant, or short list of constants; Hence, almost everyone has to work around the issue as the initial poster did by using a much longer construction. That's what I have seen as well. I've never seen an example where someone wanted this behaviour. > > The most compact notation in programming really ought to reflect the most *commonly* desired operation. Otherwise, we're really just making people do extra typing for no reason. It's not so much the typing as the fact that this a common gotcha. Apparently many people expect different behaviour here. I seem to remember finding this surprising at first. :) That's true as well. > > Further, list comprehensions take quite a bit longer to run than low level copies; by a factor of roughly 10. SO, it really would be worth implementing the underlying logic -- even if it wasn't super easy. > > I really don't think doing a shallow copy of lists would break anyone's program. > The non-list elements, whatever they are, can be left as reference copies -- but any element which is a list ought to be shallow copied. The behavior observed in the opening post where modifying one element of a sub-list, modifies all elements of all sub-lists is never desired as far as I have ever witnessed. It is a semantic change that would, I imagine, break many things in subtle ways. ?? Do you have any guesses, how ? > > The underlying implementation of Python can check an object type trivially, and the only routine needed is a shallow list copy. So, no it really isn't a complicated operation to do shallow copies of lists. Yes but if you're inspecting the object to find out whether to copy it what do you test for? If you check for a list type what about subclasses? What if someone else has a custom list type that is not a subclass? Should there be a dunder method for this? No dunder methods. :) Custom non-subclass list types aren't a common usage for list multiplication in any event. At present one has to do list comprehensions for that, and that would simply remain so. Subclasses, however, are something I hadn't considered... I don't think it's such a simple problem. Oscar You made a good point, Oscar; I'll have to think about the subclassing a bit. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 11/06/2012 09:32 AM, Prasad, Ramit wrote: Ian Kelly wrote: On Tue, Nov 6, 2012 at 1:21 AM, Andrew Robinson [snip] See if you can find *any* python program where people desired the multiplication to have the die effect that changing an object in one of the sub lists -- changes all the objects in the other sub lists. I'm sure you're not going to find it -- and even if you do, it's going to be 1 program in 1000's. Per the last thread where we discussed extremely rare scenarios, shouldn't you be rounding "1 in 1000s" up to 20%? ;-) :D -- Ian -- also consider that I *am* willing to use extra memory. Not everything can be shrunk to nothing and still remain functional. :) So, it isn't *all* about *micro* optimization -- it's also about psychology and flexibility. Actually, I would be surprised if it was even 1 in 1000. Of course, consistency makes it easier to learn and *remember*. I value that far more than a minor quirk that is unlikely to bother me now that I know of it. Well, at least not as long as I do not forget my morning coffee/tea :) But, having it copy lists -- when the only purpose of multiplication is for lists; is only a minor quirk as well. ~Ramit -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 11/06/2012 01:19 AM, Ian Kelly wrote: On Tue, Nov 6, 2012 at 1:21 AM, Andrew Robinson If you nest it another time; [[[None]]]*4, the same would happen; all lists would be independent -- but the objects which aren't lists would be refrenced-- not copied. a=[[["alpha","beta"]]]*4 would yield: a=[[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']]] and a[0][0]=1 would give [[1],[['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta' rather than a=[[1], [1], [1], [1]] Or at another level down: a[0][0][0]=1 would give: a=[[[1, 'beta']], [['alpha', 'beta']], [['alpha', 'beta']], [['alpha', 'beta']] ] rather than a=[[[1, 'beta']], [[1, 'beta']], [[1, 'beta']], [[1, 'beta']]] You wrote "shallow copy". When the outer-level list is multiplied, the mid-level lists would be copied. Because the copies are shallow, although the mid-level lists are copied, their contents are not. Thus the inner-level lists would still be all referencing the same list. To demonstrate: I meant all lists are shallow copied from the innermost level out. Equivalently, it's a deep copy of list objects -- but a shallow copy of any list contents except other lists. from copy import copy class ShallowCopyList(list): ... def __mul__(self, number): ... new_list = ShallowCopyList() ... for _ in range(number): ... new_list.extend(map(copy, self)) ... return new_list ... That type of copy is not equivalent to what I meant; It's a shallow copy only of non-list objects. This shows that assignments at the middle level are independent with a shallow copy on multiplication, but assignments at the inner level are not. In order to achieve the behavior you describe, a deep copy would be needed. Yes, it can be considered a deep copy of *all* list objects -- but not of non list contents. It's a terminology issue -- and you're right -- I need to be more precise. That really is what people *generally* want. If the entire list is meant to be read only -- the change would affect *nothing* at all. The time and memory cost of the multiplication operation would become quadratic instead of linear. Perhaps, but the copy would still not be _nearly_ as slow as a list comprehension !!! Being super fast when no one uses the output -- is , "going nowhere fast." I think It's better to get at the right place at a medium speed than nowhere fast; List comprehensions *do* get to the right place, but *quite* slowly. They are both quadratic, *and* multiple tokenized steps. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Tue, Nov 6, 2012 at 2:36 PM, Andrew Robinson
wrote:
> I meant all lists are shallow copied from the innermost level out.
> Equivalently, it's a deep copy of list objects -- but a shallow copy of any
> list contents except other lists.
Why only list objects, though? When a user writes [[]] * 10, they
probably want a list containing ten distinct nested lists. Likewise,
when a user writes [{}] * 10, they probably want a list containing ten
distinct dicts, which is not at all an uncommon thing to want. It
seems very inconsistent that the former should work while the latter
should not. This is especially true when you start mixing the two
paradigms; the user might expect [[{}] * 10] * 10 to create a a 10x10
matrix where each element is a distinct dict, but this still would not
work, even though the nested lists would all have different
identities.
What about ([],) * 10? This is perhaps best interpreted as a request
to create a matrix of ten rows where the rows themselves are mutable
but the collection of rows is not. If list multiplication were to
copy nested lists, then should tuple multiplication do the same?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 11/06/2012 01:04 AM, Steven D'Aprano wrote:
On Mon, 05 Nov 2012 21:51:24 -0800, Andrew Robinson wrote:
The most compact notation in programming really ought to reflect the
most *commonly* desired operation. Otherwise, we're really just making
people do extra typing for no reason.
There are many reasons not to put minimizing of typing ahead of all other
values:
I didn't. I put it ahead of *some* values for the sake of practicality
and human psychology.
" Practicality beats purity. "
* Typically, code is written once and read many times. Minimizing
typing might save you a second or two once, and then cost you many
seconds every time you read the code. That's why we tell people to
choose meaningful variable names, instead of naming everything "a"
and "b".
Yes. But this isn't going to cost any more time than figuring out
whether or not the list multiplication is going to cause quirks,
itself. Human psychology *tends* (it's a FAQ!) to automatically assume
the purpose of the list multiplication is to pre-allocate memory for the
equivalent (using lists) of a multi-dimensional array. Note the OP even
said "4d array".
The OP's original construction was simple, elegant, easy to read and
very commonly done by newbies learning the language because it's
*intuitive*. His second try was still intuitive, but less easy to read,
and not as elegant.
* Consistency of semantics is better than a plethora of special
cases. Python has a very simple and useful rule: objects should
not be copied unless explicitly requested to be copied. This is
much better than having to remember whether this operation or
that operation makes a copy. The answer is consistent:
Bull. Even in the last thread I noted the range() object produces
special cases.
>>> range(0,5)[1]
1
>>> range(0,5)[1:3]
range(1, 3)
>>>
The principle involved is that it gives you what you *usually* want; I
read some of the documentation on why Python 3 chose to implement it
this way.
(pardon me for belabouring the point here)
Q: Does [0]*10 make ten copies of the integer object?
A: No, list multiplication doesn't make copies of elements.
Neither would my idea for the vast majority of things on your first list.
Q: What about [[]]*10?
A: No, the elements are never copied.
YES! For the obvious reason that such a construction is making mutable
lists that the user wants to populate later. If they *didn't* want to
populate them later, they ought to have used tuples -- which take less
overhead. Who even does this thing you are suggesting?!
>>> a=[[]]*10
>>> a
[[], [], [], [], [], [], [], [], [], []]
>>> a[0].append(1)
>>> a
[[1], [1], [1], [1], [1], [1], [1], [1], [1], [1]]
Oops! Damn, not what anyone normal wants
Q: How about if the elements are subclasses of list?
A: No, the elements are never copied.
Another poster brought that point up -- it's something I would have to
study before answering.
It's a valid objection.
Q: What about other mutable objects like sets or dicts?
A: No, the elements are never copied.
They aren't list multiplication compatible in any event! It's a total
nonsense objection.
If these are inconsistent in my idea -- OBVIOUSLY -- they are
inconsistent in Python's present implementation. You can't even
reference duplicate them NOW.
>>> { 1:'a', 2:'b', 3:'c' } * 2
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for *: 'dict' and 'int'
Q: How about on Tuesdays? I bet they're copied on Tuesdays.
A: No, the elements are never copied.
That's really a stupid objection, and everyone knows it.
" Although that way may not be obvious at first unless you're Dutch. "
Your proposal throws away consistency for a trivial benefit on a rare use-
case, and replaces it with a bunch of special cases:
RARE You are NUTS
Q: What about [[]]*10?
A: Oh yeah, I forgot about lists, they're copied.
Yup.
Q: How about if the elements are subclasses of list?
A: Hmmm, that's a good one, I'm not actually sure.
Q: How about if I use delegation to proxy a list?
A: Oh no, they definitely won't be copied.
Give an example usage of why someone would want to do this. Then we can
discuss it.
Q: What about other mutable objects like sets or dicts?
A: No, definitely not. Unless people complain enough.
now you're just repeating yourself to make your contrived list longer --
but there's no new objections...
Losing consistency in favour of saving a few characters for something as
uncommon as list multiplication is a poor tradeoff. That's why this
proposal has been rejected again and again and again every time it has
been suggested.
Please link to the objection being proposed to the developers, and their
reasoning for rejecting it.
I think you are exaggerating.
List multiplication [x]*n is conceptually equivalent to:
This is nice and simple
Re: Obnoxious postings from Google Groups
On Tue, 06 Nov 2012 17:16:44 +, Prasad, Ramit wrote: >> To enter the newline, I typed Ctrl-Q to tell bash to treat the next >> character as a literal, and then typed Ctrl-J to get a newline. > > That sounds complicated, my version of bash lets me type > 'foobar' for the same effect. Well, I learned something new about bash. On the other hand, the Ctrl-Q next-char-is-literal trick works for entering control characters that otherwise don't have a key on the keyboard. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
RE: Obnoxious postings from Google Groups
Steven D'Aprano wrote: > > On Tue, 06 Nov 2012 17:16:44 +, Prasad, Ramit wrote: > > >> To enter the newline, I typed Ctrl-Q to tell bash to treat the next > >> character as a literal, and then typed Ctrl-J to get a newline. > > > > That sounds complicated, my version of bash lets me type > > 'foobar' for the same effect. > > Well, I learned something new about bash. > > On the other hand, the Ctrl-Q next-char-is-literal trick works for > entering control characters that otherwise don't have a key on the > keyboard. > Would you mind elaborating on how this works? I know it's not a bash list, but I do not understand how ctrl-J is considered a literal. Obviously, I must have a different definition of "literal". Where can I find a list of other literals? My Google-fu is being weak today. :( ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to only get a list of the names of the non-directory files in current directory ('.')?
在 2012年11月6日星期二UTC+8下午1时24分41秒，Chris Angelico写道：
> On Tue, Nov 6, 2012 at 4:19 PM, iMath wrote:
>
> > How to only get a list of the names of the non-directory files in current
> > directory ('.')?
>
> > (Note excluding its subdirectories ).
>
> >
>
> > I need the code : )
>
>
>
> Start by getting a list of names of everything in the current directory.
>
>
>
> Then filter that list by testing each one to see if it's a directory.
>
>
>
> Tip: The second step can be done with os.path.isdir
>
>
>
> Put some code together and try it. If you have trouble, post your
>
> code, any exception traceback you get, and what you're having
>
> difficulty with, and we'll go on from there.
>
>
>
> Have fun!
>
>
>
> ChrisA
how to get a list of names of everything in the current directory ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote: > I have just finished a 251 line bash shell script that builds my linux > distro from scratch. "From scratch"? So if you run it on bare metal with no OS, it works? :-P But seriously -- bash is a mature, powerful shell. It works well for what it does. It has been designed to make it easy[1] to automate system admin tasks. It would be astonishing if an experienced, competent bash programmer couldn't write an installation tool in bash. By comparison, few general purpose programming languages (with the obvious exception of perl) are designed for system administration as their primary purpose. But... how robust is your script? How many bugs does it contain? Chances are you will only use it a handful of times, on the same system. That's not a lot of testing to be sure that it is free of bugs, and robust against unexpected input. Hell, even widely used and distributed install scripts written by companies with the resources of Ubuntu and Red Hat have a distressing tendency to break. Or worse, to behave in unexpected ways. Unless you are some sort of bash-scripting über-geek superhero with powers beyond those of mortal men, chances are that your script is much more buggy and fragile than you imagine. How well does it recover from errors? Does it leave you with a broken system, half installed? How easily can you maintain it after three months? Will it work in the presence of filenames with newlines in them? [1] For some definition of "easy". In my opinion, control structures like "for" and "if" in bash are hard to use, hard to read, easy to get wrong, give cryptic error messages when you do get them wrong, and are ugly. Tests are obfuscated, and as always, the fact that everything is text in bash means it is way harder than it needs to be to use rich, modern data structures. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to only get a list of the names of the non-directory files in current directory ('.')?
In iMath writes: > how to get a list of names of everything in the current directory ? Try os.listdir() . -- John Gordon A is for Amy, who fell down the stairs [email protected] B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- http://mail.python.org/mailman/listinfo/python-list
Re: clicking on turtle
On Tue, 06 Nov 2012 22:13:21 +0100, python wrote: > I have a problem with the standard "turtle" module. When a turtle has a > custom shape of type "compound", it doesn't seem to respond to click > events. No problem with polygon shapes. [...] > When I run this and click on the black square (i.e. t1), the message > "click at..." gets printed on the console. When I click on the red > square (i.e. t2), nothing happens. I don't know enough about turtle graphics to tell whether it's a bug in your code, or a bug in the turtle, but I can confirm that the same behaviour occurs in Python 2.7 on Linux. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
RE: Multi-dimensional list initialization
Andrew Robinson wrote:
>
> On 11/06/2012 01:04 AM, Steven D'Aprano wrote:
> > On Mon, 05 Nov 2012 21:51:24 -0800, Andrew Robinson wrote:
> >
[snip]
> > Q: What about other mutable objects like sets or dicts?
> > A: No, the elements are never copied.
> They aren't list multiplication compatible in any event! It's a total
> nonsense objection.
>
> If these are inconsistent in my idea -- OBVIOUSLY -- they are
> inconsistent in Python's present implementation. You can't even
> reference duplicate them NOW.
>
> >>> { 1:'a', 2:'b', 3:'c' } * 2
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: unsupported operand type(s) for *: 'dict' and 'int'
>>> z = [ {'a':1} ]*10
>>> z[0]['b'] = 4
>>> z
[{'a': 1, 'b': 4}, {'a': 1, 'b': 4}, {'a': 1, 'b': 4},{'a': 1, 'b': 4},
{'a': 1, 'b': 4}, {'a': 1, 'b': 4}, {'a': 1, 'b': 4}, {'a': 1, 'b': 4},
{'a': 1, 'b': 4}, {'a': 1, 'b': 4}]
Should that copy the dictionary? According to logical reasoning
it should copy the dictionary as well. How do you draw the line of
what should be copied and what should not?
>
> > Q: How about on Tuesdays? I bet they're copied on Tuesdays.
> > A: No, the elements are never copied.
> That's really a stupid objection, and everyone knows it.
Agreed. [snip]
> > Q: How about if I use delegation to proxy a list?
> > A: Oh no, they definitely won't be copied.
> Give an example usage of why someone would want to do this. Then we can
> discuss it.
IIRC, someone wanted to do something very similar for dictionaries to
prevent editing of global variables.
> > Q: What about other mutable objects like sets or dicts?
> > A: No, definitely not. Unless people complain enough.
> now you're just repeating yourself to make your contrived list longer --
> but there's no new objections...
This is my main objection and one of the flaws of your argument.
You want to handle one type of mutable objects completely separately
than other mutable objects. Why is list any different than dictionary
in this respect? The only reason I can imagine is because lists
end up being used for 2d (or higher) "matrices".
>
> > Losing consistency in favour of saving a few characters for something as
> > uncommon as list multiplication is a poor tradeoff. That's why this
> > proposal has been rejected again and again and again every time it has
> > been suggested.
> Please link to the objection being proposed to the developers, and their
> reasoning for rejecting it.
> I think you are exaggerating.
I reject (as a developer) it because it forces me to remember a very
specific quirk versus a simple (logical) rule that applies to all objects. Not
to mention that the quirk is not even that useful except for beginners.
>
> > List multiplication [x]*n is conceptually equivalent to:
> >
> > This is nice and simple and efficient.
> No it isn't efficient. It's *slow* when done as in your example.
>
> > Copying other objects is slow and inefficient. Keeping list
> > multiplication consistent, and fast, is MUCH more important than making
> > it work as expected for the rare case of 2D arrays:
> I don't think so -- again, look at range(); it was made to work
> inconsistent for a "common" case.
>
> Besides, 2D arrays are *not* rare and people *have* to copy internals of
> them very often.
> The copy speed will be the same or *faster*, and the typing less -- and
> the psychological mistakes *less*, the elegance more.
>
> It's hardly going to confuse anyone to say that lists are copied with
> list multiplication, but the elements are not.
>
> Every time someone passes a list to a function, they *know* that the
> list is passed by value -- and the elements are passed by reference.
> People in Python are USED to lists being "the" way to weird behavior
> that other languages don't do.
I think you just lost 90% of your credibility (with me). When did lists
get passed by value? Python uses call by sharing[0].
Terminology aside, lists are handled exactly the same way as all
other objects; the rules regarding their mutability in the callee
are the same as dictionaries, sets, or any mutable type (including
non-builtins).
>
> >
> > Copying those elements does not come for free.
> >
> > It is true that list multiplication can be much faster than a list comp.
> > But that's because the list multiply doesn't have to inspect the
> > elements, copy them, or engage the iteration machinery. Avoiding copying
> > gives you a big saving:
> >
> >
> > [steve@ando ~]$ python3.3 -m timeit -s "x = range(1000)"
> > "[x for _ in range(100)]" # not copied
> > 10 loops, best of 3: 11.9 usec per loop
> >
> > [steve@ando utilities]$ python3.3 -m timeit -s "x = range(1000)"
> > "[x[:] for _ in range(100)]" # copied
> > 1 loops, best of 3: 103 usec per loop
> >
> > So there's a factor of ten difference right there. If list multiplication
> > had to make copies, it would lose much of its speed advantage.
> And when multiplicati
Re: Multi-dimensional list initialization
On Tue, Nov 6, 2012 at 3:41 PM, Andrew Robinson
wrote:
>> Q: What about other mutable objects like sets or dicts?
>> A: No, the elements are never copied.
>
> They aren't list multiplication compatible in any event! It's a total
> nonsense objection.
>
> If these are inconsistent in my idea -- OBVIOUSLY -- they are inconsistent
> in Python's present implementation. You can't even reference duplicate them
> NOW.
>
{ 1:'a', 2:'b', 3:'c' } * 2
>
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unsupported operand type(s) for *: 'dict' and 'int'
The objection is not nonsense; you've merely misconstrued it. If
[[1,2,3]] * 4 is expected to create a mutable matrix of 1s, 2s, and
3s, then one would expect [[{}]] * 4 to create a mutable matrix of
dicts. If the dicts are not copied, then this fails for the same
reason
>> Q: How about if I use delegation to proxy a list?
>> A: Oh no, they definitely won't be copied.
>
> Give an example usage of why someone would want to do this. Then we can
> discuss it.
Seriously? Read a book on design patterns. You might start at SO:
http://stackoverflow.com/questions/832536/when-to-use-delegation-instead-of-inheritance
>> Losing consistency in favour of saving a few characters for something as
>> uncommon as list multiplication is a poor tradeoff. That's why this
>> proposal has been rejected again and again and again every time it has
>> been suggested.
>
> Please link to the objection being proposed to the developers, and their
> reasoning for rejecting it.
> I think you are exaggerating.
>From Google:
http://bugs.python.org/issue1408
http://bugs.python.org/issue12597
http://bugs.python.org/issue9108
http://bugs.python.org/issue7823
Note that in two out of these four cases, the reporter was trying to
multiply lists of dicts, not just lists of lists.
> Besides, 2D arrays are *not* rare and people *have* to copy internals of
> them very often.
> The copy speed will be the same or *faster*, and the typing less -- and the
> psychological mistakes *less*, the elegance more.
List multiplication is not potentially useful for copying 2D lists,
only for initializing them. For copying an existing nested list,
you're still stuck with either copy.deepcopy() or a list
comprehension.
> It's hardly going to confuse anyone to say that lists are copied with list
> multiplication, but the elements are not.
>
> Every time someone passes a list to a function, they *know* that the list is
> passed by value -- and the elements are passed by reference. People in
> Python are USED to lists being "the" way to weird behavior that other
> languages don't do.
Incorrect. Python uses what is commonly known as call-by-object, not
call-by-value or call-by-reference. Passing the list by value would
imply that the list is copied, and that appends or removes to the list
inside the function would not affect the original list. This is not
what Python does; the list inside the function and the list passed in
are the same list. At the same time, the function does not have
access to the original reference to the list and cannot reassign it by
reassigning its own reference, so it is not call-by-reference
semantics either.
--
http://mail.python.org/mailman/listinfo/python-list
RE: How to only get a list of the names of the non-directory files in current directory ('.')?
iMath wrote: > how to get a list of names of everything in the current directory ? http://lmgtfy.com/?q=python+get+files+in+directory ~Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Tue, 06 Nov 2012 23:08:11 +, Prasad, Ramit wrote: > Steven D'Aprano wrote: >> >> On Tue, 06 Nov 2012 17:16:44 +, Prasad, Ramit wrote: >> >> >> To enter the newline, I typed Ctrl-Q to tell bash to treat the next >> >> character as a literal, and then typed Ctrl-J to get a newline. >> > >> > That sounds complicated, my version of bash lets me type >> > 'foobar' for the same effect. >> >> Well, I learned something new about bash. >> >> On the other hand, the Ctrl-Q next-char-is-literal trick works for >> entering control characters that otherwise don't have a key on the >> keyboard. >> >> > Would you mind elaborating on how this works? I know it's not a bash > list, but I do not understand how ctrl-J is considered a literal. > Obviously, I must have a different definition of "literal". Where can I > find a list of other literals? My Google-fu is being weak today. :( I'm not an expert, so the following may not be exactly correct. As I understand it, when you hit a key on the keyboard, it sends the character you typed to the operating system. (The OS can then remap keys, generate keyboard events including a timestamp, etc.) Hit the J key, and the event includes character "j". Hit Shift-J, and character "J" is sent. Hit Ctrl-J, and the character sent is the ASCII control character ^J, or newline. (Technically, the name for ASCII 10 is "linefeed" rather than "newline".) Similarly, other control character combinations send other control codes: ^A = ASCII 0x01 Start Of Heading ^L = ASCII 0xFF Formfeed \f ^M = ASCII 0x0D Carriage Return \r etc. http://en.wikipedia.org/wiki/C0_and_C1_control_codes When readline is enabled in bash, one of the standard editing commands is that C-q (usually ctrl-Q on the keyboard) instructs readline to treat the next key as a literal. So Ctrl-Q followed by Backspace won't delete the previous character, but insert a literal DEL 0x7F character. (One of those historical quirks is that on most(?) keyboards, the Backspace key generates a DEL character rather than the ^H backspace control code, and the Delete key generates an escape sequence. Go figure.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 2012-11-06 23:52, Ian Kelly wrote:
On Tue, Nov 6, 2012 at 3:41 PM, Andrew Robinson
wrote:
Q: What about other mutable objects like sets or dicts?
A: No, the elements are never copied.
They aren't list multiplication compatible in any event! It's a total
nonsense objection.
If these are inconsistent in my idea -- OBVIOUSLY -- they are inconsistent
in Python's present implementation. You can't even reference duplicate them
NOW.
{ 1:'a', 2:'b', 3:'c' } * 2
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for *: 'dict' and 'int'
The objection is not nonsense; you've merely misconstrued it. If
[[1,2,3]] * 4 is expected to create a mutable matrix of 1s, 2s, and
3s, then one would expect [[{}]] * 4 to create a mutable matrix of
dicts. If the dicts are not copied, then this fails for the same
reason
Q: How about if I use delegation to proxy a list?
A: Oh no, they definitely won't be copied.
Give an example usage of why someone would want to do this. Then we can
discuss it.
Seriously? Read a book on design patterns. You might start at SO:
http://stackoverflow.com/questions/832536/when-to-use-delegation-instead-of-inheritance
Losing consistency in favour of saving a few characters for something as
uncommon as list multiplication is a poor tradeoff. That's why this
proposal has been rejected again and again and again every time it has
been suggested.
Please link to the objection being proposed to the developers, and their
reasoning for rejecting it.
I think you are exaggerating.
From Google:
http://bugs.python.org/issue1408
http://bugs.python.org/issue12597
http://bugs.python.org/issue9108
http://bugs.python.org/issue7823
Note that in two out of these four cases, the reporter was trying to
multiply lists of dicts, not just lists of lists.
Besides, 2D arrays are *not* rare and people *have* to copy internals of
them very often.
The copy speed will be the same or *faster*, and the typing less -- and the
psychological mistakes *less*, the elegance more.
List multiplication is not potentially useful for copying 2D lists,
only for initializing them. For copying an existing nested list,
you're still stuck with either copy.deepcopy() or a list
comprehension.
It's hardly going to confuse anyone to say that lists are copied with list
multiplication, but the elements are not.
Every time someone passes a list to a function, they *know* that the list is
passed by value -- and the elements are passed by reference. People in
Python are USED to lists being "the" way to weird behavior that other
languages don't do.
Incorrect. Python uses what is commonly known as call-by-object, not
call-by-value or call-by-reference. Passing the list by value would
imply that the list is copied, and that appends or removes to the list
inside the function would not affect the original list. This is not
what Python does; the list inside the function and the list passed in
are the same list. At the same time, the function does not have
access to the original reference to the list and cannot reassign it by
reassigning its own reference, so it is not call-by-reference
semantics either.
I prefer the term "reference semantics".
--
http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
On Tue, 06 Nov 2012 23:14:40 +, Steven D'Aprano wrote: > On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote: > >> I have just finished a 251 line bash shell script that builds my linux >> distro from scratch. > > "From scratch"? So if you run it on bare metal with no OS, it works? It has a host system for build/bootstraping. Then it goes onto an USB drive, both as the OS and installation packages (with package manager) capable of install on a system without an OS. Hard drive needed ;) > > But seriously -- bash is a mature, powerful shell. It works well for > what it does. It has been designed to make it easy[1] to automate system > admin tasks. It would be astonishing if an experienced, competent bash > programmer couldn't write an installation tool in bash. By comparison, > few general purpose programming languages (with the obvious exception of > perl) are designed for system administration as their primary purpose. > > But... how robust is your script? How many bugs does it contain? Chances > are you will only use it a handful of times, on the same system. That's > not a lot of testing to be sure that it is free of bugs, and robust > against unexpected input. I have used it for several years and others have used it to build their own systems. I have used it on 586 to the latest multi core systems. > > Hell, even widely used and distributed install scripts written by > companies with the resources of Ubuntu and Red Hat have a distressing > tendency to break. Or worse, to behave in unexpected ways. I am not Redhat or Ubuntu (commercial distros stink) ;) > > Unless you are some sort of bash-scripting über-geek superhero with > powers beyond those of mortal men, chances are that your script is much > more buggy and fragile than you imagine. How well does it recover from > errors? It stops on all critical build errors and skips the package on minimal errors, giving me a list of skipped packages and status on them at the end of the build sequence (so I can fix my errors). It will also download the source package if it is not present in the build directory. If I incur any breakage/error ( it can happen a lot ) it stops and notifies me. I then fix the package build script and lather/rinse/repeat until I get the package build correct. It logs all the information into build/testing/file listing/dependency requirements into log files. Then the package goes off to a repository holding all the other packages. The directory layout is like this: build +--section - programming/X window etc +package - python gcc coreutils and contains the build script ( bash script ) and source package. The build system ( bash scripts ) recurses this directory structure build the packages and placing them into repository +-base - base system packages kernel coreutils etc +-extra - programming packages, xorg etc here The package manager (written in C) then looks to the repository to install/update from the repository. > Does it leave you with a broken system, half installed? No. It builds all of the packages and then creates binary/devel packages to be installed a new system. The finished packages go into a repository. If I update a package only that package is built and placed into the repository so all machine can be updated by my package manager. And yes the build script automatically takes care of all build dependencies as well as installed binary dependencies for the host installs. It will even build itself. >How easily can you maintain it after three months? Will it work in the > presence of filenames with newlines in them? I have maintained it for 8 years, and it can and does handle file names with spaces, any valid *nix file name character can be used. > > > > [1] For some definition of "easy". In my opinion, control structures > like "for" and "if" in bash are hard to use, hard to read, easy to get > wrong, give cryptic error messages when you do get them wrong, and are > ugly. Tests are obfuscated, and as always, the fact that everything is > text in bash means it is way harder than it needs to be to use rich, > modern data structures. Only from a certain points of view. I use many for loops and no if statements. There is a good alternate for if, easily understandable if you know C and boolean logic. My background is in C and Delphi/Pascal and I didn't have problems with bash scripting. I want to have a go at python. Arch linux "pacman package management/build/delevopment system" is very similar to mine. If you wish to take a look at it. It is also mostly bash scripts with some C and python2/3 to boot. -- http://mail.python.org/mailman/listinfo/python-list
multiprocessing help
I'm looking for some help with multiprocessing. Essentially what I'm trying to do is the following: 1. create a main process that gets daemonized 2. spawn two subprocess that live for the life of the daemon 3. each subprocess creates children that do heavy work and exit when the work is done I am not having issues with creating the processes but I can't get them to die. Sometimes it works and they all die and sometimes they don't. Obviously I do not understand the multiprocessing documentation so I'm hoping that somebody can point out what I'm doing wrong. I also understand that my code might be strict adherence to PEP8 and there might be a number of flaws with the code; all of which would be helpful to know, but I'm particularly looking for help with getting what I'm trying to do to work. I'm starting to lose my mind.. I just want to say all processes that spawned from here $@%@$% DIE. Thanks in advance for anybody that has some spare time to point me in the right direction. I am grateful. Thanks. Very Respectfully, Stephen Bunn [email protected] sqlimport.py Description: Binary data daemon.py Description: Binary data maindaemon.py Description: Binary data -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Tue, 06 Nov 2012 14:41:24 -0800, Andrew Robinson wrote: > Yes. But this isn't going to cost any more time than figuring out > whether or not the list multiplication is going to cause quirks, itself. > Human psychology *tends* (it's a FAQ!) to automatically assume the > purpose of the list multiplication is to pre-allocate memory for the > equivalent (using lists) of a multi-dimensional array. Note the OP even > said "4d array". I'm not entirely sure what your point is here. The OP screwed up -- he didn't generate a 4-dimensional array. He generated a 2-dimensional array. If his intuition about the number of dimensions is so poor, why should his intuition about list multiplication be treated as sacrosanct? As they say, the only truly intuitive interface is the nipple. There are many places where people's intuition about programming fail. And many places where Fred's intuition is the opposite of Barney's intuition. Even more exciting, there are places where people's intuition is *inconsistent*, where they expect a line of code to behave differently depending on their intention, rather than on the code. And intuition is often sub-optimal: e.g. isn't it intuitively obvious that "42" + 1 should give 43? (Unless it is intuitively obvious that it should give 421.) So while I prefer intuitively obvious behaviour where possible, it is not the holy grail, and I am quite happy to give it up. > The OP's original construction was simple, elegant, easy to read and > very commonly done by newbies learning the language because it's > *intuitive*. His second try was still intuitive, but less easy to read, > and not as elegant. Yes. And list multiplication is one of those areas where intuition is suboptimal -- it produces a worse outcome overall, even if one minor use- case gets a better outcome. I'm not disputing that [[0]*n]*m is intuitively obvious and easy. I'm disputing that this matters. Python would be worse off if list multiplication behaved intuitively. An analogy: the intuitively obvious thing to do with a screw is to bang it in with a hammer. It's long, thin, has a point at the end, and a flat head that just screams "hit me". But if you do the intuitive thing, your carpentry will be *much worse* than the alternatives -- a hammered in screw holds much less strongly than either a nail or a screwed in screw. The surface area available for gripping is about 2% compared to a nail and about 0.01% compared to a screw used correctly. Having list multiplication copy has consequences beyond 2D arrays. Those consequences make the intuitive behaviour you are requesting a negative rather than a positive. If that means that newbie programmers have to learn not to hammer screws in, so be it. It might be harder, slower, and less elegant to drill a pilot hole and then screw the screw in, but the overall result is better. >> * Consistency of semantics is better than a plethora of special >>cases. Python has a very simple and useful rule: objects should not >>be copied unless explicitly requested to be copied. This is much >>better than having to remember whether this operation or that >>operation makes a copy. The answer is consistent: > > Bull. Even in the last thread I noted the range() object produces > special cases. > >>> range(0,5)[1] > 1 > >>> range(0,5)[1:3] > range(1, 3) What's the special case here? What do you think is copied? You take a slice of a tuple, you get a new tuple. You take a slice of a list, you get a new list. You take a slice of a range object, you get a new range object. I'm honestly not getting what you think is inconsistent about this. > The principle involved is that it gives you what you *usually* want; Who is the "you" that decides what "you" usually want? And how do they know what is "usual"? Two-dimensional arrays in Python using lists are quite rare. Anyone who is doing serious numeric work where they need 2D arrays is using numpy, not lists. There are millions of people using Python, so it's hardly surprising that once or twice a year some newbie trips over this. But it's not something that people tend to trip over again and again and again, like C's "assignment is an expression" misfeature. > I read some of the documentation on why Python 3 chose to implement it > this way. What documentation is this? Because this is a design decision that goes all the way back to at least Python 1.5: [steve@ando ~]$ python1.5 Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> x = [[0]*5]*3 >>> x[0][1] = 99 >>> x [[0, 99, 0, 0, 0], [0, 99, 0, 0, 0], [0, 99, 0, 0, 0]] So I expect the design decision for Python 3 was "we made the right decision before, there's no need to change it". >>(pardon me for belabouring the point here) >> >> Q: Does [0]*10 make ten copies of the integer object? A: No, list >> mult
Re: Base class and Derived class question
On Nov 7, 1:08 am, [email protected] wrote: > Just got answer, I didn't call a class it's self. Correct code is: > class derivedClass(baseClassMod.baseClass): > def .. Incidentally, this is why it's recommended to give modules lowercase names - baseclass - and classes camelcased ones - BaseClass. It makes it more obvious to what you're holding a reference. -- http://mail.python.org/mailman/listinfo/python-list
How to specify a field name dynamically
I have three tables: table1 |———| | id | f1 | |———| table2 |———| | id | f2 | |———| table3 |———| | id | f3 | |———| I want define a function to insert records to someone,but I don't know how to specify a field name dynamically. I had a try like this /def insert_record(table, field, goods):// //return db.insert(table, field=goods//)/ or /def insert_record(table, **kv):// //return db.insert(table, **kv)/ but it does not works -- http://mail.python.org/mailman/listinfo/python-list
Re: How to specify a field name dynamically
On 11/06/2012 10:14 PM, jack wrote: > I have three tables: What's a table? I'll assume you're using Python, but what version, and what extra libraries do you have installed ? At least show your import statements, so we might have a chance at guessing. I'll assume the db stands for database, but what database, or what library??? if it really is a database question, and you specify what library you're using, then maybe somebody who uses that will jump in. > table1 > |———| > | id | f1 | > |———| > > table2 > |———| > | id | f2 | > |———| > > table3 > |———| > | id | f3 | > |———| > > > I want define a function to insert records to someone,but I don't know > how to specify a field name dynamically. > I had a try like this > > / def insert_record(table, field, goods):// > // return db.insert(table, field=goods//)/ > or > / def insert_record(table, **kv):// > // return db.insert(table, **kv)/ > > but it does not works > That's not much of a clue. Do you mean you get an exception? If so, paste it into a message, the full traceback. Or you mean it returns the wrong data? Or it crashes your OS? My first guess would be that those slashes are causing syntax errors. But if that's a bug in your OS's copy/paste, then I'd say you have indentation problems. Or maybe these are not just functions, but methods inside a class. And in that case, I might guess that you're missing the self argument, and therefore getting an exception of wrong number of arguments. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing help
On 11/6/2012 7:52 PM, Stephen Bunn wrote: I'm looking for some help with multiprocessing. Questions about using Python go to python-list. python-dev is for developing future versions of Python. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing help
On 11/6/2012 11:04 PM, Terry Reedy wrote: On 11/6/2012 7:52 PM, Stephen Bunn wrote: I'm looking for some help with multiprocessing. Questions about using Python go to python-list. python-dev is for developing future versions of Python. My apologies. I intended to and thought I had opened python-dev (as gmane newsgroup) and clicked send a couple of seconds too soon (or realized my mistake a couple of seconds too late). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Nov 7, 5:26 am, MRAB wrote: > I prefer the term "reference semantics". Ha! That hits the nail on the head. To go back to the OP: On Nov 5, 11:28 am, Demian Brecht wrote: > So, here I was thinking "oh, this is a nice, easy way to initialize a 4D > matrix" (running 2.7.3, non-core libs not allowed): > > m = [[None] * 4] * 4 > > The way to get what I was after was: > > m = [[None] * 4, [None] * 4, [None] * 4, [None * 4]] > > (Obviously, I could have just hardcoded the initialization, but I'm too lazy > to type all that out ;)) > > The behaviour I encountered seems a little contradictory to me. [None] * 4 > creates four distinct elements in a single array while [[None] * 4] * 4 > creates one distinct array of four distinct elements, with three references > to it: > > >>> a = [None] * 4 > >>> a[0] = 'a' > >>> a > > ['a', None, None, None] > > >>> m = [[None] * 4] * 4 > >>> m[0][0] = 'm' > >>> m > > [['m', None, None, None], ['m', None, None, None], ['m', None, None, None], > ['m', None, None, None]] > > Is this expected behaviour and if so, why? In my mind either result makes > sense, but the inconsistency is what throws me off. > m=[[None] * 2] * 3 is the same as m=[[None]*2, [None]*2, [None]*2] until one starts doing things like m[0][0] = 'm' So dont do it! And to get python to help you by saying the same that I am saying do m=((None) * 2) * 3 (well almost... its a bit more messy in practice) m=(((None,) * 2),)*3 After that try assigning to m[0][0] and python will kindly say NO! tl;dr version: reference semantics is ok assignment is ok (well up to a point) assignment + reference semantics is not -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Wed, 07 Nov 2012 00:23:44 +, MRAB wrote: >> Incorrect. Python uses what is commonly known as call-by-object, not >> call-by-value or call-by-reference. Passing the list by value would >> imply that the list is copied, and that appends or removes to the list >> inside the function would not affect the original list. This is not >> what Python does; the list inside the function and the list passed in >> are the same list. At the same time, the function does not have access >> to the original reference to the list and cannot reassign it by >> reassigning its own reference, so it is not call-by-reference semantics >> either. >> > I prefer the term "reference semantics". Oh good, because what the world needs is yet another name for the same behaviour. - call by sharing - call by object sharing - call by object reference - call by object - call by value, where "values" are references (according to the Java community) - call by reference, where "references" refer to objects, not variables (according to the Ruby community) - reference semantics Anything else? http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
In article <[email protected]>, Steven D'Aprano wrote: > On Wed, 07 Nov 2012 00:23:44 +, MRAB wrote: > > >> Incorrect. Python uses what is commonly known as call-by-object, not > >> call-by-value or call-by-reference. Passing the list by value would > >> imply that the list is copied, and that appends or removes to the list > >> inside the function would not affect the original list. This is not > >> what Python does; the list inside the function and the list passed in > >> are the same list. At the same time, the function does not have access > >> to the original reference to the list and cannot reassign it by > >> reassigning its own reference, so it is not call-by-reference semantics > >> either. > >> > > I prefer the term "reference semantics". > > > Oh good, because what the world needs is yet another name for the same > behaviour. > > - call by sharing > - call by object sharing > - call by object reference > - call by object > - call by value, where "values" are references > (according to the Java community) > - call by reference, where "references" refer to objects, not variables > (according to the Ruby community) > - reference semantics > > > Anything else? > > http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing Call by social network? The called function likes the object. Depending on how it feels, it can also comment on some of the object's attributes. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to specify a field name dynamically
On 2012/11/7 11:36, Dave Angel wrote:
On 11/06/2012 10:14 PM, jack wrote:
I have three tables:
What's a table? I'll assume you're using Python, but what version, and
what extra libraries do you have installed ? At least show your import
statements, so we might have a chance at guessing. I'll assume the db
stands for database, but what database, or what library??? if it really
is a database question, and you specify what library you're using, then
maybe somebody who uses that will jump in.
yeah, I'm sorry for that I didn't offer enough information about my
question.
table1
|———|
| id | f1 |
|———|
table2
|———|
| id | f2 |
|———|
table3
|———|
| id | f3 |
|———|
I want define a function to insert records to someone,but I don't know
how to specify a field name dynamically.
I had a try like this
/ def insert_record(table, field, goods)://
// return db.insert(table, field=goods//)/
or
/ def insert_record(table, **kv)://
// return db.insert(table, **kv)/
but it does not works
That's not much of a clue. Do you mean you get an exception? If so,
paste it into a message, the full traceback. Or you mean it returns the
wrong data? Or it crashes your OS?
My first guess would be that those slashes are causing syntax errors.
But if that's a bug in your OS's copy/paste, then I'd say you have
indentation problems. Or maybe these are not just functions, but methods
inside a class. And in that case, I might guess that you're missing the
self argument, and therefore getting an exception of wrong number of
arguments.
# I want to insert something to a database using web.py-0.37 & mysql.
/import web//
//db = web.database(dbn='mysql', user='username', passwd='password',
db='test'//)/
# I found the tables I created have similar structure,so I wanted
define one function to serve all tables
/ create table if not exists table1(id integer auto_increment primary
key, num integer, table1_cxt text);//
//create table if not exists table2(id integer auto_increment
primary key, num integer, table2_cxt text);//
//create table if not exists table3(id integer auto_increment
primary key, num integer, table3_cxt text);/
# I known that:
/def insert_record(num=None, table1_cxt=None)://
//db.insert('table1', num=num, table1_cxt=table1_cxt ) /
so I think have some way to pass args instead of the hard code('table1',
table1_cxt).
///def insert_record(table, num, field, goods): //
return db.insert(table, num=num, field=goods)/
this is my way.I do a experiment:
///>>> def func(arg1 = 'None', arg2 = 'None')://
//... print arg1//
//... print arg2//
//...//
//>>> def func1(a1, a2, v1, v2)://
//... func(a1=v1, a2=v2)//
//...
//>>> func1('arg1', 'arg2', 3, 4)//
//Traceback (most recent call last)://
// File "", line 1, in //
// File "", line 2, in func1//
//TypeError: func() got an unexpected keyword argument 'a1'
/obviously, it's wrong.
**kv works for me:
/>>> def func1(**kv)://
//... func(**kv)//
>>> func1(arg1='123', arg2='456')//
//123//
//456/
Maybe it's right, so I should change before saying
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
Roy Smith wrote: Call by social network? The called function likes the object. Depending on how it feels, it can also comment on some of the object's attributes. And then finds that it has inadvertently shared all its private data with other functions accessing the object. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
If anything is to be done in this area, it would be better as an extension of list comprehensions, e.g. [[None times 5] times 10] which would be equivalent to [[None for _i in xrange(5)] for _j in xrange(10)] -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Coordination between developers in the Python project
Ian Kelly wrote: Although I find it a bit easier to just use something like unshorten.com, which is the first Google hit for "url unshortener". Assuming that you trust that site to not be hosting malware itself. :-) Ah yes, beware the Hungarian unshortening service that redirects every request to a random porn page. They will plead incompetence, of course. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
Steven D'Aprano wrote: The downside is that if spaces are not argument separators, then you need something else to be an argument separator. Or you need argument delimiters. Or strings need to be quoted. Programming languages do these things because they are designed to be correct. Shell do not because they are designed for lazy users and merely aim to be "good enough". That's overly judgemental. In the environment where shells originated, not being able to easily put spaces in file names wasn't considered a problem. File names weren't thought of as names in the natural language sense, but as identifiers in the programming sense. You don't complain that you can't put spaces in identifiers in a Python program, do you? No, because that would require all identifiers to be quoted somehow, which would drive you crazy. In the same way, requiring all filenames to be quoted would drive shell users crazy. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
In article , Gregory Ewing wrote: > Steven D'Aprano wrote: > > The downside is that if spaces are not argument separators, then you need > > something else to be an argument separator. Or you need argument > > delimiters. Or strings need to be quoted. Programming languages do these > > things because they are designed to be correct. Shell do not because they > > are designed for lazy users and merely aim to be "good enough". > > That's overly judgemental. In the environment where shells originated, > not being able to easily put spaces in file names wasn't considered a > problem. File names weren't thought of as names in the natural language > sense, but as identifiers in the programming sense. > > You don't complain that you can't put spaces in identifiers in a > Python program, do you? No, because that would require all identifiers > to be quoted somehow, which would drive you crazy. In the same way, > requiring all filenames to be quoted would drive shell users crazy. On the other hand, if you *wanted* to put a space in a Python identifier, you just can't. If you want to put a space in a file name in the shell, all you need do is put spaces around the name. Or, if you prefer, escape the space with a backslash. Oh, wait. This blows my mind... >>> f = Foo() >>> setattr(f, "x y", "xyz") >>> dir(f) ['__doc__', '__module__', 'x y'] I did not expect this to work. Not quite sure what I've created here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging output to be redirected to a particular folder
Thanks ...this works perfectly fine now. On Tuesday, November 6, 2012 11:28:46 PM UTC+5:30, Prasad, Ramit wrote: > Dennis Lee Bieber wrote: > > > > > > On Tue, 06 Nov 2012 13:26:11 +0100, Peter Otten <[email protected]> > > > declaimed the following in gmane.comp.python.general: > > > > > > > [email protected] wrote: > > [snip] > > > > > def main(): > > > > >logging.basicConfig(Filename='c://myapp.log', level=logging.ERROR) > > > > > > > > Python is case-sensitive. Try: > > > > > > > > logging.basicConfig(filename='c://myapp.log', level=logging.ERROR) > > > > > > > The double forward slashes might also be confusing... At the least, > > > unneeded... > > > > > > >>> import os.path > > > >>> print os.path.normpath("c://somefile.log") > > > c:\somefile.log > > > >>> print os.path.normpath("c:\\somefile.log") > > > c:\somefile.log > > > >>> print os.path.normpath("c:\\tryfile.log") > > > c:\tryfile.log > > > >>> print os.path.normpath("c:\tryfile.log") > > > c: ryfile.log > > > >>> print os.path.normpath("c:/tryfile.log") > > > c:\tryfile.log > > > >>> > > > > > > Doubling back-slashes is needed to avoid the problem of literal > > > escapes corrupting the intent... > > > > Or use the raw literal form r"c:\tryfile.log". I know several > > people that prefer to use forward slashes as it works in both > > Windows and *nix. > > > > > > ~Ramit > > > > > > This email is confidential and subject to important disclaimers and > > conditions including on offers for the purchase or sale of > > securities, accuracy and completeness of information, viruses, > > confidentiality, legal privilege, and legal entity disclaimers, > > available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On 2012-11-06, at 5:55 PM, Steven D'Aprano wrote: > I'm not entirely sure what your point is here. The OP screwed up -- he > didn't generate a 4-dimensional array. He generated a 2-dimensional > array. If his intuition about the number of dimensions is so poor, why > should his intuition about list multiplication be treated as sacrosanct? Yep, I may have mis-worded the explanation a bit (although I *did* express that it was a 4D matrix in the OP). I was using a 2D list to represent a 4D matrix in order to easily iterate over 90 degree rotations with zip(*matrix[::-1]). It wasn't for production code (otherwise I *would* be using numpy), it was for an online programming challenge in which external libs are not supported. > As they say, the only truly intuitive interface is the nipple. There are > many places where people's intuition about programming fail. And many > places where Fred's intuition is the opposite of Barney's intuition. I couldn't agree more with this. My question was *not* based on what I perceive to be intuitive (although most of this thread has now seemed to devolve into that and become more of a philosophical debate), but was based on what I thought may have been inconsistent behaviour (which was quickly cleared up with None being immutable and causing it to *seem* that the behaviour was inconsistent to the forgetful mind). As you touch on here, "intuition" is entirely subjective. If you're coming from a C/C++ background, I'd think that your intuition would be that everything's passed by value unless explicitly stated. Someone coming from another background (Lua perhaps?) would likely have entirely different intuition. > So while I prefer intuitively obvious behaviour where possible, it is not > the holy grail, and I am quite happy to give it up. I fail to see where there has been any giving up on intuitiveness in the context of this particular topic. In my mind, intuitiveness is generally born of repetitiveness and consistency. As everything in Python is a reference, it would seem to me to be inconsistent to treat expressions such as [[obj]*4]*4 un-semantically (Pythonically speaking) and making it *less* intuitive. I agree that Python would definitely be worse off. Demian Brecht @demianbrecht http://demianbrecht.github.com -- http://mail.python.org/mailman/listinfo/python-list
