2nd RFD: comp.sys.raspberry-pi - LAST CALL FOR COMMENTS
SECOND REQUEST FOR DISCUSSION (RFD) unmoderated group comp.sys.raspberry-pi LAST CALL FOR COMMENTS This is a formal Request for Discussion (RFD) for the creation of the unmoderated newsgroup comp.sys.raspberry-pi. NEWSGROUPS LINE: comp.sys.raspberry-pi Raspberry Pi computers & related hardware and software RATIONALE: * Discussions on this topic have so far been widely and thinly spread on Usenet - e.g. google site:groups.google.com/group/comp "raspberry pi" * The RFD (published 9 March 2013) was well supported with positive responses CHARTER: Newsgroup comp.sys.raspberry-pi is for discussion of issues connected with Raspberry Pi computer systems including set up, programming, software, operating systems, interfacing, related hardware and projects. Posters are expected to abide by normal Usenet standards of decorum, and to ignore articles intended to disrupt the group. The usual suspects are prohibited (spam, binaries, direct advertising, etc.) PROCEDURE: Please refer to the newsgroup creation policies listed here: http://www.big-8.org/wiki/How_to_Create_a_New_Big-8_Newsgroup All discussion of active proposals should be posted to news.groups.proposals. To this end, the followup header of this RFD has been set to news.groups.proposals. The final comment period lasts for five (5) days from the time that this RFD is posted. DISTRIBUTION: This document has been posted to the following newsgroups: news.announce.newgroups news.groups.proposals comp.lang.forth comp.lang.python comp.os.linux.misc Pointers will also be posted to: comp.arch.embedded uk.comp.homebuilt uk.comp.os.linux comp.sys.apple2 PROPONENT: James Harris james.harris.1Agmail.com (replace A with @) CHANGE HISTORY: 2013-03-09 Initial RFD 2013-03-16 This LCC -- http://mail.python.org/mailman/listinfo/python-list
sqlite3 - a create of table x fails after dropping table x (only on Windows)
Interested to understand this problem. It only happens in Windows, not MacOS.
Running python 2.7.3. sqlite3 3.7.12. The following script:
import sqlite3
table_name = 'table_name'
conn = sqlite3.connect('data2.db')
c = conn.cursor()
sql = 'create table if not exists ' + table_name + ' (id integer)'
c.execute(sql)
sql = 'drop table ' + table_name
c.execute(sql)
sql = 'create table if not exists ' + table_name + ' (id integer)'
c.execute(sql)
sql = 'insert into ' + table_name + ' (id) values (%d)' % 97
c.execute(sql)
conn.commit()
Fails every other time it is executed. Here's the error:
Traceback (most recent call last):
File "C:/Users/potrebic/PycharmProjects/play/play.py", line 15, in
c.execute(sql)
sqlite3.OperationalError: no such table: table_name
line 15 is the execute of the 'insert' stmt.
If the "if not exists" is removed from line 11, then the scripts works every
time.
(Note - on MacOS it succeeds every time).
--
http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
On Fri, 15 Mar 2013 21:26:28 -0700, rusi wrote: > The unicode standard is language-agnostic. Unicode implementations exist > withing a language x implementation x C- compiler implementation x … -- > Notice the gccs in Andriy's comparison. Do they signify? They should not. Ideally, the behaviour of Python should be identical regardless of the compiler used to build the Python interpreter. In practice, this is not necessarily the case. One compiler might generate more efficient code than another. But aside from *performance*, the semantics of what Python does should be identical, except where noted as "implementation dependent". > The number of actual python implementations is small -- 2.7, 3.1, 3.2, > 3.3 -- at most enlarged with wides and narrows; The number of possible > implementations is large (in principle infinite) IronPython and Jython will, if I understand correctly, inherit their string implementations from .Net and Java. > -- a small example of a point in design-space that is not explored: eg > > There are 17 planes x 2^16 chars in a plane < 32 x 2^16 > = 2^5 x 2^16 > = 2^21 > > ie wide unicode (including the astral planes) can fit into 21 bits ie 3 > wide-chars can fit into 64 bit slot rather than 2. Is this option worth > considering? Ive no idea and I would wager that no one does until some > trials are done As I understand it, modern CPUs and memory chips are optimized for dealing with either two things: - single bytes; - even numbers of bytes, e.g. 16 bits, 32 bits, 64 bits, ... but not odd numbers of bytes, e.g. 24 bits, 40 bits, 72 bits, ... So while you might save memory by using "UTF-24" instead of UTF-32, it would probably be slower because you would have to grab three bytes at a time instead of four, and the hardware probably does not directly support that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Simple Plot in Python
Dear Group, I have two sets of values in probability, like, x=[0.1,0.2,0.3,0.4] and y=[0.2,0.4,0.6,0.8] And I am trying to draw a simple graph with Python. I was trying to draw in Matplotlib but did not find much help. If any one in the room can kindly suggest. Thanking You in Advance, Regards, Subhabrata. -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple Plot in Python
subhabangal...@gmail.com wrote: >I was trying to draw in Matplotlib but did not find much help. Have you looked already at the homepape for "maptlotlib"?: http://matplotlib.org/index.html There you'll find a tutorial: http://matplotlib.org/users/pyplot_tutorial.html Bye, Andreas -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
In article <51440235$0$29965$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > UTF-32 is a *fixed width* storage mechanism where every code point takes > exactly four bytes. Since the entire Unicode range will fit in four > bytes, that ensures that every code point is covered, and there is no > need to walk the string every time you perform an indexing operation. But > it means that if you're one of the 99.9% of users who mostly use > characters in the BMP, your strings take twice as much space as > necessary. If you only use Latin1 or ASCII, your strings take four times > as much space as necessary. I suspect that eventually, UTF-32 will win out. I'm not sure when "eventually" is, but maybe sometime in the next 10-20 years. When I was starting out, the computer industry had a variety of character encodings designed to take up less than 8 bits per character. Sixbit, Rad-50, BCD, and so on. Each of these added complexity and took away character set richness, but saved a few bits. At the time, memory was so expensive and so precious, it was worth it. Over the years, memory became cheaper, address spaces grew from 16 to 32 to 64 bits, and the pressure to use richer character sets kept increasing. So, now we're at the point where people are (mostly) using Unicode, but are still arguing about which encoding to use because the "best" complexity/space tradeoff isn't obvious. At some point in the future, memory will be so cheap, and so ubiquitous, that people will be wondering why us neanderthals bothered worrying about trying to save 16 bits per character. Of course, by then, we'll be migrating to Mongocode and arguing about UTF-64 :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple Plot in Python
On Saturday, March 16, 2013 5:12:41 PM UTC+5:30, subhaba...@gmail.com wrote: > Dear Group, > > > > I have two sets of values in probability, like, > > > > x=[0.1,0.2,0.3,0.4] > > and > > y=[0.2,0.4,0.6,0.8] > > > > And I am trying to draw a simple graph with Python. > > > > I was trying to draw in Matplotlib but did not find much help. > > > > If any one in the room can kindly suggest. > > > > Thanking You in Advance, > > Regards, > > Subhabrata. Thanks. I don't know why it slipped my eyes. Regards, Subhabrata. -- http://mail.python.org/mailman/listinfo/python-list
What am I doing wrong in this simple tkinter example?
Hi all, I'm well into "Python Programming for the Absolute Beginner" in order to become more acquainted with the language. However, when I got to page 304 and did my first example: http://bin.cakephp.org/view/1107093008 And this is the error that I'm getting: http://bin.cakephp.org/view/399711843 This is the code that came with the book: http://bin.cakephp.org/view/514822432 What I don't understand is, why am I getting that error? I've done diff -w and the code looks for the most part the same. What am I doing wrong when I put the application together? -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On Sun, Mar 17, 2013 at 1:53 AM, Yves S. Garret wrote: > Hi all, I'm well into "Python Programming for the Absolute Beginner" in order > to > become more acquainted with the language. However, when I got to page 304 and > did my first example: > > http://bin.cakephp.org/view/1107093008 > > And this is the error that I'm getting: > > http://bin.cakephp.org/view/399711843 > > This is the code that came with the book: > > http://bin.cakephp.org/view/514822432 > > > What I don't understand is, why am I getting that error? I've done diff -w > and the code looks for the most part the same. What am I doing wrong when I > put the application together? self.secret_txt.delete(0.0, END) self.secret_txt.delete(0.0, message) Is the second one supposed to be adding text? I'm not familiar with tkinter but that's the line with the error, and it looks a little odd. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On 03/16/2013 10:53 AM, Yves S. Garret wrote: Hi all, I'm well into "Python Programming for the Absolute Beginner" in order to > become more acquainted with the language. However, when I got to page 304 and > did my first example: > > http://bin.cakephp.org/view/1107093008 > > And this is the error that I'm getting: > > http://bin.cakephp.org/view/399711843 > > This is the code that came with the book: > > http://bin.cakephp.org/view/514822432 > > > What I don't understand is, why am I getting that error? I've done diff -w > and the code looks for the most part the same. What am I doing wrong when I > put the application together? The error is that indexes are supposed to be integers, instead you have a text string: "That's not the correct password, so I can't s hare the secret with you." -m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ The existence of any evil anywhere at any time absolutely ruins a total optimism. George Santayana -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On Saturday, March 16, 2013 11:10:07 AM UTC-4, Mitya Sirenef wrote: > On 03/16/2013 10:53 AM, Yves S. Garret wrote: > > > Hi all, I'm well into "Python Programming for the Absolute Beginner" in > > order to > > > become more acquainted with the language. However, when I got to page > > 304 and > > > did my first example: > > > > > > http://bin.cakephp.org/view/1107093008 > > > > > > And this is the error that I'm getting: > > > > > > http://bin.cakephp.org/view/399711843 > > > > > > This is the code that came with the book: > > > > > > http://bin.cakephp.org/view/514822432 > > > > > > > > > What I don't understand is, why am I getting that error? I've done > > diff -w > > > and the code looks for the most part the same. What am I doing wrong > > when I > > > put the application together? > > > > > > The error is that indexes are supposed to be integers, instead you have > > a text string: > > > > "That's not the correct password, so I can't s hare the secret with you." > > > > > > -m > > > > > > -- > > Lark's Tongue Guide to Python: http://lightbird.net/larks/ > > > > The existence of any evil anywhere at any time absolutely ruins a total > > optimism. George Santayana *shrug* In the example that I have posted from the book it works just fine. I also used this batch file to help me along. longevity.py pause Hence the question mark over my head at the moment :) . -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On Saturday, March 16, 2013 11:08:24 AM UTC-4, Chris Angelico wrote: > On Sun, Mar 17, 2013 at 1:53 AM, Yves S. Garret > > wrote: > > > Hi all, I'm well into "Python Programming for the Absolute Beginner" in > > order to > > > become more acquainted with the language. However, when I got to page 304 > > and > > > did my first example: > > > > > > http://bin.cakephp.org/view/1107093008 > > > > > > And this is the error that I'm getting: > > > > > > http://bin.cakephp.org/view/399711843 > > > > > > This is the code that came with the book: > > > > > > http://bin.cakephp.org/view/514822432 > > > > > > > > > What I don't understand is, why am I getting that error? I've done diff -w > > > and the code looks for the most part the same. What am I doing wrong when I > > > put the application together? > > > > self.secret_txt.delete(0.0, END) > > self.secret_txt.delete(0.0, message) > > > > Is the second one supposed to be adding text? I'm not familiar with > > tkinter but that's the line with the error, and it looks a little odd. > > > > ChrisA Yes, the second line is supposed to add the text. -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On Sun, Mar 17, 2013 at 2:16 AM, Yves S. Garret wrote: > In the example that I have posted from the book it works just fine. Yep, I just checked the book's version again and the difference is clear. Check out the two lines I quoted in my previous post, and look at the corresponding two lines in the book's version. You should see the difference. :) By the way, I like the choice of secret. It lends itself well to a discussion of recursion - how do you live to 99? Live to 98, then be careful. Etcetera. You need just one special case: How do you live to 1? Be born, then be careful. And there you have it, a perfect problem for defining recursion vs iteration, as both can do the job! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
New Python book, "Learn Python Quickly"
Hi All, You may be interested in my latest book "Learn Python Quickly". It's a Kindle book but is specifically designed to be used with any of the free-to-download Kindle Reading Apps. What's special about the book is its comprehensive glossary and the numerous in-text internal hyperlinks to topics in the glossary, allowing the reader to quickly jump to glossary topics to clarify the terms used in the text. The book can be followed by those with zero prior knowledge of the language and very little general language experience, but leads the reader in easy stages to quite sophisticated coding skills including classes and Graphical User Interface (GUI) programming. There are numerous graded exercises, all with sample answers at the end of the book. There is also a companion web site from which those programs can be freely copied and used immediately in Python's IDLE interface. (This overcomes the copying restriction imposed on Kindle books.) The programs and lots of Information about the book (including sample chapters and an extract from the glossary) can be found on www.learnpythonquickly.com and the book itself is available from Amazon, from where you can download the reading apps and then download a further sample of the book onto those apps. I do hope you find this of interest. Kind regards, John Rowland -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
Am 16.03.13 16:14, schrieb Yves S. Garret: On Saturday, March 16, 2013 11:08:24 AM UTC-4, Chris Angelico wrote: self.secret_txt.delete(0.0, END) self.secret_txt.delete(0.0, message) Is the second one supposed to be adding text? I'm not familiar with tkinter but that's the line with the error, and it looks a little odd. Yes, the second line is supposed to add the text. Think about it. "delete" is not going to add text. You want "insert" instead. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On Saturday, March 16, 2013 11:23:07 AM UTC-4, Chris Angelico wrote: > On Sun, Mar 17, 2013 at 2:16 AM, Yves S. Garret > > wrote: > > > In the example that I have posted from the book it works just fine. > > > > Yep, I just checked the book's version again and the difference is > > clear. Check out the two lines I quoted in my previous post, and look > > at the corresponding two lines in the book's version. You should see > > the difference. :) > > > > By the way, I like the choice of secret. It lends itself well to a > > discussion of recursion - how do you live to 99? Live to 98, then be > > careful. Etcetera. You need just one special case: How do you live to > > 1? Be born, then be careful. And there you have it, a perfect problem > > for defining recursion vs iteration, as both can do the job! > > > > ChrisA *facepalm* Yep, I see it :) . Thanks for your help. -- http://mail.python.org/mailman/listinfo/python-list
Re: What am I doing wrong in this simple tkinter example?
On 03/16/2013 11:16 AM, Yves S. Garret wrote: On Saturday, March 16, 2013 11:10:07 AM UTC-4, Mitya Sirenef wrote: On 03/16/2013 10:53 AM, Yves S. Garret wrote: Hi all, I'm well into "Python Programming for the Absolute Beginner" in order to > become more acquainted with the language. However, when I got to page 304 and > did my first example: > > http://bin.cakephp.org/view/1107093008 > > And this is the error that I'm getting: > > http://bin.cakephp.org/view/399711843 > > This is the code that came with the book: > > http://bin.cakephp.org/view/514822432 > > > What I don't understand is, why am I getting that error? I've done diff -w > and the code looks for the most part the same. What am I doing wrong when I > put the application together? The error is that indexes are supposed to be integers, instead you have a text string: "That's not the correct password, so I can't s hare the secret with you." -m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ The existence of any evil anywhere at any time absolutely ruins a total optimism. George Santayana *shrug* In the example that I have posted from the book it works just fine. I also used this batch file to help me along. longevity.py pause Hence the question mark over my head at the moment :) . You are giving a message to the delete call, but delete call needs an integer to work. In the book, it's not a delete call but an insert call that's why it works there. -m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
On Mar 16, 6:29 pm, Roy Smith wrote: > In article <51440235$0$29965$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > > > UTF-32 is a *fixed width* storage mechanism where every code point takes > > exactly four bytes. Since the entire Unicode range will fit in four > > bytes, that ensures that every code point is covered, and there is no > > need to walk the string every time you perform an indexing operation. But > > it means that if you're one of the 99.9% of users who mostly use > > characters in the BMP, your strings take twice as much space as > > necessary. If you only use Latin1 or ASCII, your strings take four times > > as much space as necessary. > > I suspect that eventually, UTF-32 will win out. I'm not sure when > "eventually" is, but maybe sometime in the next 10-20 years. There is an article by Tim O'Reilly IIRC that talks of a certain prognostication that went wrong. [If someone knows this article please give me the link] The gist as I remember it was: First there were audio cassettes and LPs. Then came CDs with far better fidelity. As Moore's law went its relentless way, the audio industry puts its hope into formats that would double CD quality. Whereas the public went with mp3s, ie a distinctly lower quality format, because putting a thousand CDs into my pocket beats the pants of some super-duper hi- fi new CD. So while Moore's law takes its course, public demand and therefore big money and therefore new standards may go some other way, including reverse. I believe that there are many things about unicode that are less than satisfactory. Some are downright asinine like the 'prime-real-estate' devoted to the control characters and never used. In short, I am not betting on UTF-32. Of course the reverse side also is there: Some of the world's most un- optimal standards are also the most ubiquitous, like the qwerty keyboard. -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
In article <70844d17-22bd-4394-86e2-d7ef3efc6...@ps9g2000pbb.googlegroups.com>, rusi wrote: > I believe that there are many things about unicode that are less than > satisfactory. Some are downright asinine like the 'prime-real-estate' > devoted to the control characters and never used. Ah, but in UTF-32, all real-estate is the same price :-) -- http://mail.python.org/mailman/listinfo/python-list
PyWart: NameError trackbacks are superfluous
Sometimes many levels of trace messages can be helpful when detecting bugs, however, in the case of NameErrors, these "nuggets" ejected from deep within the bowls of the Python interpreter are nothing more than steaming piles of incomprehensible crap! We don't need multiple layers of traces for NameErrors. Python does not have *real* global variables; and thank Guido for that! All we need to know is which module the error occurred in AND which line of that module contains the offensive lookup of a name that does not exist. Here is a fine example -- Contents of mod1.py -- print symbolNonExistant -- Contents of mod2.py -- import mod1 -- Contents of mod3.py -- import mod2 Results of executing mod3.py Traceback (most recent call last): File "C:/a/b/c/mod3.py", line 2, in import mod2 File "C:/a/b/c/mod2.py", line 1, in import mod1 File "C:/a/b/c/mod1.py", line 2, in print symbolNonExistant NameError: name 'symbolNonExistant' is not defined Why did i need to see all that junk when all i really need to see was this: Traceback (most recent call last): File "C:/a/b/c/mod1.py", line 2, in print symbolNonExistant NameError: name 'symbolNonExistant' is not defined Or event better: NameError: name 'symbolNonExistant' is not defined File "C:/a/b/c/mod1.py", line 2, in print symbolNonExistant -- http://mail.python.org/mailman/listinfo/python-list
Re: Im fetching data from excel using python code.. i could see some junk value also with it.
On Sat, Mar 16, 2013 at 2:50 AM, dieter wrote: > s.arun...@gmail.com writes: > > > Hi im fetching data from excel using python code.. i could see some junk > value also with it. like [text:u > I used the xlrd module some time back. I think if you google for tutorial on it you will find your answer > > > > How to remove it.. below is the code > > It is very difficult to extract data reliably from an undocumented binary > format (such as "excel" files): things can change between versions, > some "features" may be used only in particular situations > difficult to get at by reverse engineering, > lacking a complete documentation completeness is difficult to get. > This isn't true. The xlrd module takes care of this > > I see two options for you: > > * send a problem report with your data to the "xlrd" author > > He may know how to fix it. > > * Tell "excel" to export the file to "csv" and > use Python's "csv" mode to read the values. > I agree, that this is a simpler aproach > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Joel Goldstick http://joelgoldstick.com -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the easiest Python datagrid GUI (preferably with easy database hooks as well)?
> Very helpful collection, only one open question: which of them work > with Python 3? No clue, sorry. Given how many other modules are not yet compatible with Python 3, I haven't investigated that yet. wxwidgets/wxPython already has *just* made the switch to Cocoa (with 2.9) when Carbon support was dropped by Apple, and I don't have a clue about the future of PyGTK (last update 2011, seems to have been replaced by PyGObject). > Will look at Pypapi and SQLkit. Frustrated with Dabo? Why? Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
-- utf-32 is already here. You are all most probably [*] using it without noticing it. How? By using OpenType fonts, without counting the text processing applications using them. Why? Because there is no other way to do it. [*] depending of the font, the internal table(s), eg "cmap" table, are in utf-16 or utf-32. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On 16 March 2013 18:27, Rick Johnson wrote: > > Sometimes many levels of trace messages can be helpful when detecting bugs, > however, in the case of NameErrors, these "nuggets" ejected from deep within > the bowls of the Python interpreter are nothing more than steaming piles of > incomprehensible crap! > > We don't need multiple layers of traces for NameErrors. Python does not have > *real* global variables; and thank Guido for that! All we need to know is > which module the error occurred in AND which line of that module contains the > offensive lookup of a name that does not exist. [SNIP] NameErrors can occur conditionally depending on e.g. the arguments to a function. Consider the following script: # tmp.py def broken(x): if x > 2: print(x) else: print(undefined_name) broken(1) When run it gives a NameError with a traceback: $ python tmp.py Traceback (most recent call last): File "tmp3.py", line 8, in broken(1) File "tmp3.py", line 6, in broken print(undefined_name) NameError: global name 'undefined_name' is not defined The traceback shows the arguments passed to the broken function that caused the NameError to be generated. Different arguments would not have generated the NameError. This information can be useful if the logic of the function in question is complicated. It also hints at why you were calling the function and what your code is trying to do. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
Steven D'Aprano: So while you might save memory by using "UTF-24" instead of UTF-32, it would probably be slower because you would have to grab three bytes at a time instead of four, and the hardware probably does not directly support that. Low-level string manipulation often deals with blocks larger than an individual character for speed. Generally 32 or 64-bits at a time using the CPU or 128 or 256 using the vector unit. Then there may be entry/exit code to handle initial alignment to a block boundary and dealing with a smaller than block-size tail. For an example of this kind of thing, see find_max_char in python\Objects\stringlib\find_max_char.h which can examine a char* 32 or 64-bits at a time. 24-bit is likely to be a win in many circumstances due to decreased memory traffic. a 12-bit implementation may also be worthwhile as the low 0x1000 characters of Unicode contains Latin (with extensions), Greek, Cyrillic, Arabic, Hebrew, and most Indic scripts. Neil -- http://mail.python.org/mailman/listinfo/python-list
Having a hard time installing pygame on Win7.
Hi all, got a small problem. As I'm going through "Python Programming for the Absolute Beginner", I got to chapter 11 and as I'm working through it, I can't seem to get pygame/livewires installed... I don't even know how to go about installing it (the book is skimpy on details). I'm using Python 3.3.0 for the job. Has anyone else had the same problems? -- http://mail.python.org/mailman/listinfo/python-list
Re: String performance regression from python 3.2 to 3.3
In article , Neil Hodgson wrote: > Low-level string manipulation often deals with blocks larger than > an individual character for speed. Generally 32 or 64-bits at a time > using the CPU or 128 or 256 using the vector unit. Then there may be > entry/exit code to handle initial alignment to a block boundary and > dealing with a smaller than block-size tail. Duff's Device! -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote:
>
> NameErrors can occur conditionally depending on e.g. the
> arguments to a function. Consider the following script:
>
> # tmp.py
> def broken(x):
> if x > 2:
> print(x)
> else:
> print(undefined_name)
>
> broken(1)
Why would anyone write code like that? That's like arming your toilet paper
holder with a bomb set to explode if the RPMs of the spinning roll exceed a
small threshold. Sure, you could do it, but why the hell would you? The only
way your code could be any worse is by picking a random RPM threshold every
morning!
import random
from home.bathroom import ToiletPaperHolder
RPMS = range(100)
def maybeGoBoom(event):
maxRpm = random.choice(RPMS)
if event.RPM > maxRpm:
roll.explode()
tph = ToiletPaperHolder()
if not tph.has_roll():
tph.load_roll()
roll = tph.get_active_roll()
roll.bind("", maybeGoBoom)
> The traceback shows the arguments passed to the broken
> function that caused the NameError to be generated.
> Different arguments would not have generated the
> NameError. This information can be useful if the logic of
> the function in question is complicated. It also hints at
> why you were calling the function and what your code is
> trying to do.
If you want to observe your code "in action" there are much better ways than
eyeball-parsing lines and lines of trackbacks. The code you posted is nonsense,
maybe you can provide a better example that will convince me, but that one
failed miserably.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On 16 March 2013 22:39, Rick Johnson wrote: > On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote: > >> The traceback shows the arguments passed to the broken >> function that caused the NameError to be generated. >> Different arguments would not have generated the >> NameError. This information can be useful if the logic of >> the function in question is complicated. It also hints at >> why you were calling the function and what your code is >> trying to do. > > If you want to observe your code "in action" there are much better ways than > eyeball-parsing lines and lines of trackbacks. The code you posted is > nonsense, maybe you can provide a better example that will convince me, but > that one failed miserably. I wasn't looking to convince *you*, just to set the record straight that this behaviour is sometimes useful. In any case, even when the traceback information is not helpful, printing it is really not a problem and hardly a "wart". Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On 2013-03-16 15:39, Rick Johnson wrote: > On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote: > > # tmp.py > > def broken(x): > > if x > 2: > > print(x) > > else: > > print(undefined_name) > > > > broken(1) > > Why would anyone write code like that? Because, in the real world, that example looks something like def broken(intelligence_level): if intelligence_level < 100: return dumb_down(intellegence_level) else: return make_harder(intelligence_level) broken(op.iq) Pylint, pyflakes or some other such linter should catch it, but this happens ALL THE TIME in actual development, occasionally leaking into production. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sun, Mar 17, 2013 at 10:36 AM, Tim Chase wrote: > Because, in the real world, that example looks something like > > def broken(intelligence_level): > if intelligence_level < 100: > return dumb_down(intellegence_level) > else: > return make_harder(intelligence_level) > broken(op.iq) > > Pylint, pyflakes or some other such linter should catch it, but this > happens ALL THE TIME in actual development, occasionally leaking into > production. That's actually an argument in favour of declared variables. NameError becomes a parse-time failure :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sat, 16 Mar 2013 21:19:34 +, Oscar Benjamin wrote:
> On 16 March 2013 18:27, Rick Johnson
> wrote:
>>
>> Sometimes many levels of trace messages can be helpful when detecting
>> bugs, however, in the case of NameErrors, these "nuggets" ejected from
>> deep within the bowls of the Python interpreter are nothing more than
>> steaming piles of incomprehensible crap!
>>
>> We don't need multiple layers of traces for NameErrors. Python does not
>> have *real* global variables; and thank Guido for that! All we need to
>> know is which module the error occurred in AND which line of that
>> module contains the offensive lookup of a name that does not exist.
> [SNIP]
/head-desk
Is Rick still pushing these stupid "PyWart" ideas?
> NameErrors can occur conditionally depending on e.g. the arguments to a
> function. Consider the following script:
[...]
Correct, although in your example, simply pointing at the relevant line
of code is enough to establish the error.
But that's an easy case. Tracebacks aren't printed because you need them
to fix the easy bugs. Tracebacks are printed so you have a hope of fixing
the hard bugs. NameError is no different in this than any other
exception, and the Zen applies:
Special cases aren't special enough to break the rules.
NameErrors are exceptions like any other. They aren't special enough to
suppress the full traceback when a NameError occurs. In the easy cases,
you can just ignore the full traceback, and no harm is done. In the hard
cases, you will need it.
Since name bindings ("variables") in Python are dynamic, not static,
whether or not a name exists at any time can depend *when* and *how* you
call a line of code, not just which line of code. That is, whether or not
a line of code will raise NameError can depend on which lines of code are
called before it, and that depends on the function call chain shown by
the traceback.
Here's a truly trivial case where code will succeed or fail depending on
the order of function calls.
def display():
print("spam = %d" % spam)
def start():
global spam
spam = 23
def stop():
global spam
del spam
def run():
print("*** Succeeds ***")
start()
display()
stop()
def fail():
print("*** Fails ***")
start()
stop()
display()
run()
fail()
It's not enough to know that the print line in display() fails, because
that's merely the side-effect. The actual problem occurs in the caller,
fail(). If NameError suppressed the traceback, that would be more
difficult to solve.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Saturday, March 16, 2013 6:29:52 PM UTC-5, Oscar Benjamin wrote: > I wasn't looking to convince *you*, just to set the record > straight that this behaviour is sometimes useful. And you claim to "set the record strait" by posting code that *purposely* raises a NameError when some function parameter is not within a predefined range? That's ludicrous! Look, i don't want you to think that i am arguing with you, i just want you to show us an example that proves your argument to be true; but you cannot prove the argument by doing foolish things. Imagine the following scenario: * CarMakerA claims their new automobile is safest on the road. * CarMakerB purposely drives the car into a ditch and then claims the car is unsafe and CarMakerA is a liar. That's what your example just did! Please provide a "real world" example that proves your argument. I am open to changing my mind *IF* someone can provide proof. > In any case, even when the traceback information is not > helpful, printing it is really not a problem and hardly a > "wart". * Warts are ugly * Superfluous trackbacks are not only ugly, they damage productivity. Therefore this *IS* a wart. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sun, Mar 17, 2013 at 10:48 AM, Steven D'Aprano wrote: > Here's a truly trivial case where code will succeed or fail depending on > the order of function calls. > (chop code) > It's not enough to know that the print line in display() fails, because > that's merely the side-effect. The actual problem occurs in the caller, > fail(). If NameError suppressed the traceback, that would be more > difficult to solve. A good example. It would be logically equivalent to set spam=None in stop(), and nobody would expect the TypeError to omit the traceback, so why should delling the name be any different? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sun, Mar 17, 2013 at 10:50 AM, Rick Johnson wrote: > * Superfluous trackbacks are not only ugly, they damage >productivity. Extraordinary claims require extraordinary evidence. Start evidencing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
[ANNC] pynguin-0.13 python turtle graphics application now uses python 3
Pynguin is a python-based turtle graphics application.
It combines an editor, interactive interpreter, and
graphics display area.
It is meant to be an easy environment for introducing
some programming concepts to beginning programmers.
http://pynguin.googlecode.com/
This release ports Pynguin to Python 3.
Pynguin is tested with Python 3.2.3 and PyQt 4.9.3 and
will use Pygments syntax highlighting if available.
Pynguin is released under GPLv3.
Changes in pynguin-0.13:
Now uses (requires) Python 3
- Tested with Python 3.2.3
Important fixes
- New approach for threading of user code
- should provide safer, more reliable, termination of user code
- can now reliably stop code like ... while 1: pass
- Preserves fill state and color when changing avatar
Other fixes
- Preserves name label when changing avatar
- Tries harder to go as fast as possible for "instant" setting
- throttles back on CPU when not running user code
Pynguin API
- Logo-mode coordinates and angles now available
- Switch mode using Pynguin -> Mode -> Logo
- or create new instance with mlogo=ModeLogo()
- Python turtle-mode coordinates and angles now available
- Switch mode using Pynguin -> Mode -> Turtle
- or create new instance with mturtle=ModeTurtle()
- xy(x, y) re-uses goto(x, y) code
- xyh() uses xy() and h() to retrieve values
- color() takes an optional alpha channel value for transparency
- color('ralpha') chooses a random color with random alpha
- Each pynguin's speed can now be set individually
Canvas
- Added a dialog for pen, background, and fill default colors
- sets these colors on program startup
- uses these colors for reset()
- also used when adding new pynguins
- Can now track any pynguin
- Can zoom to fit entire drawing
UI
- Added new Pynguin menu for avatar and mode selection
- Added alpha value selector to pen and fill color dialogs
Integrated Editor
Integrated Console
Examples
- All ported to Python 3
- Added examples using colors with alpha channel values
- Added finish line to horserace
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Saturday, March 16, 2013 6:48:01 PM UTC-5, Steven D'Aprano wrote:
> On Sat, 16 Mar 2013 21:19:34 +, Oscar Benjamin wrote:
> > [...]
> > NameErrors can occur conditionally depending on e.g. the
> > arguments to a function. Consider the following script:
> [...]
>
> Correct, although in your example, simply pointing at the
> relevant line of code is enough to establish the error.
EXACTLY!
> [...]
> Here's a truly trivial case where code will succeed or
> fail depending on the order of function calls.
>
> def display():
> print("spam = %d" % spam)
>
> def start():
> global spam
> spam = 23
>
> def stop():
> global spam
> del spam
>
> def run():
> print("*** Succeeds ***")
> start()
> display()
> stop()
>
> def fail():
> print("*** Fails ***")
> start()
> stop()
> display()
>
> run()
>
> fail()
>
> It's not enough to know that the print line in display()
> fails, because that's merely the side-effect. The actual
> problem occurs in the caller, fail().
No, the "ACTUAL PROBLEM" is in the author.
Who would be stupid enough to write code that depends on globals that *may* or
*may not* exist, and then go an add insult to injury by not testing for the
name before executing the code? Your example is a fine example of why using
globals is foolish.
Congratulations Steven, you drove the car into the ditch -- even a noob can do
that!
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On 03/16/2013 06:11 PM, Rick Johnson wrote: > No, the "ACTUAL PROBLEM" is in the author. Surely any NameException can also be blamed on the author then, by your logic? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote: > On 03/16/2013 06:11 PM, Rick Johnson wrote: >> No, the "ACTUAL PROBLEM" is in the author. > > Surely any NameException can also be blamed on the author then, by your > logic? Any exception at all is obviously the author's fault. I propose that Python stops wasting our time with debugging information and tracebacks, and on any error, simply prints the following message then dump core: PEBKACError: Programmer is an idiot. You did something wrong, you moron, turn your computer off, you're obviously too stupid to program. That will certainly improve productivity. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sun, Mar 17, 2013 at 2:14 PM, Steven D'Aprano wrote: > On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote: > >> On 03/16/2013 06:11 PM, Rick Johnson wrote: >>> No, the "ACTUAL PROBLEM" is in the author. >> >> Surely any NameException can also be blamed on the author then, by your >> logic? > > Any exception at all is obviously the author's fault. I propose that > Python stops wasting our time with debugging information and tracebacks, > and on any error, simply prints the following message then dump core: > > > PEBKACError: Programmer is an idiot. You did something wrong, you moron, > turn your computer off, you're obviously too stupid to program. > > > That will certainly improve productivity. Why dump core? That seems far too useful to fit with the rest of your proposal. Just exit 0 - after all, it wasn't Python's fault, so it obviously succeeded. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: NameError trackbacks are superfluous
On Sat, Mar 16, 2013 at 8:14 PM, Steven D'Aprano wrote: > On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote: > >> On 03/16/2013 06:11 PM, Rick Johnson wrote: >>> No, the "ACTUAL PROBLEM" is in the author. >> >> Surely any NameException can also be blamed on the author then, by your >> logic? > > Any exception at all is obviously the author's fault. I propose that > Python stops wasting our time with debugging information and tracebacks, > and on any error, simply prints the following message then dump core: > > > PEBKACError: Programmer is an idiot. You did something wrong, you moron, > turn your computer off, you're obviously too stupid to program. > > > That will certainly improve productivity. > > -- > Steven Don't have it dump core. Have it print a pink slip to the default printer. -- http://mail.python.org/mailman/listinfo/python-list
How to automatically get the indent level from code?
Hi, I want to get the indent level within the code. For example, I want to print 1 within the while loop as the line is indented 1 level. Is it possible to get it within python? while 1: #print the level of indent, which is 1 here. -- Regards, Peng -- http://mail.python.org/mailman/listinfo/python-list
Re: How to automatically get the indent level from code?
No On Sun, Mar 17, 2013 at 12:52 AM, Peng Yu wrote: > Hi, > > I want to get the indent level within the code. For example, I want to > print 1 within the while loop as the line is indented 1 level. Is it > possible to get it within python? > > while 1: >#print the level of indent, which is 1 here. > > -- > Regards, > Peng > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
RE: How to automatically get the indent level from code?
I realize this isn't yet precisely what you're asking for, but look at the
inspect and ast modules:
import ast, inspect
def indent_level():
lineno = inspect.currentframe().f_back.f_lineno
with open(__file__) as source_file:
tree = ast.parse(source_file.read(), filename=__file__)
for node in ast.walk(tree):
if hasattr(node, 'lineno') and node.lineno == lineno:
return node.col_offset
def example_usage():
print("first indent_level() = {0}".format(indent_level()))
if True:
print("second indent_level() = {0}".format(indent_level()))
if __name__ == '__main__':
example_usage()
The indent_level function above returns the textual column offset rather than
the logical block level you're asking for, e.g.:
first indent_level() = 4
second indent_level() = 8
But hopefully it's a start.
Mark
-Original Message-
From: Python-list
[mailto:python-list-bounces+mshroyer=awaredigital@python.org] On Behalf Of
Peng Yu
Sent: Sunday, March 17, 2013 12:53 AM
To: python-list@python.org
Subject: How to automatically get the indent level from code?
Hi,
I want to get the indent level within the code. For example, I want to
print 1 within the while loop as the line is indented 1 level. Is it
possible to get it within python?
while 1:
#print the level of indent, which is 1 here.
--
Regards,
Peng
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
