Re: Script suddenly stops
Chris writes: > I'm trying to read ten 200 MB textfiles into a MySQL MyISAM database > (Linux, ext4). The script output is suddenly stopping, while the Python > process is still running (or should I say sleeping?). It's not in top, > but in ps visible. > > Why is it stopping? Is there a way to make it continue, without calling > "kill -9", deleting the processed lines and starting it again? This is difficult to say (from the distance). I would approach an analysis in the following way: * use a Python with debug symbols (OS provided Python installations usually lack debugging symbols; a manually generated Python usually has those symbols) * run your script unter "gdb" control (the C level debugger) * when you see that your script starts "sleeping", hit "CTRL-C" in the "gdb" session * use "gdb" commands - maybe combined with the special python commands for "gdb" to learn where the "sleeping" happens. These special Python commands allow you to use the C level debugger "gdb" to get information about the Python level. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, May 30, 2014 at 4:20 PM, Steven D'Aprano wrote: >> It's on par with creating a file with a name beginning with a >> hyphen, and then fiddling around with various commands as you try to >> manipulate it (tip: "rm ./-r" works); programs will happily interpret >> "-r" as an option rather than a file name, without being concerned that >> it's technically legal. > > I don't see any connection between the two. -r is a valid file name, just as . is a valid line of input. But with the rm command, you can't provide it with -r as a file name - you have to use ./-r or somesuch, because the parser gets to it first. That's the connection. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Fri, May 30, 2014 at 4:04 PM, Rustom Mody wrote: > I thought when one signs up for python one has to sign an affidavit > saying: > "I shall not write one-liners\n" * 100 Certainly not. I write all my list comps on one line! *ducking for cover* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 2014-05-29 22:40:36 +, Travis Griggs said: I use either vim or textwrangler for simple one file scripts. Since you're on OS X have a look at Exedore, it's paid but very cheap. It aims at providing a beautiful interface, I fetched the free trial a couple days ago and the job so far is impressively neat. I'm not related to the project, I just found it by accident and want to give Cocoa-credit where credit is due. -- Andrea -- https://mail.python.org/mailman/listinfo/python-list
Re: Script suddenly stops
Chris wrote:
> Dear All,
>
> I'm trying to read ten 200 MB textfiles into a MySQL MyISAM database
> (Linux, ext4). The script output is suddenly stopping, while the Python
> process is still running (or should I say sleeping?). It's not in top,
> but in ps visible.
>
> Why is it stopping? Is there a way to make it continue, without calling
> "kill -9", deleting the processed lines and starting it again?
>
> Thank you in advance.
>
>
>
> [1] http://pastebin.com/CxHCA9eB
>
> #!/usr/bin/python
>
> import MySQLdb, pprint, re
> db = None
> daten = "/home/chris/temp/data/data/"
> host = "localhost"
> user = "data"
> passwd = "data"
> database = "data"
> table = "data"
>
> def connect_mysql():
> global db, host, user, passwd, database
> db = MySQLdb.connect(host, user, passwd, database)
> return(db)
>
>
> def read_file(srcfile):
> lines = []
> f = open(srcfile, 'r')
> while True:
> line = f.readline()
> #print line
> lines.append(line)
> if len(line) == 0:
> break
> return(lines)
The read_file() function looks suspicious. It uses a round-about way to read
the whole file into memory. Maybe your system is just swapping?
Throw read_file() away and instead iterate over the file directly (see
below).
> def write_db(anonid, query, querytime, itemrank, clickurl):
> global db, table
> print "write_db aufgerufen."
> cur = db.cursor()
> try:
> cur.execute("""INSERT INTO data
(anonid,query,querytime,itemrank,clickurl) VALUES (%s,%s,%s,%s,%s)""",
(anonid,query,querytime,itemrank,clickurl))
> db.commit()
> except:
> db.rollback()
>
>
> def split_line(line):
> print "split_line called."
> print "line is:", line
> searchObj = re.split(r'(\d*)\t(.*)\t([0-9: -]+)\t(\d*)\t([A-Za-
z0-9._:/ -]*)',line, re.I|re.U)
> return(searchObj)
>
>
>
> db = connect_mysql()
> pprint.pprint(db)
with open(daten + "test-07b.txt") as lines:
for line in lines:
result = split_line(line)
write_db(result[1], result[2], result[3], result[4], result[5])
> db.close()
Random remarks:
- A bare except is evil. You lose valuable information.
- A 'global' statement is only needed to rebind a module-global variable,
not to access such a variable. At first glance all your 'global'
declarations seem superfluous.
- You could change the signature of write_db() to accept result[1:6].
- Do you really need a new cursor for every write? Keep one around as a
global.
- You might try cur.executemany() to speed things up a bit.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
Rustom Mody wrote:
> On Friday, May 30, 2014 12:15:46 PM UTC+5:30, Rustom Mody wrote:
>> Heres a (pr) approx
>>
>> $ python -c 'import os, pprint; pprint.pprint ([ r for r, d, f in
>> os.walk(".") if len(d+f) != 1])'
>
> Without pprint: (pooor)
>
> python -c 'import os; print "\n".join([ r for r, d, f in os.walk(".") if
> len(d+f) != 1])'
>
> Or (poor)
>
> python -c 'from os import walk; print "\n".join([ r for r, d, f in
> walk(".") if len(d+f) != 1])'
If there are a lot of matching folders:
$ python -c 'import os, sys; sys.stdout.writelines(p + "\n" for p, f, n in
os.walk(".") if len(n+f) == 1)'
With a little help from the shell:
$ echo -e "import os\nfor p, f, n in os.walk('.'):\n if len(f+n) == 1:
print(p)" | python
--
https://mail.python.org/mailman/listinfo/python-list
Re: PythonCE successfully inst'ed, but scripts don't work. Please help.
On Fri, May 30, 2014 at 1:12 PM, Abdullah Indorewala wrote: > Hi, > > I know you posted this 15 years ago but I recently stumbled across your post > here : > > https://mail.python.org/pipermail/python-list/1999-May/018340.html > > And I am in the same situation (kind of). I can’t get Python to install on my > MobilePro 770 running Windows CE 3.0. Are you still available? Is this e-mail > even valid? I know I’m just some random person on the internet but I need > your help in installing Python to my MobilePro 770. Any help would be > appreciated. > Well... you've reached a valid and current mailing list (mirrored to the comp.lang.python newsgroup), and there's plenty of activity here. But I don't know if anyone here uses WinCE, nor if anyone has the exact version of hardware you're using. So it's probably easiest to just set the previous post aside and start fresh, with details like: 1) What version of Python are you trying to install? 2) What version of Windows? (You already answered that, above; according to Wikipedia, the MobilePro 770 came with WinCE 2.11, so I'm guessing that's been upgraded.) 3) What happens when you try to install? I don't think Win CE is an officially-supported platform, so it's entirely possible you'll have problems with the standard installers. There is, however, a dedicated third-party port at http://pythonce.sourceforge.net/ , which I found by simple Google search for 'python wince'. That might help you, and if not, come back with more info and maybe someone can help out. Good luck! I'm pretty sure "WinCE" is appropriately named after the facial sign of distress. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how avoid delay while returning from C-python api?
Yes, Cython looks easier but the problem its a very old code ( 6 or 7 years ). Almost entire code base uses plain python-c api. Thanks for the example, will use Cython or Ctypes way for side-projects! Cheers, Lakshmipathi.G FOSS Programmer. www.giis.co.in/readme.html -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 2014-05-30 07:21:52 +, Andrea D'Amore said: It aims at providing a beautiful interface, Side note: the text editing is still green. -- Andrea -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, 30 May 2014 17:19:00 +1000, Chris Angelico wrote: > On Fri, May 30, 2014 at 4:20 PM, Steven D'Aprano > wrote: >>> It's on par with creating a file with a name beginning with a hyphen, >>> and then fiddling around with various commands as you try to >>> manipulate it (tip: "rm ./-r" works); programs will happily interpret >>> "-r" as an option rather than a file name, without being concerned >>> that it's technically legal. >> >> I don't see any connection between the two. > > -r is a valid file name, just as . is a valid line of input. But with > the rm command, you can't provide it with -r as a file name - you have > to use ./-r or somesuch, because the parser gets to it first. That's the > connection. The analogy doesn't quite match, because rm, like all shell commands, does it's own argument parsing, whereas Python operators do not. But putting that aside, the parser's rule is "arguments starting with a dash are treated as options". That's *standard behaviour*. If you want to override that standard behaviour, you have to tweak the command: rm -f ./-r /tmp/* Some commands accept a single dash to mean "no more options following this". Assuming rm does the same: rm -f - -r /tmp/* Either way, it is the standard behaviour as defined by rm, and so expected. That makes this the equivalent of Python's rule that dot behaves somewhat like an operator, and that a dot on its own is legal any place a bare binary operator is legal. The analogy to "the REPL is allowed to modify standard syntax to make a bare dot special" would be something like: the shell is allowed to pre-process the command line, so that -r on a line on its own like this: rm -f \ -r \ /tmp/* which otherwise would have been treated as `rm -f -r /tmp/*`, is instead turned into `rm -f ./-r /tmp/*`. Reading the rm man page won't tell you this, because it happens outside of rm, just as reading the Python documentation won't tell you about the tricks your hypothetical REPL does to otherwise legal syntax. rm doesn't know what tricks your hypothetical shell might do, and neither can the Python parser tell what tricks your hypothetical REPL might do. Both see only what the shell give them. This is why I'm so adamant that, while REPLs may be permitted to introduce *new* syntax which is otherwise illegal to the Python parser, (e.g. like IPython's %magic and !shell commands) they *must not* change the meaning of otherwise legal Python syntax. It's simply a bad idea to have legal Python code mean different things depending on what environment you're running it in. (As I mentioned before, the annoying "blank line closes all open blocks" rule gets an exception simply because I don't believe there is any practical alternative.) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, May 30, 2014 at 9:27 PM, Steven D'Aprano wrote: > This is why I'm so adamant that, while REPLs may be permitted to > introduce *new* syntax which is otherwise illegal to the Python parser, > (e.g. like IPython's %magic and !shell commands) they *must not* change > the meaning of otherwise legal Python syntax. It's simply a bad idea to > have legal Python code mean different things depending on what > environment you're running it in. Hmm. I'm not sure that "raises SyntaxError" is any less a part of the language's promise than "evaluates to twice the value of x" is. Would you, for instance, permit the REPL to define a new __future__ directive, on the basis that it's invalid syntax currently? >>> from __future__ import magic_command_history SyntaxError: future feature magic_command_history is not defined I don't think SyntaxError equates to "invitation to make changes". Also, consider: >>> for i in range(5): i*3+2 2 5 8 11 14 If you do this in a script, it's perfectly legal, but won't print anything. So the REPL is already "chang[ing] the meaning of otherwise legal Python syntax", and what's more, it's making None into a special case: >>> for i in range(5): None if i%2 else i 0 2 4 Practicality beats purity. If it's more useful to the end user for something valid-but-illogical to have a new bit of meaning in interactive mode, I say go for it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Thu, 29 May 2014 15:11:31 -0500, Mark H Harris wrote: > On 5/29/14 11:44 AM, Paul Rudin wrote: >> Terry Reedy writes: >>> I am curious how many of the editors people have been recommending >>> have all of the following Idle features, that I use constantly. >>> >>> 1. Run code in the editor with a single keypress. >>> >>> 2. Display output and traceback in a window that lets you jump from >>> the any line in the traceback to the corresponding file and line, >>> opening the file if necessary. >>> >>> 3. Search unopened files (grep) for a string or re. >>> >>> 4. Display grep output in a window that lets you jump from any 'hit' >>> to the corresponding file and line, opening the file if necessary. >> >> Emacs. >> >> > Emacs is the coolest tech editor out there, by far; however, the very > nature of Emacs (which makes it the coolest) is also unfortunately the > very thing that sucks about it... highly configurable (&extensible), > highly complex, intricately complicated; especially for novices. > > The OP is looking for an "IDE-like" interactive environment, because he > is "uncomfortable" with IDLE. IDLE is THE choice, however ---precisely > because IDLE is clean, elegant, and most importantly "simple". It is > simple to understand, and it is even simpler to use effectively... even > for novice pythonics. IDLE is straight-forward. > > As Terry pointed out, IDLE is very useful and functional. And in the > modern python world is also very stable (IDLE used to get a black eye > because it had snags early-on). Today IDLE works, has great features, > and actually helps new users get on-board with Python. > > marcus The only thing missing form emacs is a good text editor ;-) -- Chemist who falls in acid will be tripping for weeks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 12:50:31 PM UTC+5:30, Chris Angelico wrote:
> On Fri, May 30, 2014 at 4:04 PM, Rustom Mody wrote:
> > I thought when one signs up for python one has to sign an affidavit
> > saying:
> > "I shall not write one-liners\n" * 100
> Certainly not. I write all my list comps on one line!
> *ducking for cover*
Heres a more vile misuse of python3's print-as-function + list-comp-as-for:
python3 -c 'from os import walk; [print(r) for r, d, f in walk(".") if len(d+f)
== 1]'
Well if C programmers can use ',' as one-line ';' and '?:' as one-line if
why not python also?
[To noobs who are reading: Dont do this!]
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Thursday, May 29, 2014 10:14:35 PM UTC+5:30, Paul Rudin wrote: > Terry Reedy writes: > > 3. Search unopened files (grep) for a string or re. > Emacs. How do you do this with emacs? I find a menagerie of greppish commands -- rgrep, lgrep, grep-find etc -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Fri, May 30, 2014 at 10:47 PM, Rustom Mody wrote:
> On Friday, May 30, 2014 12:50:31 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, May 30, 2014 at 4:04 PM, Rustom Mody wrote:
>> > I thought when one signs up for python one has to sign an affidavit
>> > saying:
>> > "I shall not write one-liners\n" * 100
>
>> Certainly not. I write all my list comps on one line!
>
>> *ducking for cover*
>
> Heres a more vile misuse of python3's print-as-function + list-comp-as-for:
>
> python3 -c 'from os import walk; [print(r) for r, d, f in walk(".") if
> len(d+f) == 1]'
>
> Well if C programmers can use ',' as one-line ';' and '?:' as one-line if
> why not python also?
>
> [To noobs who are reading: Dont do this!]
I actually crafted the exact same vile misuse, prior to asking the question.
https://lists.debian.org/debian-user/2014/05/msg02019.html
Modulo trivialities like whitespace and the from-import, it's exactly
the same as your version.
Incidentally, C's ?: operator maps to Python's ternary if/else
operator, which most definitely is valid in a one-liner. So it's just
the semicolon that you're looking at. In C, you can combine any two
statements onto one line; in Python, certain statements may not follow
a semicolon. So it's not really ; and ?: that are the point here, but
that Python, with its stricter rules about newlines (as opposed to
"any whitespace"), doesn't seem to have a convenient notation for
putting multiple lines into a -c command.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
Rustom Mody :
>> > 3. Search unopened files (grep) for a string or re.
>
> How do you do this with emacs?
> I find a menagerie of greppish commands -- rgrep, lgrep, grep-find etc
To grep for a pattern in the directory of the active buffer:
M-x grep
Run grep (like this): grep -nH -e
Complete the grep command:
Run grep (like this): grep -nH -e class *.py
and hit ENTER. Feel free to modify the command from grep to egrep, for
example. I often replace -e with -i.
To grep for a pattern in any subdirectory:
M-x grep
Run grep (like this): grep -nH -r assert .
or:
M-x grep-find
Run find (like this): find . -type f -exec grep -nH -e assert {} +
Again, you can modify the command freely:
M-x grep-find
Run find (like this): find . -name '*.py' -exec grep -nH -e assert {} +
You will get a list of hits in a new buffer. You can use the C-x `
command to traverse them in order, but there are many other ways.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Friday, May 30, 2014 7:24:10 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody wrote: > > > >> > 3. Search unopened files (grep) for a string or re. > > > > How do you do this with emacs? > > I find a menagerie of greppish commands -- rgrep, lgrep, grep-find etc > > > > To grep for a pattern in the directory of the active buffer: > > >M-x grep >Run grep (like this): grep -nH -e Well... lgrep is cleverer than grep (in a stupid sort of way :D ) Was just wondering if there were some other tricks -- https://mail.python.org/mailman/listinfo/python-list
Optparse to parsing Suggestions !!
Hello Python world ,
I wanted suggestion on how to modify the below code to help me accomodate
the below two cases
# Here is the Sample code.
def main():
""" ---MAIN--- """
parser = optparse.OptionParser(usage='%prog [options] .]',
version='1.0')
object_choice = ('super_block','blocks''files', 'directory','links')
parser.add_option("-o", "--object",
action="store",metavar="object",default='inode',dest="object",type='choice',
choices=object_choice,
help='The object type to be corrupted [ choose from ('
+ ','.join(object_choice) + ') default: %default]',)
parser.add_option("-p",
"--path",action="store",metavar="/mnt/",dest="path",type="string",help="The
file or directory path in /mnt/",)
parser.add_option("-n",
"--size",action="store",metavar="size",dest="size",default=1,type='int',help="The
offset field)
# Instruct optparse to parse the program's command line:
(options, args) = parser.parse_args()
# Build the dispatch table:
object_type_dictionary = {
"super_block":super_block_def,
"blocks":blocks_def,
"files": files_corrupt_def,
"directory": directory_corrupt_def,
"links": links_corrput_def, # no () here,we're storing function
}
# Lookup the object type and then call the function:
object_type_dictionary[options.object]()
Sample Run
# python corrupt.py --object=files --path=/tmp/ --size 1000
Questions :
Case 1: # The --path is optional for few for the object type. How do I
simulate the below behaviour
#python corrupt.py --object=super_block --size=1000
==> Should work even if --path is not given
#python corrupt.py --object=super_block --path=/tmp/--size 1000
==> If user enters --object=super_block and --path=/ifs/ should
throw an error
saying its an invaild combinations.
case 2: # The --path is mandatory for few of the object types and should
complain if its not entered .
# python corrupt.py --object=files --path=/tmp/ --size 1000
Regards,
Ganesh
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On 5/30/2014 7:46 AM, Chris Angelico wrote:
Hmm. I'm not sure that "raises SyntaxError" is any less a part of the
language's promise than "evaluates to twice the value of x" is.
Of course it is. A real SyntaxError cannot be caught immediately.* When
new syntax features are added, breaking the raising of a SyntaxError is
*not* a consideration. On the other hand, we do not freely change
AbcError to XyzError even when the latter would be more 'correct'.
* IE, you cannot type
>>> try: ..
except SyntaxError: print('caught')
because the SyntaxError during parsing rather than during execution.
Also, consider:
for i in range(5): i*3+2
2
5
8
11
14
If you do this in a script, it's perfectly legal, but won't print
anything. So the REPL is already "chang[ing] the meaning of otherwise
legal Python syntax",
It does not change what is calculated. It adds introspection output as a
convenience. The minus is that one may forget that it *is* an addition
and use the shortcut when writing a script. (I know I have, occasionally.)
> and what's more, it's making None into a special case:
Which it is, as the 'zero' of the set of Python objects.
for i in range(5): None if i%2 else i
0
2
4
Practicality beats purity. If it's more useful to the end user for
something valid-but-illogical to have a new bit of meaning in
interactive mode, I say go for it.
I disagree.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Optparse to parsing Suggestions !!
On Fri, May 30, 2014 at 7:48 PM, Ganesh Pal wrote:
>
> Hello Python world ,
>
>
> I wanted suggestion on how to modify the below code to help me accomodate
> the below two cases
>
> # Here is the Sample code.
>
> def main():
> """ ---MAIN--- """
> parser = optparse.OptionParser(usage='%prog [options] .]',
> version='1.0')
>object_choice = ('super_block','blocks''files', 'directory','links')
>
> parser.add_option("-o", "--object",
> action="store",metavar="object",default='inode',dest="object",type='choice',
> choices=object_choice,
> help='The object type to be corrupted [ choose from
> (' + ','.join(object_choice) + ') default: %default]',)
>
> parser.add_option("-p",
> "--path",action="store",metavar="/mnt/",dest="path",type="string",help="The
> file or directory path in /mnt/",)
>
> parser.add_option("-n",
> "--size",action="store",metavar="size",dest="size",default=1,type='int',help="The
> offset field)
>
>
> # Instruct optparse to parse the program's command line:
> (options, args) = parser.parse_args()
>
> # Build the dispatch table:
> object_type_dictionary = {
> "super_block":super_block_def,
> "blocks":blocks_def,
> "files": files_corrupt_def,
> "directory": directory_corrupt_def,
>"links": links_corrput_def, # no () here,we're storing function
> }
>
> # Lookup the object type and then call the function:
> object_type_dictionary[options.object]()
>
>
> Sample Run
> # python corrupt.py --object=files --path=/tmp/ --size 1000
>
>
> Questions :
>
> Case 1: # The --path is optional for few for the object type. How do I
> simulate the below behaviour
>
> #python corrupt.py --object=super_block --size=1000
>
> ==> Should work even if --path is not given
>
> #python corrupt.py --object=super_block --path=/tmp/--size 1000
>
> ==> If user enters --object=super_block and --path=/ifs/ should
> throw an error
>
> saying its an invaild combinations.
>
>
>
> case 2: # The --path is mandatory for few of the object types and should
> complain if its not entered .
>
> # python corrupt.py --object=files --path=/tmp/ --size 1000
>
>
>
Can these be accomplished with optparse using a callback. I was reading
about this.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On 5/30/2014 2:45 AM, Rustom Mody wrote:
$ python -c 'import os, pprint; pprint.pprint ([ r for r, d, f in os.walk(".")
if len(d+f) != 1])'
Mysterious that print after a ; is fine whereas for is not
Not at all. Simple statememts can follow ; or :, compound statements cannot.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/30/2014 9:54 AM, Marko Rauhamaa wrote:
Rustom Mody :
3. Search unopened files (grep) for a string or re.
How do you do this with emacs?
I find a menagerie of greppish commands -- rgrep, lgrep, grep-find etc
To grep for a pattern in the directory of the active buffer:
M-x grep
Run grep (like this): grep -nH -e
Complete the grep command:
Run grep (like this): grep -nH -e class *.py
and hit ENTER. Feel free to modify the command from grep to egrep, for
example. I often replace -e with -i.
To grep for a pattern in any subdirectory:
M-x grep
Run grep (like this): grep -nH -r assert .
or:
M-x grep-find
Run find (like this): find . -type f -exec grep -nH -e assert {} +
Again, you can modify the command freely:
M-x grep-find
Run find (like this): find . -name '*.py' -exec grep -nH -e assert {} +
Thank you for the answer. I once had things like this memorized, but now
I prefer Idle's dialog, with selected text (if any) and the full path of
the current directory (+/.py) pre-inserted as target and search
directory, and options as radiobuttons (remembered from my last search) ...
You will get a list of hits in a new buffer. You can use the C-x `
command to traverse them in order, but there are many other ways.
and a scrollable window for results ;-).
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Optparse to parsing Suggestions !!
Ganesh Pal wrote:
> Hello Python world ,
>
>
> I wanted suggestion on how to modify the below code to help me accomodate
> the below two cases
>
> # Here is the Sample code.
>
> def main():
> """ ---MAIN--- """
> parser = optparse.OptionParser(usage='%prog [options] .]',
> version='1.0')
>object_choice = ('super_block','blocks''files', 'directory','links')
>
> parser.add_option("-o", "--object",
>
action="store",metavar="object",default='inode',dest="object",type='choice',
> choices=object_choice,
> help='The object type to be corrupted [ choose from
> ('
> + ','.join(object_choice) + ') default: %default]',)
>
> parser.add_option("-p",
> "--
path",action="store",metavar="/mnt/",dest="path",type="string",help="The
> file or directory path in /mnt/",)
>
> parser.add_option("-n",
> "--
size",action="store",metavar="size",dest="size",default=1,type='int',help="The
> offset field)
>
>
> # Instruct optparse to parse the program's command line:
> (options, args) = parser.parse_args()
>
> # Build the dispatch table:
> object_type_dictionary = {
> "super_block":super_block_def,
> "blocks":blocks_def,
> "files": files_corrupt_def,
> "directory": directory_corrupt_def,
>"links": links_corrput_def, # no () here,we're storing function
> }
>
> # Lookup the object type and then call the function:
> object_type_dictionary[options.object]()
>
>
> Sample Run
> # python corrupt.py --object=files --path=/tmp/ --size 1000
>
>
> Questions :
>
> Case 1: # The --path is optional for few for the object type. How do I
> simulate the below behaviour
>
> #python corrupt.py --object=super_block --size=1000
>
> ==> Should work even if --path is not given
>
> #python corrupt.py --object=super_block --path=/tmp/--size 1000
>
> ==> If user enters --object=super_block and --path=/ifs/ should
> throw an error
>
>saying its an invaild combinations.
>
>
>
> case 2: # The --path is mandatory for few of the object types and should
> complain if its not entered .
>
> # python corrupt.py --object=files --path=/tmp/ --size 1000
I think you have to do it manually:
options, args = parser.parse_args()
if options.object == "super_block" and options.path is not None:
parser.error("Paths not allowed for 'super_block' object")
elif options.object == "files" and options.path is None:
parser.error("'files' object requires a path")
--
https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Friday, May 30, 2014 8:36:54 PM UTC+5:30, [email protected] wrote: > Out of curiosity. > Are you the Rusi Mody attempting to dive in Xe(La)TeX? Yeah :-) As my blog posts labelled unicode will indicate I am a fan of using unicode in program source: http://blog.languager.org/search/label/Unicode Of course it is not exactly a coincidence that I used APL a bit in my early days. At that time it was great fun though we did not take it seriously.* It is now about time that we stop taking ASCII seriously!! And for those who dont know xetex, its is really xɘtex – a pictorial anagram if written as XƎTEX However in all fairness I should say that I cannot seem to find my way to that promised land yet: - xetex does not quite work whereas pdflatex works smoothly - mathjax is awesome however its firmly latex (not xetex) based --- * And the fact that there are recent implementations including web ones means its by no means dead: http://baruchel.hd.free.fr/apps/apl/ which I think unicode aficionados will enjoy -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 5/30/2014 12:15 PM, Rustom Mody wrote: And for those who dont know xetex, its is really xɘtex – a pictorial anagram if written as XƎTEX I believe you mean 'pictorial palindrome', which it is! -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 30/05/2014 17:15, Rustom Mody wrote: On Friday, May 30, 2014 8:36:54 PM UTC+5:30, [email protected] wrote: It is now about time that we stop taking ASCII seriously!! This can't happen in the Python world until there is a sensible approach to unicode. Ah, but wait a minute, the ball was set rolling with Python 3.0. Then came PEP 393 and the Flexible String Representation in Python 3.3 and some strings came down in size by a factor of 75% and in most cases it was faster. Just what do some people want in life, jam on it? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Friday, May 30, 2014 10:07:21 PM UTC+5:30, Terry Reedy wrote: > On 5/30/2014 12:15 PM, Rustom Mody wrote: > > > And for those who dont know xetex, its is really xɘtex – a pictorial > > anagram if written as XƎTEX > > I believe you mean 'pictorial palindrome', which it is! > Heh! Getting woozy it looks! -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Friday, May 30, 2014 10:08:04 PM UTC+5:30, Mark Lawrence wrote: > On 30/05/2014 17:15, Rustom Mody wrote: > > On Friday, May 30, 2014 8:36:54 PM UTC+5:30, jmf wrote: > > It is now about time that we stop taking ASCII seriously!! > This can't happen in the Python world until there is a sensible approach > to unicode. Ah, but wait a minute, the ball was set rolling with Python > 3.0. Then came PEP 393 and the Flexible String Representation in Python > 3.3 and some strings came down in size by a factor of 75% and in most > cases it was faster. Just what do some people want in life, jam on it? I dont see that these two are related¹ You are talking about the infrastructure needed for writing unicode apps. The language need not have non-ASCII lexemes for that I am talking about something quite different. Think for example of a German wanting to write "Gödel" According to some conventions (s)he can write Goedel But if that is forced just because of ASCII/US-104/what-have-u it would justifiably cause irritation/offense. Likewise I am talking about the fact that x≠y is prettier than x != y.² In earlier times the former was not an option. Today the latter is drawn from an effectively random subset of unicode only for historical reasons and not anything technologically current. --- ¹ Ok very very distantly related maybe in the sense that since python is a key part of modern linux system admin, and getting out of ASCII-jail needs the infrastructure to work smoothly in the wider unicode world. ² And probably 100s of other such egs, some random sample of which I have listed: http://blog.languager.org/2014/04/unicoded-python.html -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On 30/05/2014 18:07, Rustom Mody wrote: On Friday, May 30, 2014 10:08:04 PM UTC+5:30, Mark Lawrence wrote: On 30/05/2014 17:15, Rustom Mody wrote: On Friday, May 30, 2014 8:36:54 PM UTC+5:30, jmf wrote: It is now about time that we stop taking ASCII seriously!! This can't happen in the Python world until there is a sensible approach to unicode. Ah, but wait a minute, the ball was set rolling with Python 3.0. Then came PEP 393 and the Flexible String Representation in Python 3.3 and some strings came down in size by a factor of 75% and in most cases it was faster. Just what do some people want in life, jam on it? I dont see that these two are related¹ You are talking about the infrastructure needed for writing unicode apps. The language need not have non-ASCII lexemes for that I am talking about something quite different. Think for example of a German wanting to write "Gödel" According to some conventions (s)he can write Goedel But if that is forced just because of ASCII/US-104/what-have-u it would justifiably cause irritation/offense. Likewise I am talking about the fact that x≠y is prettier than x != y.² In earlier times the former was not an option. Today the latter is drawn from an effectively random subset of unicode only for historical reasons and not anything technologically current. --- ¹ Ok very very distantly related maybe in the sense that since python is a key part of modern linux system admin, and getting out of ASCII-jail needs the infrastructure to work smoothly in the wider unicode world. ² And probably 100s of other such egs, some random sample of which I have listed: http://blog.languager.org/2014/04/unicoded-python.html I just happen to like fishing :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Friday, May 30, 2014 10:47:33 PM UTC+5:30, [email protected] wrote: > = > Ok, thanks for the answer. > "xetex does not quite work whereas pdflatex works smoothly" > ? Problem is a combination of 1. I am a somewhat clueless noob 2. xetex is emerging technology therefore changing fast and not stable So when something does not work I dont know whether: - its 1 (I am doing something silly) - Or 2 (I have actually hit a bug) I tried writing some small (hello-world) type text using unicode chars rather the old-fashioned \alpha type of locutions. It worked. Added a bunch of more latex packages from apt. It stopped working. -- PS It would help all if you read https://wiki.python.org/moin/GoogleGroupsPython and dont double-space earlier mails. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, 30 May 2014 21:46:55 +1000, Chris Angelico wrote: > On Fri, May 30, 2014 at 9:27 PM, Steven D'Aprano > wrote: >> This is why I'm so adamant that, while REPLs may be permitted to >> introduce *new* syntax which is otherwise illegal to the Python parser, >> (e.g. like IPython's %magic and !shell commands) they *must not* change >> the meaning of otherwise legal Python syntax. It's simply a bad idea to >> have legal Python code mean different things depending on what >> environment you're running it in. > > Hmm. I'm not sure that "raises SyntaxError" is any less a part of the > language's promise than "evaluates to twice the value of x" is. Would > you, for instance, permit the REPL to define a new __future__ directive, > on the basis that it's invalid syntax currently? > from __future__ import magic_command_history > SyntaxError: future feature magic_command_history is not defined "from __future__ import ..." is an instruction to the compiler, hence a positive language feature. (That's why in source files any such import must occur at the top of the file, before any line of code.) It's a little unfortunate that bogus __future__ imports raise SyntaxError directly rather than some subclass of it, but given that it occurs at compile time, and how rarely one is in a position to try catching the exception, its understandable that the core devs didn't bother making it a separate subclass. (On the other hand, "import __future__" is a regular import that can occur any time you like.) No, a REPL cannot legitimately invent new language features that change Python's semantics, any more than they can legitimately redefine the plus operator + to perform subtraction. But they can legitimately add features to the shell, provided those features don't affect Python code. What's the difference? Consider entering this part of an interactive IPython session: In [14]: len [] ---> len([]) Out[14]: 0 In [15]: n = len [] File "", line 1 n = len [] ^ SyntaxError: invalid syntax Why is [14] permitted, but not [15]? Because [14] is a shell feature, but [15] is Python code. If [15] were permitted, then we would be tempted to use it inside functions: def spam(a): n = len a ... and either be surprised at the syntax error, or (worse!) be surprised that the function runs interactively inside IPython but fails in other shells and non-interactively. If [15] were allowed, we would no longer be running Python code. Of course, a naive user will be confused that len [] is permitted in IPython, but that's okay since it's a power-user's shell aimed at power- users. If the vanilla Python shell introduced such power-user convenience features by default, I would be very disappointed. Before you ask, there is no absolutely hard and fast line between "shell feature" and "Python code", but the more closely your shell features resemble Python code, the harder it will be for users (power or not) to keep them separate in their head and the more likely they will be confused. E.g. suppose my shell decided to allow lines like var = len [] to define the variable var and set it to 0. I'd argue that crosses the line from "useful convenience feature for power-users" to "dangerously confusing misfeature" because it looks too much like Python code. (I'm already dubious about len [] on its own.) A better interface is to have a clear separation between shell commands and Python, and IPython commonly usually uses prefix sigils such as ; % and ! for that. More here, including some cases where I think IPython crosses that line: http://ipython.org/ipython-doc/dev/interactive/reference.html You raise the issue of the vanilla Python shell printing the result of expressions. That would be the P in REPL, yes? :-) It would be a funny REPL that *didn't* print evaluated expressions. (Not entirely unheard of though -- Forth, for example, doesn't print the values you push onto the stack unless you pop them from the stack first. But it does print "ok" after each Read-Eval cycle when working interactively, so I guess it still counts as a REPL.) If we wanted to be pedantic, then yes there are semantic differences between code running in a REPL and the same running non-interactively. The vanilla REPL sets the magic variable _ to the result of the last evaluated expression (IPython has a bazillion variations of that). The REPL defines sys.ps1 and sys.ps2, when running non-interactively they don't exist. PYTHONSTARTUP isn't loaded outside of the REPL. But my argument is that these are a different kind of semantic difference than changing how Python expressions are parsed. Not all semantic differences are equal: (1) in the REPL, evaluating "(spam . attr)" on its own has the side-effect of printing the value of spam.attr (2) in the REPL, evaluating "(spam . attr)" does not perform a lookup of attr on spam
Re: How to run script from interpreter?
On Sat, May 31, 2014 at 5:28 AM, Steven D'Aprano
wrote:
> Before you ask, there is no absolutely hard and fast line between "shell
> feature" and "Python code", but the more closely your shell features
> resemble Python code, the harder it will be for users (power or not) to
> keep them separate in their head and the more likely they will be
> confused. E.g. suppose my shell decided to allow lines like
>
> var = len []
>
> to define the variable var and set it to 0. I'd argue that crosses the
> line from "useful convenience feature for power-users" to "dangerously
> confusing misfeature" because it looks too much like Python code. (I'm
> already dubious about len [] on its own.) A better interface is to have a
> clear separation between shell commands and Python, and IPython commonly
> usually uses prefix sigils such as ; % and ! for that.
I think this is the nub of the issue. You believe that anything that's
syntactically legal in a script MUST (a) be syntactically legal, and
(b) have the same semantics (modulo the printing part mentioned below)
in the interactive interpreter. I'm a little less strict, and would be
okay with some things that make little sense being disallowed. There
are already a few such things (you mention the blank line issue), and
the question is more whether they're recommended or not, than whether
they're allowed or not. (Python 3's super() is a piece of magic, and
it's better that it be magical, but it isn't a precedent to be
followed.) I can accept that the desirable line is further over than I
was putting it; practicality is only so-much of an argument.
> You raise the issue of the vanilla Python shell printing the result of
> expressions. That would be the P in REPL, yes? :-) It would be a funny
> REPL that *didn't* print evaluated expressions.
Yes of course, but there's a difference between these:
>>> 1 + 2
3
>>> while True:
input("Echo? ")
if _=="Echo!": break
The first one is using the REPL exactly the way everyone would expect
it to be used. A single expression is entered, and it is printed.
Failing to do that is, indeed, failing on the P of REPL. (That said, a
Read-Eval Loop, sans Print, is still of value. I used one for over a
decade with REXX, manually prefixing things with "say" when I wanted
them printed, err I mean said.) But the second one is looking a lot
more like a script, and if you're writing code like that, you really
should think about assigning the input to a variable and explicitly
printing it, not fiddling with automatic display and the _ capture.
A "top-level expression", if you like, should definitely be printed.
An inner expression isn't so fundamental. Since Python has been
written to print them, we can make use of it; but a REPL that didn't
print inner expressions is still a useful tool. Printing inner
expressions is sliding toward the line of dangerously confusing
misfeatures that you mentioned; you could compose a massively long
function, and deep inside it, call something and have its return value
printed - and then paste that into a script and find that it's not
printing any more. Or, possibly worse, come to python-list with the
question "How do I fix this?", not even knowing what the problem is,
and having us all assume it's a script.
It's a grey area. What's a convenient and useful feature, and what's a
problem? Is supporting "print 1+2" in Python 3 on one side or the
other of that line?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: daemon thread cleanup approach
Don't use daemon threads, they are inherently un-thread-safe: any global access you do anywhere inside a daemon thread can fail, because daemon threads are still potentially run during interpreter shutdown, when globals are being deleted from every module. Most functions you might call are not safe in a daemon thread at shutdown. -- Devin On Wed, May 28, 2014 at 6:20 PM, Carl Banks wrote: > Ok, so I have an issue with cleaning up threads upon a unexpected exit. I > came up with a solution but I wanted to ask if anyone has any advice or > warnings. > > Basically I am writing a Python library to run certain tasks. All of the > calls in the library start worker threads to do the actual work, and some of > the worker threads are persistent, others not. Most threads have cleanup > work to do (such as deleting temporary directories and killing spawned > processes). > > For better or worse, one of the requirements is that the library can't cause > the program to hang no matter what, even if it means you have to forego > cleanup in the event of an unexpected exit. Therefore all worker threads run > as daemons. Nevertheless, I feel like the worker threads should at least be > given a fair opportunity to clean up; all threads can be communicated with > and asked to exit. > > One obvious solution is to ask users to put all library calls inside a > with-statement that cleans up on exit, but I don't like it for various > reasons. > Using atexit doesn't work because it's called after the daemon threads are > killed. > > Here's the solution I came up with: in the library's init function, it will > start a non-daemon thread that simply joins the main thread, and then asks > all existing worker threads to exit gracefully before timing out and leaving > them to be killed. So if an exception ends the main thread, there is still a > chance to clean up properly. > > Does anyone see a potential problem with this approach? It it possible that > this will cause the program to hang in any case? We can assume that all > calls to the library will occur from the main thread, or at least from the > same thread. (If that isn't the case, then the caller has taken > responsibility to ensure the program doesn't hang.) > > This is Python 2.7, and it's only ever going to run on Windows. > > Thanks for any advice/warnings. > > Carl Banks > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
Chris Angelico wrote:
> Problem: Translate this into a shell one-liner:
>
> import os
> for root, dirs, files in os.walk("."):
> if len(dirs + files) == 1: print(root)
>
This is one area where Windows seems to do better than Linux shells:
PS C:\python33> python -c "import os`nfor root, dirs, files in os.walk('.'):`n
if len(dirs + files) == 1: print(root)`n"
.\Doc
.\Lib\concurrent\__pycache__
.\Lib\curses\__pycache__
...
The `n shell escaped newline is interpreted well before Python runs.
Also the multiline version works and in Powershell ISE up-arrow pulls it back
as a
single unit for easy editing:
PS C:\python33> python -c @"
import os
for root, dirs, files in os.walk('.'):
if len(dirs + files) == 1: print(root)
"@
.\Doc
.\Lib\concurrent\__pycache__
.\Lib\curses\__pycache__
... and so on ...
--
Duncan Booth
--
https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
In unix shells you can literally use a new line. Or is that only bash?
-- Devin
On Fri, May 30, 2014 at 2:11 PM, Duncan Booth
wrote:
> Chris Angelico wrote:
>
>> Problem: Translate this into a shell one-liner:
>>
>> import os
>> for root, dirs, files in os.walk("."):
>> if len(dirs + files) == 1: print(root)
>>
>
> This is one area where Windows seems to do better than Linux shells:
>
> PS C:\python33> python -c "import os`nfor root, dirs, files in
> os.walk('.'):`nif len(dirs + files) == 1: print(root)`n"
> .\Doc
> .\Lib\concurrent\__pycache__
> .\Lib\curses\__pycache__
> ...
>
> The `n shell escaped newline is interpreted well before Python runs.
>
> Also the multiline version works and in Powershell ISE up-arrow pulls it back
> as a
> single unit for easy editing:
>
> PS C:\python33> python -c @"
> import os
> for root, dirs, files in os.walk('.'):
> if len(dirs + files) == 1: print(root)
> "@
> .\Doc
> .\Lib\concurrent\__pycache__
> .\Lib\curses\__pycache__
> ... and so on ...
>
>
> --
> Duncan Booth
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: daemon thread cleanup approach
On 05/30/2014 01:47 PM, Devin Jeanpierre wrote: Don't use daemon threads, they are inherently un-thread-safe: any global access you do anywhere inside a daemon thread can fail, because daemon threads are still potentially run during interpreter shutdown, when globals are being deleted from every module. Most functions you might call are not safe in a daemon thread at shutdown. Given the use-case (must shut down, cannot risk a hung process, orphan files be damned) I don't think having a daemon thread die because it raised an exception trying to access a missing global is a big deal. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Sat, May 31, 2014 at 7:42 AM, Devin Jeanpierre wrote: > In unix shells you can literally use a new line. Or is that only bash? You can in bash, I know, but it's fiddly to type it; and more importantly, it's not a good point in the "this is cleaner than a series of pipes" argument. My primary recommendation, of course, was a three-line script saved as an actual file, but for a more direct parallel to the pipe-it-three-ways model, I wanted to use -c. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: daemon thread cleanup approach
On Fri, May 30, 2014 at 1:59 PM, Ethan Furman wrote: > Given the use-case (must shut down, cannot risk a hung process, orphan files > be damned) I don't think having a daemon thread die because it raised an > exception trying to access a missing global is a big deal. It's certainly suboptimal. Subprocesses are better in every way. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Script suddenly stops
On 5/29/14, 7:47 PM, Chris wrote: I'm trying to read ten 200 MB textfiles into a MySQL MyISAM database (Linux, ext4). The script output is suddenly stopping, while the Python process is still running (or should I say sleeping?). It's not in top, but in ps visible. Does it stop in the same place every time? How long are you waiting before giving up? Is it at all possible that it is the MySQL side that is blocking? Why is it stopping? Is there a way to make it continue, without calling "kill -9", deleting the processed lines and starting it again? One thing to try (maybe, depending on whether it still fits into your requirements for a database transaction) is to increase the number of rows inserted before each commit. [1] http://pastebin.com/CxHCA9eB It won't have any bearing, but those globals aren't necessary... Paul -- https://mail.python.org/mailman/listinfo/python-list
Yet another "simple" headscratcher
I am trying to whip up a quick matrix class that can handle multiplication.
Should be no problem, except when it fails.
--- Begin
#!/usr/bin/env python
# _*_ coding: utf-8
from operator import mul
class Matrix(object):
"""Matrix([data])
Data should be a list of equal sized lists.
Defaults to a 2d identity matrix
"""
def __init__(self, data=None):
if data is None:
data = [[1,0], [0,1]]
self.data = []
if isinstance(data, (list, tuple)):
ncols = len(data[0])
for row in data:
if len(row) != ncols:
raise ValueError("Rows are unequal lengths")
self.data.append(row)
self.size = (len(self.data), len(self.data[0]))
def get_row(self, idx):
if (0 <= idx < self.size[0]):
return self.data[idx]
else:
raise ValueError("Bad row")
def get_col(self, idx):
if (0 <= idx < self.size[1]):
return list(d[idx] for d in self.data)
else:
raise ValueError("Bad column index")
def __mul__(self, other):
if not isinstance(other, (Matrix,int, float)):
raise ValueError("Cannot multiply by given value")
if isinstance(other, (int, float)):
res = []
for row in self.data:
res.append([d*other for d in row])
return Matrix(res)
# left with a matrix
res = zero_matrix(self.size[0], other.size[1])
for i in range(res.size[0]):
for j in range(res.size[1]):
print i, j, self.get_row(i), other.get_col(j),
temp = map(mul, self.get_row(i), other.get_col(j))
print temp,
t = sum(temp)
print t
res.data[i][j] = t
print res.data
return res
def as_string(self):
# return a list of lines that look pretty
stringed =[]
for row in self.data:
stringed.append(map(str, row))
widths = []
for col in range(self.size[1]):
column = [s[col] for s in stringed]
widths.append(max(map(len, column)))
item_format = "{:>%s}"
format_items = [item_format % w for w in widths]
format_string = " ".join(format_items)
formatted = [format_string.format(*s) for s in stringed]
return formatted
def zero_matrix(rows, cols):
row = [0] * cols
data = []
for r in range(rows):
data.append(row)
return Matrix(data)
M = Matrix(([1, 0], [0, -1]))
N = M*4
print '\n'.join(M.as_string())
print '-'
print '\n'.join(N.as_string())
print '-'
S = N * M
print '\n'.join(S.as_string())
--- END
For some reason, my output from this is:
1 0
0 -1
-
4 0
0 -4
-
0 0 [4, 0] [1, 0] [4, 0] 4
[[4, 0], [4, 0]]
0 1 [4, 0] [0, -1] [0, 0] 0
[[4, 0], [4, 0]]
1 0 [0, -4] [1, 0] [0, 0] 0
[[0, 0], [0, 0]]
1 1 [0, -4] [0, -1] [0, 4] 4
[[0, 4], [0, 4]]
0 4
0 4
>>>
The print lines prove to me that the logic is working, but for some reason,
assigning the sum to a particular item in a particular row is assigning the
same row values to every row.
This should be one of those really simple Python things, but for the life of me
I don't see it.
The first [[4, 0], [4, 0]] is clearly wrong. In each step, this algorithm is
repeating the row.
Any ideas as to why this is happening?
Python 2.7.5, Windows 7, so nothing exotic.
Josh
--
https://mail.python.org/mailman/listinfo/python-list
Re: Yet another "simple" headscratcher
Mea culpa, gang. I found it. It had absolutely nothing to do with the multiplication. It was in zero_matrix. I feel like a fool. Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet another "simple" headscratcher
On Fri, May 30, 2014 at 9:38 PM, Josh English wrote: > I am trying to whip up a quick matrix class that can handle multiplication. > > Should be no problem, except when it fails. > > [SNIP] > > def zero_matrix(rows, cols): > row = [0] * cols > data = [] > for r in range(rows): > data.append(row) Each row of the matrix that you create here is the *same* list, not different lists that happen to be equal. So when you mutate one row, you mutate all of them. See: https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Yet another "simple" headscratcher
On 05/30/2014 08:38 PM, Josh English wrote: ... def zero_matrix(rows, cols): row = [0] * cols data = [] for r in range(rows): data.append(row) return Matrix(data) There is a simple and common newbie mistake here.It looks like you are appending several copies of a zero row to data, but in fact you are appending multiple references to a single row. (The hint is that you only created *one* row.) Put the row = [0] * cols inside the loop so each append is using its own row rather than one shared row being used multiple times. Here's a small example that demonstrates problem: >>> row = [0,0,0,0] >>> data = [] >>> data.append(row) >>> data.append(row) >>> data[0][0] = 99 >>> data [[99, 0, 0, 0], [99, 0, 0, 0]] Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
