Re: PyWart: Module access syntax
On Tue, Jan 15, 2013 at 6:49 PM, Rick Johnson
wrote:
> Look, maybe nobody has the time to deal with this module, so if you need some
> help, then feel free to ask for my assistance. All Guido has to do is send me
> a private email and say:
>
> """ Hello Rick! Your ideas for packaging of Tkinter are interesting, and i
> would like for you to send a patch over to {0} for immediate consideration.
> Thanks GvR """.format(destination)
Python's open source. Grab the source, do it, and post! Consider
yourself preemptively invited.
I'm not kidding. You don't need to wait for Guido's invitation to do
something. Just get in there, do something, and (preferably) show an
upgrade path from "current status" to "proposed status" - which might
involve a translation script similar to 2to3 - and people WILL take
notice.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: unit selection problem
Am 14.01.2013 21:29, schrieb Paul Pittlerson: map_textures = get_sprites( (48, 48) ,"spritesheet.png" , (0, 0) ) You forgot to include spritesheet.png in your message. Seriously, condense your code down to a minimal example. This might help you finding the problem yourself, otherwise post the complete compilable example here. Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Jan 15, 1:28 pm, "D'Arcy J.M. Cain" wrote: > Steven D'Aprano wrote: > > I disagree that Rick is a troll. Trolling requires that the troll > > Doesn't matter. He duck types as one. +1 Intent isn't magic. If Rick intends to contribute, he could actually contribute. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Mon, 14 Jan 2013 22:54:10 -0800, Rick Johnson wrote:
> No, classes DO NOT exist at runtime OR compile time! Classes are only
> *structured text* (or code if you prefer) that instruct Python to build
> *real* MEMORY OBJECTS for us. The "magic" that you are witnessing is
> Python, not classes.
Ultimately, everything in Python is "structured text", because the only
way to create a Python program is to write source code. Everything you
say is equally true for every other data type in Python. Floats. Strings.
Ints. Lists. Tuples. Dicts. *Everything*. They are only "structured text"
when they appear in source code, or on the command line, or in the
interactive interpreter, just like classes, and Python then constructs an
object in memory to represent that data structure. Just like classes.
So if you wish to deny that classes are objects, you also have to deny
that lists and strings and ints and floats are objects too.
In Python, either nothing is an object, or everything is an object. There
is no middle ground. You cannot treat classes differently from lists,
because Python treats them the same:
source code of a list literal => list object in memory
source code of a float literal => float object in memory
source code of a class definition => class object in memory
>> py> class Spam(object):
>> ... pass
>> ...
>> py> id(Spam)
>> 168149924
>> py> isinstance(Spam, type)
>> True
>
> Do you understand that your object definition named "Spam" is
> transformed into a memory object by python and that the id() function
> and the isinstance() function are operating on a memory object and not
> your structured text?
You don't need a class statement ("object definition") to create a class
object. Because classes are instances of the metaclass, there is a
default metaclass (called "type") that does the work of instantiating the
metaclass:
py> name = "Spam"
py> bases = (object,)
py> dict_ = {}
py> thingy = type(name, bases, dict_)
py> isinstance(thingy, type)
True
py> thingy
Classes are instances of type. That is reality in Python.
Classes are objects just like ints and strings and lists. This is a
fundamental design choice of Python. Deal with it.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] Data Plotting Library DISLIN 10.3
Dear Python users, I am pleased to announce version 10.3 of the data plotting software DISLIN. DISLIN is a high-level and easy to use plotting library for displaying data as curves, bar graphs, pie charts, 3D-colour plots, surfaces, contours and maps. Several output formats are supported such as X11, VGA, PostScript, PDF, CGM, WMF, HPGL, TIFF, GIF, PNG, BMP and SVG. The software is available for the most C, Fortran 77 and Fortran 90/95 compilers. Plotting extensions for the interpreting languages Perl, Python, Java, Ch, Ruby and TCL are also supported. DISLIN distributions and manuals in PDF and HTML format are available from the DISLIN home page http://www.dislin.de and via FTP from the server ftp://ftp.gwdg.de/pub/grafik/dislin All DISLIN distributions are free for non-commercial use. Licenses for commercial use are available from the site http://www.dislin.de. --- Helmut Michels Max Planck Institute for Solar System Research Phone: +49 5556 979-334 Max-Planck-Str. 2 Fax : +49 5556 979-240 D-37191 Katlenburg-Lindau Mail : mich...@mps.mpg.de -- http://mail.python.org/mailman/listinfo/python-list
interrupt the file sending if the file size over the quota...some errors here...
i want to interrupt the file sending. but i can't change the client. so i
need change the server.
All things go well, but the message i wanna response seem not work.
is the self.transport.loseConnection() (the last line) blocking the
messages?
in fact, i work on Cumulus(nimbus project) which based on twisted. And i
use s3cmd as the client.
here is the my code:
def headerReceived(self,line):
pycb.log(logging.INFO, "= def headerReceived of cumulus.py")
http.HTTPChannel.headerReceived(self,line)
pycb.log(logging.INFO, "= self.length is %s"%self.length)
header, data = line.split(':', 1)
header = header.lower()
data = data.strip()
if header=='authorization':
self.authorization=data
if self.length and self.authorization:
user_id = self.authorization.split(':')[0].split()[1].strip()
user = pycb.config.auth.get_user(user_id)
pycb.log(logging.INFO, "= user who put this object is
%s"%user)
remaining_quota = user.get_remaining_quota()
pycb.log(logging.INFO, "= remaining_quota is
%s"%remaining_quota)
quota_check=self.length-remaining_quota
pycb.log(logging.INFO, "=
quota_check=self.length-remaining_quota of cumulus.py")
if quota_check>0:
requestId = str(uuid.uuid1()).replace("-", "")
ex=cbException('AccountProblem')
m_msg = "HTTP/1.1 %s %s\r\n" % (ex.httpCode, ex.httpDesc)
self.transport.write(m_msg)
m_msg = "%s: %s\r\n" % (('x-amz-request-id', requestId))
self.transport.write(m_msg)
#req.setHeader('x-amz-request-id', requestId)
m_msg = "%s: %s\r\n" % (('x-amz-id-2', str(uuid.uuid1(
self.transport.write(m_msg)
e_msg = ex.make_xml_string(self._path, str(uuid.uuid1()))
pycb.log(logging.INFO, "= e_msg is %s"%e_msg)
#self.transport.write("\r\n")
self.transport.write(e_msg)
pycb.log(logging.INFO, "= self.transport.write(e_msg)")
self.transport.loseConnection()
--
http://mail.python.org/mailman/listinfo/python-list
atexit handler in IDLE?
Hello Pythonistas! I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: import atexit print "This is my program" def exit_func(): print "OK.. that's all folks!" atexit.register(exit_func) print "Program is ending..." When I run this on the command line I see: This is my program Program is ending... OK.. that's all folks! When I run this in IDLE I see: This is my program Program is ending... But the atexit handler is never called. ;-( I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. thanks! -steve -- http://mail.python.org/mailman/listinfo/python-list
Re: interrupt the file sending if the file size over the quota...some errors here...
Am 15.01.2013 10:46, schrieb Levi Nie: i want to interrupt the file sending. but i can't change the client. so i need change the server. All things go well, but the message i wanna response seem not work. Ahem, what? It doesn't work, so does it sit on the couch all day? is the self.transport.loseConnection() (the last line) blocking the messages? in fact, i work on Cumulus(nimbus project) which based on twisted. And i use s3cmd as the client. I'm wondering if questions concerning twisted don't have a better forum. In any case, I can only comment on the general approach. For that, there are two things you can do: 1. When receiving the the request header, you have a content length. If that exceeds the allowed amount, shutdown() receiving and send an according HTTP response before closing the connection. 2. If the data exceeds the amount advertised by the content length, close the connection and discard the request. If you want to be nice, send an according response before closing, but I personally wouldn't go to that effort for broken HTTP clients. Concerning the question why your client hangs, it could also be the sending. If you try to send something before receiving the full request, client and server could enter a deadlock where each side waits for the other to receive some data. For that reason, you should shutdown() receiving in such a case. HTH Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/14/2013 09:18 AM, Chris Angelico wrote: > On Tue, Jan 15, 2013 at 1:15 AM, Tim Chase > wrote: >> A newbie programmer had a problem and thought >> >> >> >> "I'll solve it by posting on >> >> >> >> python-list@python.org and on Google Groups". >> >> >> >> And now we have the problem of two threads... > And, when faced with problems of having two threads, the most obvious > solution is to add sleep() calls, so it looks like the above... Am I > dragging the analogy out too far? > > ChrisA Naaah, too far would be trying to relate the GIL to KILL files. For example, I avoid the google groups double-post syndrome by killfiling any message with google-groups in the To: or CC: fields. 596 messages in six months. I still get the second copy. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
> > Please explain how this is a problem. As Steven said, there is NO > > > > useful difference. I don't *care* whether it's a package, a module, > > or > > > > whatever. Module with class with static member? Fine. Package with > > > > module with class? Also fine. Imported special object that uses > > dunder > > > > methods to simulate either of the above? What's it matter to me, as > > > > long as I get my final result! > > > > > > > > Syntactic salt is seldom helpful. > > > > > > > > ChrisA > This is somewhat like the following problem. > > Do we have to argue with people about the tastes > of dishes in different restaurants ? > > Of course, I do because I love to enjoy fine dishes. Is there any way to report a bug to that bot ? I don't know how it end up thinking we where talking about dishes. I hope it won't count this reply as a successful bot post. JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
i can't understand decorator
>>> def deco(func):
... def kdeco():
... print("before myfunc() called.")
... func()
... print(" after myfunc() called.")
... return kdeco
...
>>> @deco
... def myfunc():
... print(" myfunc() called.")
...
>>> myfunc()
before myfunc() called.
myfunc() called.
after myfunc() called.
>>> deco(myfunc)()
before myfunc() called.
before myfunc() called.
myfunc() called.
after myfunc() called.
after myfunc() called.
1.
why there are two lines :before myfunc() called.and tow lines :after
myfunc() called. in the output?
2.why the result is not
before myfunc() called.
myfunc() called.
after myfunc() called.
before myfunc() called.
myfunc() called.
after myfunc() called.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compiling native extensions with Visual Studio 2012?
Am 12.01.2013 17:06, schrieb Alec Taylor: > Would be awesome to get these built into stdlib. > > Compiling my own versions mostly for virtualenv purposes; though > sometimes I can't find the binary on: > http://www.lfd.uci.edu/~gohlke/pythonlibs/ Let's see. I've 10 months to work on the PEP + implementation until the feature freeze of Python 3.4. It's feasible. Yeah, Christoph Gohlke's work is a time saver! Some people provide official Windows binaries for their Python packages. I'm in the lucky position to own a free MSDN subscription from Microsoft for my work on Python's Core. -- http://mail.python.org/mailman/listinfo/python-list
Re: i can't understand decorator
On 15 January 2013 14:20, contro opinion wrote:
def deco(func):
> ... def kdeco():
> ... print("before myfunc() called.")
> ... func()
> ... print(" after myfunc() called.")
> ... return kdeco
> ...
@deco
> ... def myfunc():
> ... print(" myfunc() called.")
> ...
myfunc()
> before myfunc() called.
> myfunc() called.
> after myfunc() called.
deco(myfunc)()
> before myfunc() called.
> before myfunc() called.
> myfunc() called.
> after myfunc() called.
> after myfunc() called.
> 1.
> why there are two lines :before myfunc() called.and tow lines :after
> myfunc() called. in the output?
You have wrapped the function twice with the decorator. Try changing the line
print("before func() called")
to
print("about to call", func,__name__)
and you'll see that the function it is about to call is not the same
in both cases.
> 2.why the result is not
> before myfunc() called.
> myfunc() called.
> after myfunc() called.
> before myfunc() called.
> myfunc() called.
> after myfunc() called.
You would get this output if you just called myfunc() twice. I don't
know why you expect wrapping the function twice to have this effect.
Oscar
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
On 15 January 2013 07:09, llanitedave wrote:
> So I put the following test code in my initialization method:
>
> # open database file
> self.geologger_db = sqlite3.connect('geologger.mgc')
> self.db_cursor = self.geologger_db.cursor()
> self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys =
> ON")
> self.foreign_key_status = self.foreign_key_status.fetchone()
>
> print self.foreign_key_status
>
> I ran this several times while I was arranging the downstream queries, and
> each time it returned '(1,)', which means foreign keys is enabled.
>
> But I was using a variable named 'cmd1' as a placeholder until I changed the
> name to
> the more descriptive 'self.foreign_key_status'. Since I made the name
> change, however,
> the code only returns 'None'. Reverting to the previous variable name has no
> effect.
Hmm - your code doesn't quite match up with the docs at
http://docs.python.org/2/library/sqlite3.html. That seems to suggest
that you should call fetchone() on the cursor, not on the result of
execute().
Does the following work?
# open database file
self.geologger_db = sqlite3.connect('geologger.mgc')
self.db_cursor = self.geologger_db.cursor()
self.db_cursor.execute("PRAGMA foreign_keys = ON")
print self.db_cursor.fetchone()
--
Robert K. Day
robert@merton.oxon.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
On Tuesday, January 15, 2013 6:36:51 AM UTC-8, Rob Day wrote:
> On 15 January 2013 07:09, llanitedave wrote:
>
>
>
> > So I put the following test code in my initialization method:
>
> >
>
> > # open database file
>
> > self.geologger_db = sqlite3.connect('geologger.mgc')
>
> > self.db_cursor = self.geologger_db.cursor()
>
> > self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys =
> > ON")
>
> > self.foreign_key_status = self.foreign_key_status.fetchone()
>
> >
>
> > print self.foreign_key_status
>
> >
>
> > I ran this several times while I was arranging the downstream queries, and
> > each time it returned '(1,)', which means foreign keys is enabled.
>
> >
>
> > But I was using a variable named 'cmd1' as a placeholder until I changed
> > the name to
>
> > the more descriptive 'self.foreign_key_status'. Since I made the name
> > change, however,
>
> > the code only returns 'None'. Reverting to the previous variable name has
> > no effect.
>
>
>
> Hmm - your code doesn't quite match up with the docs at
>
> http://docs.python.org/2/library/sqlite3.html. That seems to suggest
>
> that you should call fetchone() on the cursor, not on the result of
>
> execute().
>
>
>
> Does the following work?
>
>
>
> # open database file
>
> self.geologger_db = sqlite3.connect('geologger.mgc')
>
> self.db_cursor = self.geologger_db.cursor()
>
> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>
> print self.db_cursor.fetchone()
>
>
>
>
>
> --
>
> Robert K. Day
>
> robert@merton.oxon.org
Thanks for the suggestion, Rob, but that didn't make any difference. I've
never had an issue with putting the execute object into a variable and calling
"fetch" on that variable.
I can accept reality if it turns out that foreign keys simply isn't enabled on
the Python distribution of sqlite, although I don't know why that should be the
case. I'm just curious as to why it worked at first and then stopped working.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
Steven D'Aprano pearwood.info> writes: > > A programmer had a problem, and thought Now he has "I know, I'll solve > two it with threads!" problems. Host: Last week the Royal Festival Hall saw the first performance of a new logfile by one of the world's leading modern programmers, Steven "Two threads" D'Aprano. Mr D'Aprano. D'Aprano: Hello. Host: May I just sidetrack for one moment. This -- what shall I call it -- nickname of yours... D'Aprano: Ah yes. Host: "Two threads". How did you come by it? D'Aprano: Well, I don't use it myself, but some of my friends call me "Two Threads". Host: And do you in fact have two threads? D'Aprano: No, I've only got one. I've had one for some time, but a few years ago I said I was thinking of spawning another, and since then some people have called me "Two Threads". Host: In spite of the fact that you only have one. D'Aprano: Yes. Host: And are you still intending to spawn this second thread? D'Aprano: (impatient) No! Host: ...To bring you in line with your epithet? D'Aprano: No. Host: I see, I see. Well to return to your program. D'Aprano: Ah yes. Host: Did you write this logfile in the thread? D'Aprano: (surprised) No! Host: Have you written any of your recent files in this thread of yours? D'Aprano: No, no, not at all. It's just an ordinary daemon thread. Host: I see, I see. And you're thinking of spawning this second thread to write in! D'Aprano: No, no. Look. This thread business -- it doesn't really matter. The threads aren't important. A few friends call me Two Threads and that's all there is to it. I wish you'd ask me about the logfile. Everybody talks about the threads. They've got it out of proportion -- I'm a programmer. I'm going to get rid of the thread. I'm fed up with it! Host: Then you'll be Steven "No Threads" D'Aprano, eh? -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 15/01/2013 16:48, Antoine Pitrou wrote: > Steven D'Aprano pearwood.info> writes: >> >> A programmer had a problem, and thought Now he has "I know, I'll solve >> two it with threads!" problems. > > > Host: Last week the Royal Festival Hall saw the first performance of a new > logfile by one of the world's leading modern programmers, Steven > "Two threads" D'Aprano. Mr D'Aprano. [... snip ...] Brilliant, just brilliant. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
On 15 January 2013 15:51, llanitedave wrote:
> Thanks for the suggestion, Rob, but that didn't make any difference. I've
> never had an issue with putting the execute object into a variable and
> calling "fetch" on that variable.
>
> I can accept reality if it turns out that foreign keys simply isn't enabled
> on the Python distribution of sqlite, although I don't know why that should
> be the case. I'm just curious as to why it worked at first and then stopped
> working.
Well - you might be able to accept that, but I'm not sure I can! If it
was working before, it must be compiled in, and so it must be possible
to make it work again.
http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
"PRAGMA foreign_keys = ON" never returns anything, and it's only
"PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
With that in mind, does the following code work?
# open database file
self.geologger_db = sqlite3.connect('geologger.mgc')
self.db_cursor = self.geologger_db.cursor()
self.db_cursor.execute("PRAGMA foreign_keys = ON")
self.db_cursor.execute("PRAGMA foreign_keys")
print self.db_cursor.fetchone()
--
http://mail.python.org/mailman/listinfo/python-list
atexit handler in IDLE?
On Tue, Jan 15, 2013 at 6:25 AM, Steve Spicklemire wrote: > I'm trying to get this program, which works on the command line, to run > correctly in the IDLE environment: > > import atexit > > print "This is my program" > > def exit_func(): > print "OK.. that's all folks!" > > atexit.register(exit_func) > > print "Program is ending..." You know, I think I looked at this problem once. It was rather strange, but I think you need to create a tempfile, so that Python knows that IDLE is running. There's an item for this in IDLE's TODO list. I was going to implement it, which is fairly east, but never got to it. mark -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
On Monday, January 14, 2013 11:09:28 PM llanitedave wrote:
> I'm trying to get an application working in Python 2.7 and wx.Python which
> contains an embedded sqlite3 file. There are a few tables with foreign
> keys defined. In looking at the sqlite3 documentation, it says
>
> "Assuming the library is compiled with foreign key constraints enabled, it
> must still be enabled by the application at runtime, using the PRAGMA
> foreign_keys command." It goes on to say that foreign keys must be enabled
> separately for each connection, which is fine as my app has only one.
>
> So I put the following test code in my initialization method:
>
> # open database file
> self.geologger_db = sqlite3.connect('geologger.mgc')
> self.db_cursor = self.geologger_db.cursor()
> self.foreign_key_status = self.db_cursor.execute("PRAGMA foreign_keys =
> ON") self.foreign_key_status = self.foreign_key_status.fetchone()
>
> print self.foreign_key_status
>
> I ran this several times while I was arranging the downstream queries, and
> each time it returned '(1,)', which means foreign keys is enabled.
>
> But I was using a variable named 'cmd1' as a placeholder until I changed the
> name to the more descriptive 'self.foreign_key_status'. Since I made the
> name change, however, the code only returns 'None'. Reverting to the
> previous variable name has no effect.
>
> Yes, I'm closing the connection with self.db_cursor.close() at the end of
> each run.
>
> According to the sqlite3 website, getting no return value, not even a '0',
> means that "the version of SQLite you are using does not support foreign
> keys (either because it is older than 3.6.19 or because it was compiled
> with SQLITE_OMIT_FOREIGN_KEY or SQLITE_OMIT_TRIGGER defined)."
>
> How can that be a compilation issue when it worked previously? Does this
> somehow relate to it being a Python plugin instance?
>
> I'm very confused.
I haven't run this myself but after
self.foreign_key_status.fetchone()
try :
self.geologger_db.commit()
then close the db
jimonlinux
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question on for loop
On Friday, January 4, 2013 11:18:24 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 03 Jan 2013 12:04:03 -0800, subhabangalore wrote: > > > > > Dear Group, > > > If I take a list like the following: > > > > > > fruits = ['banana', 'apple', 'mango'] > > > for fruit in fruits: > > >print 'Current fruit :', fruit > > > > > > Now, > > > if I want variables like var1,var2,var3 be assigned to them, we may > > > take, var1=banana, > > > var2=apple, > > > var3=mango > > > > > > but can we do something to assign the variables dynamically > > > > Easy as falling off a log. You can't write "var1", "var2" etc. but you > > can write it as "var[0]", "var[1]" etc. > > > > var = ['banana', 'apple', 'mango'] > > print var[0] # prints 'banana' > > print var[1] # prints 'apple' > > print var[2] # prints 'mango' > > > > > > > > Of course "var" is not a very good variable name. "fruit" or "fruits" > > would be better. > > > > > > > > > > -- > > Steven Actually in many cases it is easy if you get the variable of list value, I was trying something like, def func1(n): list1=["x1","x2","x3","x4","x5","x6","x7","x8","x9","x10"] blnk=[] for i in range(len(list1)): num1="var"+str(i)+"="+list1[i] blnk.append(num1) print blnk Regards, Subhabrata. -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit handler in IDLE?
On Jan 15, 2013, at 10:22 AM, Mark Janssen wrote: > On Tue, Jan 15, 2013 at 6:25 AM, Steve Spicklemire wrote: >> I'm trying to get this program, which works on the command line, to run >> correctly in the IDLE environment: >> >> import atexit >> >> print "This is my program" >> >> def exit_func(): >>print "OK.. that's all folks!" >> >> atexit.register(exit_func) >> >> print "Program is ending..." > > You know, I think I looked at this problem once. It was rather > strange, but I think you need to create a tempfile, so that Python > knows that IDLE is running. There's an item for this in IDLE's TODO > list. I was going to implement it, which is fairly east, but never > got to it. > > mark > -- > http://mail.python.org/mailman/listinfo/python-list I don't really know how to use this. Is there a detailed todo list somewhere? I did find this tantalizing bit in news.txt, but when I tried to test it (by setting to option to false), I couldn't get it to work. Is there a set of tests for idle that might exercise this option? -- What's New in IDLEfork 0.9b1? = *Release date: 02-Jun-2003* - Added the delete-exitfunc option to config-main.def. (This option is not included in the Options dialog.) Setting this to True (the default) will cause IDLE to not run sys.exitfunc/atexit when the subprocess exits. - Thanks! -steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On Wed, Jan 16, 2013 at 3:48 AM, Antoine Pitrou wrote: > D'Aprano: No, no. Look. This thread business -- it doesn't really matter. > The threads aren't important. A few friends call me Two Threads and that's > all there is to it. I wish you'd ask me about the logfile. Everybody talks > about the threads. They've got it out of proportion -- I'm a programmer. > I'm going to get rid of the thread. I'm fed up with it! > > Host: Then you'll be Steven "No Threads" D'Aprano, eh? Close, Host. He'd be Steven "No Marbles" D'Aprano. *whistles innocently* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
> On 15 January 2013 15:51, llanitedave wrote:
>
> > Thanks for the suggestion, Rob, but that didn't make any difference. I've
> > never had an issue with putting the execute object into a variable and
> > calling "fetch" on that variable.
>
> >
>
> > I can accept reality if it turns out that foreign keys simply isn't enabled
> > on the Python distribution of sqlite, although I don't know why that should
> > be the case. I'm just curious as to why it worked at first and then
> > stopped working.
>
>
>
> Well - you might be able to accept that, but I'm not sure I can! If it
>
> was working before, it must be compiled in, and so it must be possible
>
> to make it work again.
>
>
>
> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
>
> "PRAGMA foreign_keys = ON" never returns anything, and it's only
>
> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
>
> With that in mind, does the following code work?
>
>
>
> # open database file
>
>
>
> self.geologger_db = sqlite3.connect('geologger.mgc')
>
> self.db_cursor = self.geologger_db.cursor()
>
> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>
> self.db_cursor.execute("PRAGMA foreign_keys")
>
> print self.db_cursor.fetchone()
"http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that "PRAGMA
foreign_keys = ON" never returns anything, and it's only "PRAGMA foreign_keys"
which returns 0, 1 or None (when unsupported)."
That was it, exactly, Rob. I don't know where I got the idea that I was
getting a '1' from the 'ON' command, although I was sure that I'd seen it.
But once I just called "foreign_key" it returned just fine.
Ummm... Obviously I was up fiddling around too late. Yeah, that's it.
Thanks! It's solved now.
--
http://mail.python.org/mailman/listinfo/python-list
Re: i can't understand decorator
Am 15.01.2013 15:20 schrieb contro opinion:
>>> def deco(func):
... def kdeco():
... print("before myfunc() called.")
... func()
... print(" after myfunc() called.")
... return kdeco
...
>>> @deco
... def myfunc():
... print(" myfunc() called.")
...
>>> myfunc()
before myfunc() called.
myfunc() called.
after myfunc() called.
>>> deco(myfunc)()
before myfunc() called.
before myfunc() called.
myfunc() called.
after myfunc() called.
after myfunc() called.
Wrapping works this way:
The function is defined, and the wrapper replaces the function with a
different one which (in this case) calls the original one.
Try print(myfunc) here and you see that myfunc is only a name for
another function called kdeco. It is the one returned by the decorator.
1.
why there are two lines :before myfunc() called.and tow lines :after
myfunc() called. in the output?
This is because the "before" line is printed, then the modified "myfunc"
is called, which in turn prints another "before" line and then calls the
"really original" function. After it returns, the "after" line is called
by the inner placement function (the one which sticks at the myfunc
identifier). This function returns and the function instance which
called the first "before" line is printed then.
2.why the result is not
before myfunc() called.
myfunc() called.
after myfunc() called.
before myfunc() called.
myfunc() called.
after myfunc() called.
Because the function calls are wrapped and not repeated.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
Glad I could help!
Using a local source control system like git, bzr or hg is really
useful in situations like these - it's far, far easier to debug issues
of the form "I made changes and now it's broken" when you can do `git
diff yesterday's-version today's-version` and see exactly what the
changes were.
On 15 January 2013 20:29, llanitedave wrote:
> On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
>> On 15 January 2013 15:51, llanitedave wrote:
>>
>> > Thanks for the suggestion, Rob, but that didn't make any difference. I've
>> > never had an issue with putting the execute object into a variable and
>> > calling "fetch" on that variable.
>>
>> >
>>
>> > I can accept reality if it turns out that foreign keys simply isn't
>> > enabled on the Python distribution of sqlite, although I don't know why
>> > that should be the case. I'm just curious as to why it worked at first
>> > and then stopped working.
>>
>>
>>
>> Well - you might be able to accept that, but I'm not sure I can! If it
>>
>> was working before, it must be compiled in, and so it must be possible
>>
>> to make it work again.
>>
>>
>>
>> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
>>
>> "PRAGMA foreign_keys = ON" never returns anything, and it's only
>>
>> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
>>
>> With that in mind, does the following code work?
>>
>>
>>
>> # open database file
>>
>>
>>
>> self.geologger_db = sqlite3.connect('geologger.mgc')
>>
>> self.db_cursor = self.geologger_db.cursor()
>>
>> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>>
>> self.db_cursor.execute("PRAGMA foreign_keys")
>>
>> print self.db_cursor.fetchone()
>
> "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA
> foreign_keys" which returns 0, 1 or None (when unsupported)."
>
> That was it, exactly, Rob. I don't know where I got the idea that I was
> getting a '1' from the 'ON' command, although I was sure that I'd seen it.
> But once I just called "foreign_key" it returned just fine.
>
> Ummm... Obviously I was up fiddling around too late. Yeah, that's it.
>
>
> Thanks! It's solved now.
> --
> http://mail.python.org/mailman/listinfo/python-list
--
Robert K. Day
robert@merton.oxon.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3 puzzle
Yabut I'm talking about changes I'd made 30 seconds before to code I'd written
5 minutes before. My short-term memory is nothing to write home about, even if
I could remember my mailing address!
On Tuesday, January 15, 2013 2:27:28 PM UTC-8, Rob Day wrote:
> Glad I could help!
>
>
>
>
>
> Using a local source control system like git, bzr or hg is really
>
> useful in situations like these - it's far, far easier to debug issues
>
> of the form "I made changes and now it's broken" when you can do `git
>
> diff yesterday's-version today's-version` and see exactly what the
>
> changes were.
>
>
>
>
>
> On 15 January 2013 20:29, llanitedave wrote:
>
> > On Tuesday, January 15, 2013 9:13:13 AM UTC-8, Rob Day wrote:
>
> >> On 15 January 2013 15:51, llanitedave wrote:
>
> >>
>
> >> > Thanks for the suggestion, Rob, but that didn't make any difference.
> >> > I've never had an issue with putting the execute object into a variable
> >> > and calling "fetch" on that variable.
>
> >>
>
> >> >
>
> >>
>
> >> > I can accept reality if it turns out that foreign keys simply isn't
> >> > enabled on the Python distribution of sqlite, although I don't know why
> >> > that should be the case. I'm just curious as to why it worked at first
> >> > and then stopped working.
>
> >>
>
> >>
>
> >>
>
> >> Well - you might be able to accept that, but I'm not sure I can! If it
>
> >>
>
> >> was working before, it must be compiled in, and so it must be possible
>
> >>
>
> >> to make it work again.
>
> >>
>
> >>
>
> >>
>
> >> http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
>
> >>
>
> >> "PRAGMA foreign_keys = ON" never returns anything, and it's only
>
> >>
>
> >> "PRAGMA foreign_keys" which returns 0, 1 or None (when unsupported).
>
> >>
>
> >> With that in mind, does the following code work?
>
> >>
>
> >>
>
> >>
>
> >> # open database file
>
> >>
>
> >>
>
> >>
>
> >> self.geologger_db = sqlite3.connect('geologger.mgc')
>
> >>
>
> >> self.db_cursor = self.geologger_db.cursor()
>
> >>
>
> >> self.db_cursor.execute("PRAGMA foreign_keys = ON")
>
> >>
>
> >> self.db_cursor.execute("PRAGMA foreign_keys")
>
> >>
>
> >> print self.db_cursor.fetchone()
>
> >
>
> > "http://www.sqlite.org/foreignkeys.html#fk_enable seems to suggest that
> > "PRAGMA foreign_keys = ON" never returns anything, and it's only "PRAGMA
> > foreign_keys" which returns 0, 1 or None (when unsupported)."
>
> >
>
> > That was it, exactly, Rob. I don't know where I got the idea that I was
> > getting a '1' from the 'ON' command, although I was sure that I'd seen it.
> > But once I just called "foreign_key" it returned just fine.
>
> >
>
> > Ummm... Obviously I was up fiddling around too late. Yeah, that's it.
>
> >
>
> >
>
> > Thanks! It's solved now.
>
> > --
>
> > http://mail.python.org/mailman/listinfo/python-list
>
>
>
>
>
>
>
> --
>
> Robert K. Day
>
> robert@merton.oxon.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 15/01/13 16:48, Antoine Pitrou wrote: Steven D'Aprano pearwood.info> writes: A programmer had a problem, and thought Now he has "I know, I'll solve two it with threads!" problems. Host: Last week the Royal Festival Hall saw the first performance of a new logfile by one of the world's leading modern programmers, Steven "Two threads" D'Aprano. Mr D'Aprano. D'Aprano: Hello. Host: May I just sidetrack for one moment. This -- what shall I call it -- nickname of yours... D'Aprano: Ah yes. Host: "Two threads". How did you come by it? [...] Host: I see, I see. And you're thinking of spawning this second thread to write in! D'Aprano: No, no. Look. This thread business -- it doesn't really matter. The threads aren't important. A few friends call me Two Threads and that's all there is to it. I wish you'd ask me about the logfile. Everybody talks about the threads. They've got it out of proportion -- I'm a programmer. I'm going to get rid of the thread. I'm fed up with it! Host: Then you'll be Steven "No Threads" D'Aprano, eh? + Applause -- http://mail.python.org/mailman/listinfo/python-list
Is there a more elegant way to handle determing fail status?
Ok, so I have a diagnostic tool, written by someone else. That tool
runs a series of small tests defined by the user and can simplified
summary output that can be one of the following:
FAILED_CRITICAL
FAILED_HIGH
FAILED_MEDIUM
FAILED_LOW
PASSED
I also have a wrapper script I wrote to run these tests, summarize the
results of all tests aggregated and then fail based on a particular
fail level.
The idea is that if I run 3 tests with the diagnostic tool and it
tells me the following:
testA: PASSED
testB: FAILED_MEDIUM
testC: PASSED
AND I told the wrapper to only fail on HIGH or above, the wrapper will
tell me that I had a medium failure, but the wrapper will still exit
with a 0 (success)
if I get the same results as above, but tell the wrapper to fail on
LOW, then it will tell me I had that medium failure, but the wrapper
will exit with a 1 (failure).
The problem is that my exit determination looks like this:
if fail_priority == fail_levels['FAILED_CRITICAL']:
if critical_fails:
return 1
if fail_priority == fail_levels['FAILED_HIGH']:
if critical_fails or high_fails:
return 1
if fail_priority == fail_levels['FAILED_MEDIUM']:
if critical_fails or high_fails or medium_fails:
return 1
if fail_priority == fail_levels['FAILED_LOW']:
if critical_fails or high_fails or medium_fails or low_fails:
return 1
return 0
So, to explain the above... the fail level can be set by the user when
running the wrapper using -f (or it defaults to 'high')
the wrapper assigns a number to each level using this:
# Set correct fail level
args.fail_level = 'FAILED_%s' % args.fail_level.upper()
# Get our failure priority and create the priority values
fail_levels = {'FAILED_CRITICAL':4,
'FAILED_HIGH':3,
'FAILED_MEDIUM':2,
'FAILED_LOW':1}
fail_priority = fail_levels[args.fail_level]
the variables critical_fails, high_fails, medium_fails, low_fails are
all counters that are etiher None, or the number of tests that were
failed.
So using this output from the diagnostic tool:
testA: PASSED
testB: FAILED_HIGH
testC: PASSED
testD: FAILED_MEDIUM
testE: PASSED
critical_fails would be None
high_fails would be 1
medium_fails would be 1
low_fails would be None.
The exit code determination above works, but it just feels inelegant.
It feels like there's a better way of implementing that, but I can't
come up with one that still honors the fail level properly (e.g. other
solutions will fail on medium, but won't fail properly on medium OR
higher).
I can provide the full script if necessary, if the above isn't enough
to point me in a direction that has a better way of doing this...
Thanks for looking,
Jeff
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to handle determing fail status?
On Tuesday, January 15, 2013 3:24:44 PM UTC-8, J wrote:
> Ok, so I have a diagnostic tool, written by someone else. That tool
>
> runs a series of small tests defined by the user and can simplified
>
> summary output that can be one of the following:
>
>
>
> FAILED_CRITICAL
>
> FAILED_HIGH
>
> FAILED_MEDIUM
>
> FAILED_LOW
>
> PASSED
>
>
>
> I also have a wrapper script I wrote to run these tests, summarize the
>
> results of all tests aggregated and then fail based on a particular
>
> fail level.
>
>
>
> The idea is that if I run 3 tests with the diagnostic tool and it
>
> tells me the following:
>
>
>
> testA: PASSED
>
> testB: FAILED_MEDIUM
>
> testC: PASSED
>
>
>
> AND I told the wrapper to only fail on HIGH or above, the wrapper will
>
> tell me that I had a medium failure, but the wrapper will still exit
>
> with a 0 (success)
>
>
>
> if I get the same results as above, but tell the wrapper to fail on
>
> LOW, then it will tell me I had that medium failure, but the wrapper
>
> will exit with a 1 (failure).
>
>
>
> The problem is that my exit determination looks like this:
>
>
>
> if fail_priority == fail_levels['FAILED_CRITICAL']:
>
> if critical_fails:
>
> return 1
>
> if fail_priority == fail_levels['FAILED_HIGH']:
>
> if critical_fails or high_fails:
>
> return 1
>
> if fail_priority == fail_levels['FAILED_MEDIUM']:
>
> if critical_fails or high_fails or medium_fails:
>
> return 1
>
> if fail_priority == fail_levels['FAILED_LOW']:
>
> if critical_fails or high_fails or medium_fails or low_fails:
>
> return 1
>
>
>
> return 0
>
>
>
> So, to explain the above... the fail level can be set by the user when
>
> running the wrapper using -f (or it defaults to 'high')
>
> the wrapper assigns a number to each level using this:
>
>
>
> # Set correct fail level
>
> args.fail_level = 'FAILED_%s' % args.fail_level.upper()
>
>
>
> # Get our failure priority and create the priority values
>
> fail_levels = {'FAILED_CRITICAL':4,
>
>'FAILED_HIGH':3,
>
>'FAILED_MEDIUM':2,
>
>'FAILED_LOW':1}
>
> fail_priority = fail_levels[args.fail_level]
>
>
>
> the variables critical_fails, high_fails, medium_fails, low_fails are
>
> all counters that are etiher None, or the number of tests that were
>
> failed.
>
>
>
> So using this output from the diagnostic tool:
>
>
>
> testA: PASSED
>
> testB: FAILED_HIGH
>
> testC: PASSED
>
> testD: FAILED_MEDIUM
>
> testE: PASSED
>
>
>
> critical_fails would be None
>
> high_fails would be 1
>
> medium_fails would be 1
>
> low_fails would be None.
>
>
>
> The exit code determination above works, but it just feels inelegant.
>
> It feels like there's a better way of implementing that, but I can't
>
> come up with one that still honors the fail level properly (e.g. other
>
> solutions will fail on medium, but won't fail properly on medium OR
>
> higher).
>
>
>
> I can provide the full script if necessary, if the above isn't enough
>
> to point me in a direction that has a better way of doing this...
>
>
>
> Thanks for looking,
>
>
>
> Jeff
My back of the envelope coding would do it this way. Use an array of
fail_counters, with PASSED as the first element all the way up to
FAILED_CRITICAL as the last element. Then use a simple loop starting from index
fail_priority to the end of the list looking for errors. Like this:
# Array of fail counters
fail_counters = [
0, # PASSED
0, # LOW
0, # MEDIUM
0, # HIGH
0 # CRITICAL
]
... run tests, accumulate error counts in fail_counters
for i in range(fail_priority, len(fail_counters)):
if fail_counters[i]:
return 1
return 0
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to handle determing fail status?
On 15 January 2013 23:24, J wrote: > Ok, so I have a diagnostic tool, written by someone else. That tool > runs a series of small tests defined by the user and can simplified > summary output that can be one of the following: > > FAILED_CRITICAL > FAILED_HIGH > FAILED_MEDIUM > FAILED_LOW > PASSED > > I also have a wrapper script I wrote to run these tests, summarize the > results of all tests aggregated and then fail based on a particular > fail level. > > The idea is that if I run 3 tests with the diagnostic tool and it > tells me the following: > > testA: PASSED > testB: FAILED_MEDIUM > testC: PASSED > > AND I told the wrapper to only fail on HIGH or above, the wrapper will > tell me that I had a medium failure, but the wrapper will still exit > with a 0 (success) > > if I get the same results as above, but tell the wrapper to fail on > LOW, then it will tell me I had that medium failure, but the wrapper > will exit with a 1 (failure). > > The problem is that my exit determination looks like this: > > if fail_priority == fail_levels['FAILED_CRITICAL']: > if critical_fails: > return 1 > if fail_priority == fail_levels['FAILED_HIGH']: > if critical_fails or high_fails: > return 1 > if fail_priority == fail_levels['FAILED_MEDIUM']: > if critical_fails or high_fails or medium_fails: > return 1 > if fail_priority == fail_levels['FAILED_LOW']: > if critical_fails or high_fails or medium_fails or low_fails: > return 1 > > return 0 > [SNIP] > > The exit code determination above works, but it just feels inelegant. > It feels like there's a better way of implementing that, but I can't > come up with one that still honors the fail level properly (e.g. other > solutions will fail on medium, but won't fail properly on medium OR > higher). How about the following? FAILED_CRITICAL = 4 FAILED_HIGH = 3 FAILED_MEDIUM = 2 FAILED_LOW = 1 PASSED = 0 if fail_level: print fail_message if fail_level > fail_priority: return 1 Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to handle determing fail status?
On Tue, Jan 15, 2013 at 4:24 PM, J wrote: > The exit code determination above works, but it just feels inelegant. > It feels like there's a better way of implementing that, but I can't > come up with one that still honors the fail level properly (e.g. other > solutions will fail on medium, but won't fail properly on medium OR > higher). First, instead of having separate variables 'critical_fails', 'high_fails', etc., put them in a collections.Counter 'fails' keyed by fail level. Second, make sure those fail level keys are orderable by severity. Then your check is just: if fail_priority <= max(fails): return 1 return 0 -- http://mail.python.org/mailman/listinfo/python-list
Please help test Pillow for Python 3
Hi, Python 3 support for PIL has been merged into the Pillow (PIL fork) master branch. If this interests you, please help test! - git://github.com/python-imaging/Pillow.git More on the subject: - http://blog.aclark.net/2013/01/10/pillow-python-3/ -- Alex Clark · https://www.gittip.com/aclark4life/ -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit handler in IDLE?
On 1/15/2013 7:25 AM, Steve Spicklemire wrote: import atexit print "This is my program" def exit_func(): print "OK.. that's all folks!" atexit.register(exit_func) print "Program is ending..." If you put () around the strings, it will run the same *and* work in 3.x. When I run this on the command line I see: This is my program Program is ending... OK.. that's all folks! When I run this in IDLE I see: This is my program Program is ending... But the atexit handler is never called. ;-( I tried in 3.3 idle and get the same. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to handle determing fail status?
On Tue, 15 Jan 2013 18:24:44 -0500, J wrote: > The problem is that my exit determination looks like this: > > if fail_priority == fail_levels['FAILED_CRITICAL']: > if critical_fails: > return 1 > if fail_priority == fail_levels['FAILED_HIGH']: > if critical_fails or high_fails: > return 1 > if fail_priority == fail_levels['FAILED_MEDIUM']: > if critical_fails or high_fails or medium_fails: > return 1 > if fail_priority == fail_levels['FAILED_LOW']: > if critical_fails or high_fails or medium_fails or low_fails: > return 1 > return 0 Here's a general solution that doesn't require the failure levels to be numbers, or listed in order, or to support any operation except equality testing. Start with an ordered list of failure severity levels, and an equivalent ordered list of failure counts. Find the offset of the requested failure level in the FAILURES list. Then inspect the failure counts, up to and including that offset, ignoring any failure outside of that range: failures = [FAILED_CRITICAL, FAILED_HIGH, FAILED_MEDIUM, FAILED_LOW] counts = [critical_fails, high_fails, medium_fails, low_fails] i = failures.index(fail_priority) if any(counts[:i+1]): print "Failed" else: print "No failures that we care about" The actual values for FAILED_CRITICAL etc. can be arbitrary values: integers *in any order*, strings, complicated records, anything so long as they support equality and are distinct. fail_priority must be set to one of those values. > the variables critical_fails, high_fails, medium_fails, low_fails are > all counters that are etiher None, or the number of tests that were > failed. Why set them to None when no tests failed? If no tests failed, why not just use 0? That is, instead of the counters being "the number of failures, or None", they could be "the number of failures". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: cymbalic reference?
On Wed, Jan 16, 2013 at 3:56 PM, rh wrote: > While I'm at it what magic could I use to print "the-class-I-am-in good" > instead of hard-coding "Abc good"? I tried __class_ and self.__class__ Almost there! Try self.__class__.__name__ to get the name as a string. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: cymbalic reference?
On Tue, Jan 15, 2013 at 8:56 PM, rh wrote:
> I have this working and I am curious to know how others do same.
>
> class Abc(object):
> def __init__(self):
> pass
> def good(self):
> print "Abc good"
> def better(self):
> print "Abc better"
>
> urls = {'Abc':'http://example.com'}
> strings = ['good', 'better']
>
> for s in urls:
> o = eval("%s()" % s)
> for string in strings:
> eval("o.%s()" % string)
>
>
> Yes, 'spose symbolic references is what these are
>
> While I'm at it what magic could I use to print "the-class-I-am-in good"
> instead of hard-coding "Abc good"? I tried __class_ and self.__class__
>
> --
Rather than using eval, you can grab the class out of globals(), and
then use getattr to get the methods.
>>> for s in urls :
... o = globals()[s]()
... for method in strings :
... getattr(o, method)()
...
Abc good
Abc better
And for getting the class name, the class has a __name__ attribute. So
you could use self.__class__.__name__.
--
http://mail.python.org/mailman/listinfo/python-list
Re: cymbalic reference?
On 1/15/2013 11:56 PM, rh wrote:
I have this working and I am curious to know how others do same.
class Abc(object):
def __init__(self):
pass
def good(self):
print "Abc good"
def better(self):
print "Abc better"
urls = {'Abc':'http://example.com'}
strings = ['good', 'better']
for s in urls:
o = eval("%s()" % s)
for string in strings:
eval("o.%s()" % string)
for s in urls:
o = globals()[s]()
for string in strings:
getattr(o,string)()
has same output. eval is seldom needed.
Of course, if you more sensibly use the class or an instance as key
urls = {Abc: 'http://example.com'}
urls = {Abc(): 'http://example.com'}
instead of the name, then o = s() or o = s directly.
While I'm at it what magic could I use to print "the-class-I-am-in good"
instead of hard-coding "Abc good"? I tried __class_ and self.__class__
self.__class__.__name__ or type(self).__name__)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
PyWart: Exception error paths far too verbose
Python needs to trim the path to the source file from which the exception was caught and only display the relative path starting from your personal library folder. For example. Say your personal library exists in: C:\users\user\documents\python\lib ...then there is no need to post THAT portion of the path EVERY STINKING TIME! For instance, let's say a script at: C:\users\user\documents\python\lib\sound\effects\echo.py ...throws an error. What will we see? Traceback (most recent call last): File "C:\users\user\documents\python\lib\sound\effects\echo.py", line N, in BLAH Why do i need to see "C:\users\user\documents\python\lib" EVERY time? Since all directories *BELOW* the directory that holds your personal Python library are /superfluous/ when posting exceptions to stderr, trimming this bloat can really help to make exception messages easier to read. Traceback (most recent call last): File "...\sound\effects\reverb.py", line XXX, in YYY -- http://mail.python.org/mailman/listinfo/python-list
