Script suddenly stops
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 -- Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 6:22:24 AM UTC+5:30, Chris Angelico wrote: Since lines are so critical to Python syntax, I'm a little surprised there's no majorly obvious solution to this... or maybe I'm just blind. Problem: Translate this into a shell one-liner: import os for root, dirs, files in os.walk(.): if len(dirs + files) == 1: print(root) I would have thought this would work: python -m os -c 'for root, dirs, files in os.walk(.): if len(dirs + files) == 1: print(root)' Unfortunately doesn't But did show up a small doc-bug: This fact is not documented in $ man python but is documented in $ python -h Anyways... I thought when one signs up for python one has to sign an affidavit saying: I shall not write one-liners\n * 100 -- https://mail.python.org/mailman/listinfo/python-list
Re: How to run script from interpreter?
On Fri, 30 May 2014 12:04:27 +1000, Chris Angelico wrote: On Fri, May 30, 2014 at 11:49 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 30 May 2014 10:46:34 +1000, Chris Angelico wrote: On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (By the way, ; won't work for a Python shell, because ;spam already is valid Python syntax: it's an empty statement followed by the statement spam, separated by a semicolon.) That's not really a problem, though. It's not going to stop you from doing something actually *useful*, and the fact that the semicolon could be syntactically valid isn't going to come into it, because the REPL would swallow it anyway. The point is that *syntactically valid* Python statements should not behave differently when running inside the shell or not. I thought that ;statement was syntactically valid -- but I was wrong. The vanilla CPython interactive interpreter gives a syntax error, as do IronPython and Jython. Huh. I responded to your post on the unchecked assumption that ;spam was syntactically valid. I'm still of the opinion that technically valid (but not useful) constructs are allowed to be swallowed by an interactive interpreter; Heavens no. If it's legal in a script when running non-interactively, it should be legal when running interactively. I give a grudging exception to things like the REPL ending a function definition at the first empty line, even though it breaks copy-and-paste of working code: py def example(): ... do_this() ... py do_that() File stdin, line 1 do_that() ^ IndentationError: unexpected indent That's a *serious* PITA when copying (say) classes into the interactive interpreter, because you have to delete all the blank lines (or stick comments # in them) before pasting. But I can't see any practical alternative. for instance, it's perfectly valid to write this: x = (1 . imag) Absolutely it is valid Python code, so your REPL better accept it as valid Python code. But quite a few interpreters (though not Python) take a dot on its own line to mean flush the buffer, cancel my current command. I've never come across that. I'm very glad I haven't. Who came up with that broken interface? I couldn't find a way to do this in Python, but if someone proposed adding it, the fact that the above is syntactically legal shouldn't be a proposal blocker. Damn straight it ought to. If I proposed making: x = (1 + y) do something other than set x to 1+y, I would completely deserve to be dragged out into the street and beaten with halibuts. Replace the + with a dot, and there is no difference at all. If you want to kill the current buffer, just hit Ctrl-C like you're meant to. 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. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
On Friday, May 30, 2014 11:34:36 AM UTC+5:30, Rustom Mody wrote: On Friday, May 30, 2014 6:22:24 AM UTC+5:30, Chris Angelico wrote: Since lines are so critical to Python syntax, I'm a little surprised there's no majorly obvious solution to this... or maybe I'm just blind. Problem: Translate this into a shell one-liner: import os for root, dirs, files in os.walk(.): if len(dirs + files) == 1: print(root) Heres a (pr) approx $ 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 Anyways... I thought when one signs up for python one has to sign an affidavit saying: I shall not write one-liners\n * 100 I hope youve signed it by now wink -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-line commands with 'python -c'
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])' -- https://mail.python.org/mailman/listinfo/python-list
Re: Script suddenly stops
Chris ch2...@arcor.de 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 steve+comp.lang.pyt...@pearwood.info 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 rustompm...@gmail.com 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 pwnapplei...@icloud.com 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 steve+comp.lang.pyt...@pearwood.info 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 steve+comp.lang.pyt...@pearwood.info 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 tjre...@udel.edu 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 rustompm...@gmail.com 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 rustompm...@gmail.com:
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] arg1.]',
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 ganesh1...@gmail.com 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] arg1.]',
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 rustompm...@gmail.com:
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] arg1.]',
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, wxjm...@gmail.com 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, wxjm...@gmail.com 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, wxjm...@gmail.com 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 steve+comp.lang.pyt...@pearwood.info 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 ipython console, 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
Re: How to run script from interpreter?
On Sat, May 31, 2014 at 5:28 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 pavlovevide...@gmail.com 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 ros...@gmail.com 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
duncan.booth@invalid.invalid wrote:
Chris Angelico ros...@gmail.com 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 jeanpierr...@gmail.com 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 et...@stoneleaf.us 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 joshua.r.engl...@gmail.com 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
[issue14315] zipfile.ZipFile() unable to open zip File
Roundup Robot added the comment: New changeset 6dd5e9556a60 by Gregory P. Smith in branch '2.7': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/6dd5e9556a60 New changeset 33843896ce4e by Gregory P. Smith in branch '3.4': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/33843896ce4e New changeset 89be1419472c by Gregory P. Smith in branch 'default': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/89be1419472c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14315 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14315] zipfile.ZipFile() unable to open zip File with a short extra header
Gregory P. Smith added the comment: This was never an enhancement. zipfile was failing to properly deal with real world data that other zip file tools on the planet were perfectly happy to deal with. That's a bug. Fixed. Practicality beats purity. Be lenient in what you accept. The zipfile module is not meant to be a zip standard validation tool. The other discussions in this bug about adding actual features such as a strict mode flag could be done but should really go in feature requests of their own. The zipfile module is... not a wonderful body of code (understatement). Example: It is still quite possible to get non zipfile.BadZipFile exceptions such as struct.error based on various arrangements of input data. -- assignee: - gregory.p.smith nosy: +gregory.p.smith resolution: - fixed stage: test needed - resolved status: open - closed title: zipfile.ZipFile() unable to open zip File - zipfile.ZipFile() unable to open zip File with a short extra header type: enhancement - behavior versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14315 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21611] int() docstring - unclear what number is
New submission from Dmitry Andreychuk: https://docs.python.org/3.4/library/functions.html?highlight=int#int The docstring for int() function has these sentences: If x is a number, return x.__int__(). If x is not a number or if base is given... Unfortunately the docstring doesn't describe how the function decides if x is a number or not. After searching and experimenting I came to conclusion that it is the presence of x.__int__() method makes int() treat x as a number. But I'm not sure it's a precise requirement or just something that happens to work with current implementation. I think there should be a precise definition of what is considered to be a number there. -- assignee: docs@python components: Documentation messages: 219379 nosy: and, docs@python priority: normal severity: normal status: open title: int() docstring - unclear what number is versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21611 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13742] Add a key parameter (like sorted) to heapq.merge
Roundup Robot added the comment: New changeset f5521f5dec4a by Raymond Hettinger in branch 'default': Issue #13742: Add key and reverse parameters to heapq.merge() http://hg.python.org/cpython/rev/f5521f5dec4a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13742 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13742] Add a key parameter (like sorted) to heapq.merge
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13742 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api
Sunny K added the comment:
Hi Stefan,
There is a comment at the top in structseq.c
/* Fields with this name have only a field index, not a field name.
They are only allowed for indices n_visible_fields. */
char *PyStructSequence_UnnamedField = unnamed field;
This is the definition of os.stat_result in posixmodule.c:
static PyStructSequence_Field stat_result_fields[] = {
{st_mode,protection bits},
{st_ino, inode},
{st_dev, device},
{st_nlink, number of hard links},
{st_uid, user ID of owner},
{st_gid, group ID of owner},
{st_size,total size, in bytes},
/* The NULL is replaced with PyStructSequence_UnnamedField later. */
{NULL, integer time of last access},
{NULL, integer time of last modification},
{NULL, integer time of last change},
{st_atime, time of last access},
{st_mtime, time of last modification},
{st_ctime, time of last change},
{st_atime_ns, time of last access in nanoseconds},
{st_mtime_ns, time of last modification in nanoseconds},
{st_ctime_ns, time of last change in nanoseconds},
...
By visible i mean the values present in the repr of the object and by-extension
accessible by position.
I talked about my problems with os.stat_result in points 3 and 4 of msg202333
i.e repr of os.stat_result takes the first three keys from the attribute-access
only fields (the invisible part) and uses them for the last three values in the
displayed structseq.
With my current patch, _fields for os.stat_result only has 7 values:
x = os.stat('.')
x._fields
('st_mode', 'st_ino', 'st_dev', 'st_nlink', 'st_uid', 'st_gid', 'st_size')
Is this what you expect?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1820
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1820 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19048] itertools.tee doesn't have a __sizeof__ method
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19048 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19662] smtpd.py should not decode utf-8
Maciej Szulik added the comment: I've included Leslie's comments in rst file. The 3rd version is attached in issue19662_v3.patch. -- Added file: http://bugs.python.org/file35409/issue19662_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185124] pydoc doesn't find all module doc strings
Changes by Sunny K sunfin...@gmail.com: Removed file: http://bugs.python.org/file31844/myfirst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185124] pydoc doesn't find all module doc strings
Sunny K added the comment: Hi Victor, can you give this another look? -- versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21571] Python build should check CPATH, C_INCLUDE_PATH for module dependencies
Ronald Oussoren added the comment: I'm pretty sure that I wrote the code Ned refers to, and that's indeed only targeting darwin to avoid breaking other platforms. That code could easily be made actively globally though, the only reason I didn't do so at the time is we were still getting used to the fact that MacOS used the same build infrastructure as other major platforms and hence were overly cautious. Note that this doesn't do the same thing as Jan requests: GCC[1] and clang[2] can add additional directories to their header file search path using environment variables. For Python's setup.py file the following are important: * C_INCLUDE_PATH: a list of directories that are handled as if they are present at the end of the list of -isystem options (that is, system include files at a lower priority that the user provided ones) * CPATH: simular, but for the '-I' option * LIBRARY_PATH: similar, but for the '-L' option All of them have a syntax similar to $PATH. A patch to add support for these variables (and enables the handling of -I and -L for other platforms than darwin) should be easy enough, but I agree with Ned that this would be a new feature because it could break existing build systems (that is, building Python with this patch could result in a different build than without the patch due to the build picking up more or different external libraries). Jan: are you willing to write such a patch? And if so, are you willing to sign a contributor agreement? [1]: http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html [2]: http://clang.llvm.org/doxygen/Tools_8cpp_source.html -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21571 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21541] Provide configure option --with-ssl for compilation with custom openssl
Ronald Oussoren added the comment: Isn't Modules/Setup used for builtin modules? The proposed configure flags are easier to find because similar flags are used by other projects using autoconf. Note that on OSX you could use CFLAGS=-I/path/to/ssl/include LDFLAGS=-L/path/to/ssl/lib, because setup.py contains code to add directories from those flags to its search path for headers and libraries, but only for OSX because I was overly cautious when adding that code. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21541 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21552] String length overflow in Tkinter
Roundup Robot added the comment: New changeset 59468bd68789 by Serhiy Storchaka in branch '2.7': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/59468bd68789 New changeset a90cddfd9e47 by Serhiy Storchaka in branch '3.4': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/a90cddfd9e47 New changeset 5b80af12ccb7 by Serhiy Storchaka in branch 'default': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/5b80af12ccb7 New changeset 8c96af2fba28 by Serhiy Storchaka in branch '2.7': Fixed possible integer overflow in getint, getdouble and getboolean too (issue #21552). http://hg.python.org/cpython/rev/8c96af2fba28 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21552 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21592] Make statistics.median run in linear time
Thomas Dybdahl Ahle added the comment: If you have a good, realistic test set, we can try testing quick-select vs sorting. If it's still not good, I can also reimplement it in C. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Brett Cannon added the comment: Giving Eric is polymorphic first argument to types.ModuleType() is going to be tricky thanks to the fact that it is not hard-coded anywhere in the C code nor documented that the first argument must be a string (the only way it might come up is from PyModule_GetName() and even then that's not required to work as you would expect). And since we purposefully kept specs type-agnostic, you can't do a type check for a SimpleNamespace. I think the only way for it to work is by attribute check (e.g. is 'name' or 'loader' defined on the object, regardless of value). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Brett Cannon added the comment: Another issue with the polymorphic argument is that the module type is one of those rare things written in C with keyword parameter support, so renaming the 'name' argument to 'name_or_spec' could potentially break code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect
Bikram Zesto II added the comment: I see what you are saying about implementation kludginess and will likely subclass just to get my app done. On the other hand, I think the POLA(stonishment) violation of ignoring format-related configuration of the Handler (even tho it is a subclass) matters too :-) Was not thinking a Formatter should be put _into_ mapLogRecord. More like idly wondering if mapLogRecord could be implemented as a Formatter. If this sounds like a non-kludge you would be interested in I can work on that. Added benefit being that users could override without subclassing. Maybe this is more like a documentation issue (since there is no indication that HTTPHandler does not/cannot use a Formatter like other of Handlers? -- keywords: +patch status: pending - open Added file: http://bugs.python.org/file35410/logging.handlers.txt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21608 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21610] load_module not closing opened files
Brett Cannon added the comment: I don't have a Python 2.7 repo handy but the patch LGTM. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21610 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21612] IDLE should should not open multiple instances of one file
New submission from irdb: Currently users can open multiple instances of one file in IDLE. Sometimes this leads to confusion and may cause loss of data. I'm not aware of any benefits of this behavior and I think it's better to be prevented by IDLE. Here are the steps to recreate the situation: 1. Create a file named xyz.py 2. Right-click on the file and open it with IDLE 3. Add some text 4. Goto 2. 5. Save and close both open IDLE windows. (Your work on the first saved file will be lost.) -- components: IDLE messages: 219392 nosy: irdb priority: normal severity: normal status: open title: IDLE should should not open multiple instances of one file ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21612] IDLE should not open multiple instances of one file
Changes by irdb dalba.w...@gmail.com: -- title: IDLE should should not open multiple instances of one file - IDLE should not open multiple instances of one file ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21613] Installer for mac doesn't store the installation location
New submission from Artem Ustinov: I'm trying to automate the Python uninstallation on mac but I've found that the actual installation location is not stored for Python packages. That location is required since the pkgutil keeps track of installed files (if you run $ pkgutil --files org.python.Python.PythonFramework-3.4) but doesn't store the absolute paths for that files. 1. Run $ pkgutil --pkgs=.*Python.*3\.4 Here's the expected output org.python.Python.PythonApplications-3.4 org.python.Python.PythonDocumentation-3.4 org.python.Python.PythonFramework-3.4 org.python.Python.PythonInstallPip-3.4 org.python.Python.PythonProfileChanges-3.4 org.python.Python.PythonUnixTools-3.4 2. Run $ pkgutil --pkg-info org.python.Python.PythonFramework-3.4 Here's the output package-id: org.python.Python.PythonFramework-3.4 version: 3.4.1 volume: / location: (null) install-time: 1401373546 Actual Result: The location property is (null) Expected Result: The location property should be '/Library/Frameworks/Python.framework' -- assignee: ronaldoussoren components: Installation, Macintosh messages: 219393 nosy: ronaldoussoren, ustinov priority: normal severity: normal status: open title: Installer for mac doesn't store the installation location type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21613 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21477] Idle: improve idle_test.htest
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com: Added file: http://bugs.python.org/file35411/htest-docstring-34.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21613] Installer for mac doesn't store the installation location
Ronald Oussoren added the comment: According to the manpage pkgutil is used with flat packages. The Python installer users older bundle-style packages. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21613 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21477] Idle: improve idle_test.htest
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com: Added file: http://bugs.python.org/file35412/htest-docstring-27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse
R. David Murray added the comment: I think the code should be using 'detach' after passing the fp to parser.parse, instead of using 'with'. -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21476 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds
Steve Dower added the comment: I can commit it, though I don't know how it'll affect Benjamin's release branch? (Obviously the build will be fine either way - I had the patch applied for 2.7.7rc1.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21462 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Eric Snow added the comment: Yeah, it just looks too complicated to take the ModuleType signature approach, as much as I prefer it. :) I appreciate you taking a look though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse
Vajrasky Kok added the comment: Here is the simple patch based on David Murray's thought. -- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file35413/bytes_parser_dont_close_file.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21476 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect
Vinay Sajip added the comment: As far as POLA is concerned, IMO serializing to the HTTP request format isn't really a text formatting operation in the same way as for most other handlers. The point is, even if you could have a Formatter handle the operation, you can't usefully share this Formatter with other handlers (which you refer to in your initial post), unless you really want to have format lines such as a=bc=de=f output to console or file, say - which is unlikely to be a common requirement. I don't expect to make any changes in this area - as I mentioned earlier, because (a) backward compatibility and (b) IMO it will surprise more people than the current approach (IIRC no one else has raised this or a similar issue in the 10+ years that logging has been in Python). BTW, I am happy to update the documentation for HTTPHandler to indicate that it can't sensibly use a Formatter. I'll do this soon, and that change will close this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21608 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Brett Cannon added the comment: And another complication is the compatibility hack to set loader when submodule_search_locations is set but loader is not since _NamespaceLoader is not exposed in C without importlib which gets us back into the whole question of whether types should function entirely in isolation from other subsystems of Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13212] json library is decoding/encoding when it should not
Chris Rebert added the comment: Okay, so can this issue be closed in light of the existing docs and issue 21514 then? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13212 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Eric Snow added the comment: But that part is less of a concern since we don't need namespace packages before or during bootstrapping, and afterward we have access to interp-importlib. Or am I missing something? which gets us back into the whole question of whether types should function entirely in isolation from other subsystems of Python. That is a great question, regardless. In part I imagine it depends on the subsystem and how intrinsic it is to the interpreter, which seems like a relatively implementation-agnostic point from a high-level view. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds
Zachary Ware added the comment: Go ahead and commit; it will be up to Benjamin to cherry-pick it to his release branch (or to ask you to do it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21462 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21561] help() on enum34 enumeration class creates only a dummy documentation
Terry J. Reedy added the comment: Devise a simple test (fail before, work after) that does not require enum34. If this fix is committed, the message could note that the same issue was fixed differently in 3.4 mixed in with other changes. -- nosy: +terry.reedy stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21568] Win32 pip doesn't use relative path to found site-packages.
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21568 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21569] PEP 466: Python 2.7 What's New preamble changes
Terry J. Reedy added the comment: Did you intend to upload a diff with the current changes? My answers: * Just describe 466. Don't invite trouble. * Move the section to its logical place in temporal order, with a clear link. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21569 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse
Serhiy Storchaka added the comment: Use try/finally to detach even if an exception is raised during parsing. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21476 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds
Roundup Robot added the comment: New changeset f6e47d27f67a by Steve Dower in branch '2.7': Issue #21462 PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds http://hg.python.org/cpython/rev/f6e47d27f67a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21462 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect
Roundup Robot added the comment: New changeset e5373bfbe76b by Vinay Sajip in branch '2.7': Issue #21608: Updated HTTPHandler documentation. http://hg.python.org/cpython/rev/e5373bfbe76b New changeset 220bed23696e by Vinay Sajip in branch '3.4': Issue #21608: Updated HTTPHandler documentation. http://hg.python.org/cpython/rev/220bed23696e New changeset 69011f6ce573 by Vinay Sajip in branch 'default': Closes #21608: Merged documentation update from 3.4. http://hg.python.org/cpython/rev/69011f6ce573 -- nosy: +python-dev resolution: not a bug - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21608 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14097] Improve the introduction page of the tutorial
Zachary Ware added the comment: How's this for a 2.7 backport? The least direct part of the backport is the section on division; I pretty much had to completely rewrite the paragraph in 2.x terms and I'm not certain that I took the best approach. -- stage: commit review - patch review versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35414/issue14097-2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14097 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21573] Clean up turtle.py code formatting
Terry J. Reedy added the comment: I am glad to see this. Gregor has been inactive for several years, Except for Ned's recent patch for OSX, it has been years since there was a turtle-specific code patch (from hg revision history). Questions: is there project link? are any of the mentors core developers, with commit rights? or would you need commits from someone like me? I have read turtle.py and found that the multiple layers made some things hard to follow. To me, this was a bigger impediment than code formatting. You may want to develop an outline of the layer structure. As you may know, Guido generally discourages pure code cleanups and prefers that they be done when the code is examined for other purposes. I personally think some changes are safe enough if verified by a second person. I looked for and did not fine test/test_turtle. Did I miss something? Turtledemo is a partial substitute, but it might not exercise all turtle functions. If you only apply cleanups to 3.5, subsequent bug fixes for all 3 versions will become much more difficult. The default commit process assumes that maintenance patches merge forward cleanly. I try to keep Idle code the same across versions as much as possible. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21573 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Roundup Robot added the comment: New changeset b26d021081d2 by Brett Cannon in branch 'default': Issue #20383: Introduce importlib.util.module_from_spec(). http://hg.python.org/cpython/rev/b26d021081d2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Brett Cannon added the comment: After all the various revelations today about how much of a hassle and murky it would be to get types.ModuleType to do what we were after, I went ahead and kept importlib.util.module_from_spec(), but dropped the module argument bit. I also deconstructed _SpecMethods along the way while keeping the abstractions as Eric requested. -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21577] Help for ImportError should show a more useful signature.
Terry J. Reedy added the comment: Your example in #21578 suggests that **kwargs should be deleted. *args is right. ImportError(3, 'a') ImportError(3, 'a') Should not this be fixed by ArgClinic conversion, and is not there an issue for that for exceptions? -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21577 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21500] Make use of the load_tests protocol in test_importlib packages
R. David Murray added the comment: Personally I think the fact that this doesn't work by default is a bug in unittest. See issue 15007. Issue 16662 may also be related. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21500 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21582] use support.captured_stdx context managers - test_asyncore
Terry J. Reedy added the comment: Since asyncore is depracated, I don't know if tests are being updated, or if this should be closed. -- nosy: +josiahcarlson, stutzbach, terry.reedy title: use support.catpured context managers - test_asyncore - use support.captured_stdx context managers - test_asyncore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21504] can the subprocess module war using os.wait4 and so return usage?
R. David Murray added the comment: I think the answer is that if you want that level of control you can't use communicate, you have to implement what you specifically need. I'm going to close this as rejected. It could be reopened if someone can find a way to propose something that makes sense cross-platform. -- nosy: +r.david.murray resolution: - rejected stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21583] use support.captured_stderr context manager - test_logging
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +vinay.sajip stage: - patch review title: use support.catpured_stderr context manager - test_logging - use support.captured_stderr context manager - test_logging type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21583 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21591] exec(a, b, c) not the same as exec a in b, c in nested functions
Terry J. Reedy added the comment:
The exception appears to be intentional, though I do not know what a
'qualified' exec would be. But since the tuple form is intended to mimic 3.x
exec, and since a reduced version of your example
c = '''
def g():
def f():
if True:
exec(, {}, {})
'''
compile(c, code, exec)
runs fine in 3.4, I agree that this appears to be a 2.7 compiler bug.
--
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, terry.reedy
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20383] Add a keyword-only spec argument to types.ModuleType
Eric Snow added the comment: Thanks for doing that Brett and for accommodating me. :) Also, the various little cleanups are much appreciated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21592] Make statistics.median run in linear time
Terry J. Reedy added the comment: To accept contributions, we need a signed (possibly electronically) contribution form. https://www.python.org/psf/contrib/contrib-form/ -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
