Re: Query windows event log with python
On 13/01/2013 05:55, [email protected] wrote: > On Saturday, January 12, 2013 8:34:01 PM UTC+11, Tim Golden wrote: >> On 12/01/2013 06:09, [email protected] wrote: >> >>> I am looking to write a short program to query the windows event >> >>> log. >> >>> >> >>> It needs to ask the user for input for The event type (Critical, >> >>> Error, and Information), and the user needs to be able to specify >>> a >> >>> date since when they want to view results. >> >>> >> >>> I found this piece of code to start from, >> >> >> >> [... snip ...] >> >> >> >> Well it looks like you have everything you need. Was there a >> specific >> >> question you wanted to ask? >> >> >> >> TJG > > yes, I would like to run it in Command prompt and ask the user at the > time what type and date of Event they would like to view. so i was > wondering where in the code I could put something like > "var=raw_input" Ok, so your query isn't so much with accessing the event log as with writing Python code at all. If you haven't already, could I suggest the Python tutorial here: http://docs.python.org/2/tutorial/ or, if that one doesn't suit, just search for "Python tutorial" to find something which fits your brain. Feel free to post back here with questions once you've got started. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/13/2013 11:16 PM, Steven D'Aprano wrote: > A programmer had a problem, and thought Now he has "I know, I'll solve > two it with threads!" problems. > > ++10 I've been thinking about threads lately, and have come to the tentative conclusion that they're a solution which has outlived its usefulness for 99% of the use cases. Much like the Windows 3.1 model of memory usage, where all memory was shared, and apps promised not to step too hard on each other. Or the "640k is more memory than any application will ever need" notion. When you multiprocess, everything is private except those things you work at sharing. When you multithread, everything is shared, and you promise not to intentionally do anything too nasty with the ability. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Making a logging handler that produces context.
I have some in house code for which I am considering replacing the
logging code
with something that uses the logging module.
The code is typically used as a cron job with everything higher than
info logged to
a file and everything higher than warning logged to stderr.
However there is one thing the in-house log code does, that seems
difficult to do
with the logging module, provide some context. The in-house handlers
give the
possibilty to specify the number of lines of context the hander can provide.
So the following code:
Logger(fn = "file.log", level = info)
Logger(fl = stderr, level = warning, context = 2)
log(INFO, "line 1")
log(INFO, "line 2")
log(INFO, "line 3")
log(INFO, "line 4")
log(WARNING, "line 5")
Will sent something like the following lines to stderr:
INFO: line 3
INFO: line 4
WARNING: line 5
I tried the code below, but that produced the same
as the ordinary StreamHandler.
class ContextStreamHandler (StreamHandler):
def __init__(self, stream=None, context = 5):
self.recqueue = deque([], context)
StreamHandler.__init__(self, stream)
#__init__
def handle(self, record):
print("CONTEXT HANDLER")
rv = self.filter(record)
if rv:
self.acquire()
try:
for rec in self.recqueue:
self.emit(rec)
self.recqueue.clear()
self.emit(record)
finally:
self.release
else:
self.recqueue.append(record)
return rv
#handle
#ContextStreamHandler
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On Jan 14, 2:16 pm, Steven D'Aprano wrote: > A programmer had a problem, and thought Now he has "I know, I'll solve > two it with threads!" problems. I laughed far far longer than I should have, cheers :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a logging handler that produces context.
Antoon Pardon wrote:
> I have some in house code for which I am considering replacing the
> logging code with something that uses the logging module.
> However there is one thing the in-house log code does, that seems
> difficult to do with the logging module, provide some context. The
> in-house handlers give the possibilty to specify the number of lines of
> context the hander can provide.
> So the following code:
> Logger(fl = stderr, level = warning, context = 2)
>
> log(INFO, "line 1")
> log(INFO, "line 2")
> log(INFO, "line 3")
> log(INFO, "line 4")
> log(WARNING, "line 5")
>
> Will sent something like the following lines to stderr:
>
> INFO: line 3
> INFO: line 4
> WARNING: line 5
>
> I tried the code below, but that produced the same
> as the ordinary StreamHandler.
>
> class ContextStreamHandler (StreamHandler):
>
> def __init__(self, stream=None, context = 5):
> self.recqueue = deque([], context)
> StreamHandler.__init__(self, stream)
> #__init__
>
> def handle(self, record):
> print("CONTEXT HANDLER")
> rv = self.filter(record)
> if rv:
> self.acquire()
> try:
> for rec in self.recqueue:
> self.emit(rec)
> self.recqueue.clear()
> self.emit(record)
> finally:
> self.release
> else:
> self.recqueue.append(record)
> return rv
> #handle
> #ContextStreamHandler
It turns out the logic of the above is correct. The problem is that the
handler has to see the INFO-level records while the filter() method has to
reject them. The following configuration seems to achieve that:
import logging
from collections import deque
class ContextStreamHandler(logging.StreamHandler):
def __init__(self, stream=None, context=5):
self.record_queue = deque([], context + 1)
logging.StreamHandler.__init__(self, stream)
def handle(self, record):
rv = self.filter(record)
self.record_queue.append(record)
if rv:
self.acquire()
try:
for record in self.record_queue:
self.emit(record)
self.record_queue.clear()
finally:
self.release()
return rv
class LevelFilter(logging.Filter):
def __init__(self, level, name=""):
logging.Filter.__init__(self, name)
self._filter_level = level
def filter(self, record):
return record.levelno >= self._filter_level
if __name__ == "__main__":
root = logging.getLogger()
root.setLevel(logging.INFO)
handler = ContextStreamHandler(context=2)
handler.addFilter(LevelFilter(logging.WARN))
root.addHandler(handler)
for i in range(20):
if i % 5:
root.info("message #%d" % i)
else:
root.warn("MESSAGE #%d" % i)
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to detect the character encoding in a web page ?
In article , Roy Smith wrote: >In article , > Alister wrote: > >> Indeed due to the poor quality of most websites it is not possible to be >> 100% accurate for all sites. >> >> personally I would start by checking the doc type & then the meta data as >> these should be quick & correct, I then use chardectect only if these >> fail to provide any result. > >I agree that checking the metadata is the right thing to do. But, I >wouldn't go so far as to assume it will always be correct. There's a >lot of crap out there with perfectly formed metadata which just happens >to be wrong. > >Although it pains me greatly to quote Ronald Reagan as a source of >wisdom, I have to admit he got it right with "Trust, but verify". It's Not surprisingly, as an actor, Reagan was as good as his script. This one he got from Stalin. >the only way to survive in the unicode world. Write defensive code. >Wrap try blocks around calls that might raise exceptions if the external >data is borked w/r/t what the metadata claims it should be. The way to go, of course. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with exam task for college
Hi, I only skimmed through the code, but I think your problem resides at the "while True" in your brandstofmeter update(). This function never stops.. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/13/13 22:16, Steven D'Aprano wrote: A programmer had a problem, and thought Now he has "I know, I'll solve two it with threads!" problems. A newbie programmer had a problem and thought "I'll solve it by posting on [email protected] and on Google Groups". And now we have the problem of two threads... Intentionally-misinterpreting'ly yours, -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
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 > > > > [email protected] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Making a logging handler that produces context.
Op 14-01-13 13:38, Peter Otten schreef: > It turns out the logic of the above is correct. The problem is that the > handler has to see the INFO-level records while the filter() method has to > reject them. The following configuration seems to achieve that: I see, I thought trowing away logrecords of too low a level was also done by the filter method. But if I now understand correctly logrecords of too low a level are thrown away earlier and don't even reach the handle method. Thanks for the insight. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On 01/14/13 01:56, Chris Angelico wrote:
On Mon, Jan 14, 2013 at 6:32 PM, Rick Johnson
wrote:
I really don't like using two words ("define object", or "def obj") and using one single keyword is ambiguous ("object"
or "obj"). So the obvious solution is to combine the abbreviated words into one compound keyword that will save keystrokes, save parsing,
and all-the-while maintain symmetry. That keyword is "defobj". Coupled with "defmeth" and "deffunc" we now have a
symmetrical definition syntax!
deffunc bar():
return
defobj Foo():
defmeth __init__(self, blah):
pass
Awesome! Now, just one more step to make Python into the World's Most
Awesome Language(tm): Replace those lengthy words with single symbols
found in the Unicode set; compress everything down and enforce perfect
Unicode handling.
APL will rise to linguistic domination! «maniacal laughter»
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On Mon, 14 Jan 2013 00:31:59 -0500, Dave Angel wrote: > On 01/13/2013 11:16 PM, Steven D'Aprano wrote: >> A programmer had a problem, and thought Now he has "I know, I'll solve >> two it with threads!" problems. > > ++10 It took me a moment to figure it out, but in the end I smiled and I agree: +1. > I've been thinking about threads lately, and have come to the tentative > conclusion that they're a solution which has outlived its usefulness for > 99% of the use cases. Much like the Windows 3.1 model of memory usage, > where all memory was shared, and apps promised not to step too hard on > each other. Or the "640k is more memory than any application will ever > need" notion. With this, however, I don't agree. If Python's GIL didn't interfere with the concurrency of threads, I can't think of a good reason to use multiple processes instead, except to use a tool that runs outside the Python virtual machine, or to provide more fault tolerance for long- running server-like applications. We're all adults here, and if the policy is to invoke the methods of objects as documented, then that policy extends to stepping on (or not stepping on) the memory of other threads, too. The APIs for threads and processes is pretty much the same, so I suppose it doesn't matter much, either. Use the right tool for the job. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Mon, 14 Jan 2013 18:56:08 +1100, Chris Angelico wrote: > Awesome! Now, just one more step to make Python into the World's Most > Awesome Language(tm): Replace those lengthy words with single symbols > found in the Unicode set; compress everything down and enforce perfect > Unicode handling. Also, demand that names be one character long, to > enforce creativity by the Mark Rosewater principle. We will then have a > truly wonderful language; everything will be so utterly readable. I think we did that once. We called it APL. ;-) Dan -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pyspread 0.2.3
== pyspread 0.2.3 == Pyspread 0.2.3 is released. The new version improves GPG integration. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is designed for Linux and other GTK platforms. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ What is new in 0.2.3 * GUI front-end for matplotlib charts * Image display in cells * Localization in German, Dutch, Danish and Ukrainian (partly finished) * Dependency to PyMe, rpy and gmpy removed for easier packaging * New dependencies matplotlib, python-gnupg * New example files * Various bug fixes Enjoy Martin -- http://mail.python.org/mailman/listinfo/python-list
Python modules
Is there any "rules" regarding importing python modules within your own module? I mean, how does this affects the performance of the program? For example, I have my own module named "sound". At the top of the file sound.py I have: import scipy In the code I have: import scipy, sound, etc Now I have two instances of every function within scipy, e.g. scipy.r_[a] = sound.scipy.r_[a] Module importing is quite fast, but not instant. It takes some time, but it happens only once. My concern is whether I hold all these multiple instances of same function in the memory, and does this reduce the performance of my program. In short, when creating a module, is it worthwhile to be careful and import only necessary functions, nothing more? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python modules
On Tue, Jan 15, 2013 at 1:54 AM, zoom wrote: > Is there any "rules" regarding importing python modules within your own > module? I mean, how does this affects the performance of the program? > > In short, when creating a module, is it worthwhile to be careful and import > only necessary functions, nothing more? Nope. When you import a module, a record of it is kept in sys.modules, so the next time you import it, it's just picking up the same module object. > scipy.r_[a] = sound.scipy.r_[a] They'll actually be the same thing, which you can test with the 'is' operator. The performance cost of reimporting a module is very low; in fact, trying to avoid it by adorning all your usage with an extra dot-level will probably cost you a lot more, since there'll be an extra lookup every time. Have at it! :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python modules
On 01/14/2013 04:01 PM, Dan Sommers wrote: On Mon, 14 Jan 2013 15:54:27 +0100, zoom wrote: Is there any "rules" regarding importing python modules within your own module? I mean, how does this affects the performance of the program? "Even the initializers are optimized!" -- Mel, the real programmer Great! Unless you've profiled it, and the extra memory taken up by unused functions or modules is measurable and near the top of the list of performance issues, I wouldn't worry about it. Now I have two instances of every function within scipy, e.g. scipy.r_[a] = sound.scipy.r_[a] No: now you have two names for every function within scipy. The functions themselves are not duplicated. Dan Now I love Python even more... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python modules
On Mon, 14 Jan 2013 15:54:27 +0100, zoom wrote: > Is there any "rules" regarding importing python modules within your own > module? I mean, how does this affects the performance of the program? "Even the initializers are optimized!" -- Mel, the real programmer Unless you've profiled it, and the extra memory taken up by unused functions or modules is measurable and near the top of the list of performance issues, I wouldn't worry about it. > Now I have two instances of every function within scipy, e.g. > scipy.r_[a] = sound.scipy.r_[a] No: now you have two names for every function within scipy. The functions themselves are not duplicated. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 2013-01-14, Steven D'Aprano wrote: > A programmer had a problem, and thought Now he has "I know, I'll solve > two it with threads!" problems. :) That took a few seconds -- must be the cold. -- Grant Edwards grant.b.edwardsYow! I hope I bought the at right relish ... z gmail.com... -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with exam task for college
this is what i have right now, it tells me i can't multiply a vector with a vector, i have to find a way to multiply the speed with the updated angle (=hoek in dutch) code : from visual import * import time import math import random class lunar_lander(object): def __init__(self): scene.title = 'mini star wars' scene.width = 375 scene.height = 550 scene.center = (0,0) self.pos = (0,0) self.axis = 0 self.brandstofmeter = brandstofmeter() self.ruimteschip = ruimteschip() self.view = game_view(self) def play(self): t=0 dt=0.01 while t<9: time.sleep(0.01) self.brandstofmeter.update self.ruimteschip.update(dt) t = t + dt class game_view(object): def __init__(self,owner): autoscale=True box(pos=( 0, -375, 0), length=500, height=5, width=0, color = color.white) box(pos=(0,375, 0), length=500, height=5, width=0, color = color.white) box(pos=(-250,0, 0), length=5, height=750, width=0, color = color.white) box(pos=(250,0, 0), length=5, height=750, width=0, color = color.white) maan = curve(pos=[(-250,-353),(-240,-341),(-210,-354),(-199.5,-374)],color=color.red) maana = curve(pos=[(-199.5,-374),(-166,-374)],color=color.green) maanb = curve(pos=[(-166,-374),(-140,-357),(-80,-319),(-40,-361),(0,-321),(40,-329),(80,-347)],color=color.red) maanc = curve(pos=[(80,-347),(140,-347)],color=color.green) maand = curve(pos=[(140,-347),(162,-337),(189.5,-365),(210,-355),(240,-372),(250,-338)],color=color.red) for i in random.sample(range (-250,250),20): for j in random.sample(range (-375,375),20): sterren = points(pos = [i,j,0],size = 2, color=color.white) class brandstofmeter(object): def __init__(self): self.size = (25,45) axis = 0 self.pos = (220,345) self.view = brandstofmeter_view(self) def update(self): while True: if scene.kb.keys: s = scene.kb.getkey() if (s == 'up'): self.view.update(self) class brandstofmeter_view(object): def __init__(self,owner): self.owner = owner meter = box(pos = owner.pos,size = owner.size,color = color.green) def update (self,owner): self.size = self.size - (0,0.45) class ruimteschip(object): def __init__(self): self.pos = vector(0,330) self.axis = (1,0,0) self.view = ruimteschip_view(self) self.vlam = self.view.vlam self.frame = self.view.frame self.hoek = pi / 2 def update(self,dt): zwaartekracht = vector(0,-2,0) self.gas = vector(0,10,0) self.acceleration = zwaartekracht self.axis = (1,0,0) if scene.kb.keys: s = scene.kb.getkey() if (s == "up"): self.acceleration =+ self.gas * vector(math.cos(self.hoek),math.sin(self.hoek)) if (s == "left"): self.hoek =+ pi/12 if (s == "right") : self.hoek =- pi/12 self.pos = self.pos + self.acceleration if self.pos.x > 250: self.pos.x = -250 if self.pos.x < -250: self.pos.x = 250 if self.acceleration != (0,-2,0): self.vlam.visible = True else : self.vlam.visible = False self.view.update(self) class ruimteschip_view(object): def __init__(self,owner): self.owner = owner self.frame = frame(pos = owner.pos,axis = owner.axis) self.motor = curve(frame = self.frame,pos=[(0,24.0),(22.0,24.0),(22.0,39.0),(-22.0,39.0),(-22,24),(0,24)]) self.capsule = curve(frame = self.frame,color = color.blue ,pos=[(0,39),(-3,39),(-9,44),(-12,46),(-18,48),(-22,50),(-18,52),(-12,54),(-9,56),(-3,61),(0,61),(3,59),(9,56),(12,54),(18,52),(22,50),(18,48),(12,46),(9,44),(3,39),(0,39)]) self.poota = curve(frame = self.frame,pos = [(-18,24),(-20,24),(-20,0),(-18,0),(-18,24)]) self.pootb = curve(frame = self.frame,pos = [(18,24),(20,24),(20,0),(18,0),(18,24)]) self.vlam = curve(frame = self.frame,color = color.orange , visible=false,pos = [(0,24.0),(-9.0,14.0),(0,-5.0),(9,14.0),(0,24.0)]) def update(self,owner): self.frame.axis = owner.axis self.frame.pos = owner.pos -- http://mail.python.org/mailman/listinfo/python-list
Re: Python modules
On Monday, January 14, 2013 9:04:00 AM UTC-6, Chris Angelico wrote: > The performance cost of reimporting a module is very low; > in fact, trying to avoid it by adorning all your usage > with an extra dot-level will probably cost you a lot more, > since there'll be an extra lookup every time. Most people "adorn" a module with an extra dot to: 1. create a shorter name (f.e.[1] tk instead of Tkinter) 2. keep their namespace clean. Only a fool would do "from Tkinter import *"[2]. A wise programmer, who needed to access many members of Tkinter, would do instead "import Tkinter as tk", and then prepend all members with "tk.". [1] Abbr: (F)or (E)xample. (I feel an EnglishWart brewing on this subject!) [2] With the exception of command line testing, learning, or playing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/14/2013 09:44 AM, Dan Sommers wrote: > On Mon, 14 Jan 2013 00:31:59 -0500, Dave Angel wrote: > >> On 01/13/2013 11:16 PM, Steven D'Aprano wrote: >>> A programmer had a problem, and thought Now he has "I know, I'll solve >>> two it with threads!" problems. >> ++10 > It took me a moment to figure it out, but in the end I smiled and I > agree: +1. > >> I've been thinking about threads lately, and have come to the tentative >> conclusion that they're a solution which has outlived its usefulness for >> 99% of the use cases. Much like the Windows 3.1 model of memory usage, >> where all memory was shared, and apps promised not to step too hard on >> each other. Or the "640k is more memory than any application will ever >> need" notion. > With this, however, I don't agree. If Python's GIL didn't interfere with > the concurrency of threads, Better minds than mine have tried very hard to eliminate the GIL, so for now I consider that a feature of Python. If the GIL weren't needed for the lowest levels of the interpreter, something else would be needed for all the possible data structures that need atomic updates. Hello semaphores, mutexes, etc. If threading were considered important in a language, it'd have a way to declare an object sharable (default off), and the low level code would go at full speed for any object not so declared. But the language would then provide guarantees for the standard objects that are marked as sharable. That's not current Python. > I can't think of a good reason to use > multiple processes instead, except to use a tool that runs outside the > Python virtual machine, or to provide more fault tolerance for long- > running server-like applications. We're all adults here, and if the > policy is to invoke the methods of objects as documented, then that > policy extends to stepping on (or not stepping on) the memory of other > threads, too. > > The APIs for threads and processes is pretty much the same, so I suppose > it doesn't matter much, either. Use the right tool for the job. > > Dan For other languages, I've done extensive work on projects with heavy multithreading, and getting it right is extremely difficult. Another way of putting it is that any non-trivial project with multithreading is probably buggy. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Sun, 13 Jan 2013 22:46:44 -0800, Rick Johnson wrote: > I have believed for a very long time that "class" was a poor choice of > keyword to designate an "object definition". > > Firstly, the word /class/ does not transform smoothly into CS from > English. NO English definition of "class" comes anywhere close to > describing the "structured source code that defines an object". Or even > generally as: "something that defines something else". Your knowledge of English has failed you. Here is the first definition from Webster's Dictionary (1913 edition): Class \Class\ (kl[.a]s), n. [F. classe, fr. L. classis class, collection, fleet; akin to Gr. klh^sis a calling, kalei^n to call, E. claim, haul.] 1. A group of individuals ranked together as possessing common characteristics; as, the different classes of society; the educated class; the lower classes. [1913 Webster] And definitions 3 and 4: 3. A comprehensive division of animate or inanimate objects, grouped together on account of their common characteristics, in any classification in natural science, and subdivided into orders, families, tribes, genera, etc. [1913 Webster] 4. A set; a kind or description, species or variety. [1913 Webster] "Class" is an excellent ordinary English word to describe what computer science calls a "class". > Thirdly, once people *DO* understand that a "class" is simply an "object > definition", they still go on to say idiotic things like: "Classes are > objects"! Your knowledge of Python has failed you. Classes are objects in Python, although not in all other languages. Classes are created at runtime, not compile time. They have an id, like all instances. They have a __class__ attribute, like all instances. They have a type, like all instances. They *are* instances. py> class Spam(object): ... pass ... py> id(Spam) 168149924 py> isinstance(Spam, type) True > It is obvious these people are a victim of their own terminology. You're very funny. > "subclass": > Since every "user defined object" *must* subclass /something/, Only in Python 3. In Python 2, some classes are not subclasses. py> class OldStyleClass: ... pass ... py> OldStyleClass.__bases__ () > "template": > This term is very close, but still lacking a concrete relationship > between source code (definition of object) and the resulting "thing" > living in memory (object). I think this one is TKO in round 3. A template is certainly not correct for class-based OOP languages like Python, since it implies *copying*. It might be more appropriate for prototype-cased OOP languages like Javascript. [...] > Now since "methods" and "functions" (PyWart on these terms coming soon!) Oh I can barely contain my excitement. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
I love getting that "what's up with this guy" when I start chuckling so hard that I nearly spit out my coffee first thing Monday morning. Thank you sir, this has given my week a bright start :) Demian Brecht http://demianbrecht.github.com On 2013-01-13 8:16 PM, "Steven D'Aprano" wrote: >A programmer had a problem, and thought Now he has "I know, I'll solve >two it with threads!" problems. > > > >-- >Steven >-- >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
And I hope you don't mind I may very well "borrow" this as my e-mail sig. Comedic gold imo. Demian Brecht http://demianbrecht.github.com On 2013-01-13 8:16 PM, "Steven D'Aprano" wrote: >A programmer had a problem, and thought Now he has "I know, I'll solve >two it with threads!" problems. > > > >-- >Steven >-- >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Sun, 13 Jan 2013 21:22:57 -0800, Rick Johnson wrote: > On Saturday, January 12, 2013 12:45:03 AM UTC-6, Steven D'Aprano wrote: >> On Fri, 11 Jan 2013 20:34:20 -0800, Rick Johnson wrote: >> > [...] >> So what do you do for, say, os.path? According to the first rule, you >> must write it as os:path because path is a module; according to the >> second rule, you must write it as os.path because path is a member of >> os. So which rule wins? > > Since "path" is an identifier in the module "os" that points to a system > specific module (which is loaded at run-time), you would access os.path > just as you do today; using the dot. No changes here. Next! Here you say that os.path will not change. But later in your post, you say: > the programmer will need to be sure he places a colon > between modules. Which means a programmer will need to know which path > members are modules and which are objects Since both os and path are modules, you here say that they need a colon between them. This contradicts the above when you say the syntax for os.path won't change. If even you don't understand your own proposal, how do you expect anyone else to understand it? Perhaps you should start by explaining, unambiguously and IN FULL, under what circumstances the programmer will need to use your : syntax. To start: os.path or os:path json.scanner or json:scanner > I said it before and i'll say it again: If you don't know if your calls > are accessing module space or object space (be it instanced object or > static object), then you are sadly informed "Sadly informed"? Dr Freud called, he wants his slip back. Modules are objects, and there is no difference between module space and object space, except that Python provides a convenience syntax for members of the current module. Modules are instances of a class, just like ints, strings, lists, and everything else. py> from types import ModuleType py> type(ModuleType) is type(int) True py> hasattr(os, '__dict__') True [...] > Wait, "classes" are NOT objects. They certainly are. Classes are created at runtime, they have a type -- the class of a class is the metaclass. You can even customize class behaviour with metaclass programming. Perhaps you are thinking about some other language, like Java, which fails to have first-class classes (pun intended). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/13/2013 09:16 PM, Steven D'Aprano wrote: > A programmer had a problem, and thought Now he has "I know, I'll solve > two it with threads!" problems. The same applies to regular expressions, which is actually what the expression was first used with years ago. Probably applies to just about any technology. Including Java. -- http://mail.python.org/mailman/listinfo/python-list
Re: proposal: Ellipsis in argument list
On Sat, Jan 12, 2013 at 5:30 AM, Szabolcs Blága wrote: > Dear All, > > I have an idea that the Ellipsis object could be used in function calls. > The "..." syntax should automagically turn into an Ellipsis positional > argument. > > def f(*args): > ext_args = [] > for i, a in enumerate(args): > if a is Ellipsis: > ext_args.extend([x for x in range(args[i-1]-1, args[i+1])]) > else: > ext_args.append(a) > return ext_args > > Calling it for the above example specifically: > > >>>f(34, ..., 43) > [34, 35, 36, 37, 38, 39, 40, 41, 42, 43] > > That might be useless or someone might say it is confusing, but I think it > would be relatively easy to implement and a nice little syntactic "sugar". > > The basis for adding syntactic sugar is closer to: Is this something that cannot be done clearly without the change, and is commonly useful? Also, as Stefan showed, this is already valid syntax with differing meaning, and thus could break existing code, making the threshold for adding it even harder. This change doesn't seem to useful, and can be easily done already: f(range(34, 43)) Additionally, a decorator could easily be written to do this if you find this is a pattern you commonly use for specific functions (untested), or you can use your expansion function for other cases: def ellipsisExpand(func): def newFunc(*args, **kwargs): ext_args = [] for i, a in enumerate(args): if a is Ellipsis: ext_args.extend([x for x in range(args[i-1]-1, args[i+1])]) else: ext_args.append(a) return func(*ext_args, **kwargs) Then, you use this like: @ellipsisExpand def f(arg): print arg > Best regards, > > Szabolcs Blaga > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On 01/14/13 11:26, Steven D'Aprano wrote: Your knowledge of English has failed you. Here is the first definition from Webster's Dictionary (1913 edition): Class \Class\ (kl[.a]s), n. [F. classe, fr. L. classis class, collection, fleet; akin to Gr. klh^sis a calling, kalei^n to call, E. claim, haul.] 1. A group of individuals ranked together as possessing common characteristics; as, the different classes of society; the educated class; the lower classes. [1913 Webster] Clearly Python should use a keyword like "Kingdom" or "Phylum" instead. I guess "Kingdom" should be reserved for metaclasses (or would they be metaphylums? or metaphyla?) kingdom Baz: pass phylum Foo: __metaphylum__ = Baz That is SO much clearer ;-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
In Michael Torrie writes: > On 01/13/2013 09:16 PM, Steven D'Aprano wrote: > > A programmer had a problem, and thought Now he has "I know, I'll solve > > two it with threads!" problems. > The same applies to regular expressions, which is actually what the > expression was first used with years ago. Probably applies to just > about any technology. Including Java. Steven cleverly worded it in such a way as to apply directly to threads. The sentences are jumbled and interleaved, as if they were the output of two threads that are not synchronized. -- John Gordon A is for Amy, who fell down the stairs [email protected] B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- http://mail.python.org/mailman/listinfo/python-list
Re: Thought of the day
On 01/14/2013 11:09 AM, John Gordon wrote: > In Michael Torrie > writes: > >> On 01/13/2013 09:16 PM, Steven D'Aprano wrote: >>> A programmer had a problem, and thought Now he has "I know, I'll solve >>> two it with threads!" problems. > >> The same applies to regular expressions, which is actually what the >> expression was first used with years ago. Probably applies to just >> about any technology. Including Java. > > Steven cleverly worded it in such a way as to apply directly to threads. > The sentences are jumbled and interleaved, as if they were the output of > two threads that are not synchronized. Very true! Guess I was too distracted by Python's warts to notice. Haha. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson wrote: > You are missing the point of this syntax. The colon is to access MODULE > NAMESPACE. The dot is to access MODULE MEMBERS. A module CAN BE another > module's MEMBER. > > You are also unable to grasp this simple logical fact: Once you arrive at > /any/ MODULE and you start accessing MEMBERS, you will *_ALWAYS_* find > members from that point downwards. If you want us to understand the syntax, then you need to define precisely what you mean by these terms. In what situation does a module have a dotted/coloned path without being a member of another module? Any time you import a.b, the import mechanism finds and loads module b and adds it *as a member* to module a. It follows that a module accessible by a module path is *always* a member of another module. By the above rule, then it would seem that the dot would always be used, and the colon never. I think the distinction you are trying to make here is based upon the submodule's actual source location on the disk. If you have a package folder A which contains a file B.py, then you would access that as A:B, correct? If on the other hand you have a module A.py or package A/__init__.py that loads a module from some other location and then stores it in the A module with the name "B", then that would be "A.B", correct? If I have that right, then the problem with this is that it breaks the virtualization and encapsulation of Python's package structure. When I import os.path, I don't have to know or care how the submodule relationship is implemented, whether it's a simple module in a package or something more complicated. All I need to know is that path is a submodule of os. What you're asking for is that I have to type either "os.path" or "os:path" depending on an implementation detail of the module structure, and if that implementation detail ever changes, then my code breaks. > Because modules and objects are not the same and someone who is reading the > source code NEEDS to know which "path members" are /modules/ and which "path > members" are /objects/. And he needs to know that very important information > WITHOUT opening source files to find out. Why does anybody reading the source code need to know this? We're talking about simple namespaces here. Nobody reading the source needs to care whether those namespaces are implemented as modules or some other type of object. The only substantive difference between the two is whether you can expect to be able to import them directly. If you need to know that, read the documentation. If they're documented as modules, then you can import them. Otherwise, make no such assumption, because even if it works now, that could change later. If we're *not* talking about simple namespaces, then it should be very obvious that they are not modules based upon the fact that the code uses them in ways that modules are not normally used for. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Mon, Jan 14, 2013 at 11:51 AM, Ian Kelly wrote: >> Because modules and objects are not the same and someone who is reading the >> source code NEEDS to know which "path members" are /modules/ and which "path >> members" are /objects/. And he needs to know that very important >> information WITHOUT opening source files to find out. What's more, if the purpose of the syntax is to distinguish modules from non-modules, then the syntax "os.path" (which you have stated would not change) would be misleading, because the "path" part is in fact a module. Your proposed syntax fails to even achieve its stated goal. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Mon, 14 Jan 2013 11:51:50 -0700 Ian Kelly wrote: > On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson > wrote: ...Whatever > If you want us to understand the syntax, then you need to define If you are going to feed the trolls can I please ask that you Cc them or send to them and Cc the list? That way those of us who filter out the trolls can filter out the responses to them as well. Thanks for understanding. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. IM: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
Real mature lot of responses here guys - shows how much you have grown up. Reading this thread looked more like observing a bunch of 3rd grader - somebody offers an opinion and all you can do is ridicule it? Real mature - certainly gives Python a good name having followers like this... But then I guess I will cop flack for this rejoinder too... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python modules
On 2013-01-14, Rick Johnson wrote: > Only a fool would do "from Tkinter import *"[2]. > [2] With the exception of command line testing, learning, or playing. I don't think those should be excepted. Habits acquired during learning/playing will be continue when doing real work, and "Example" code provided as part of lessons/tutorials _will_ get copied into real programs. IMO, tutorials that take shortcuts like "from Tkinter import *" are A Bad Thing(tm). When teaching somebody how to do something, don't show them the wrong way do to something and then after they've learned that add "by the way, don't actually do it that way". -- Grant Edwards grant.b.edwardsYow! Your CHEEKS sit like at twin NECTARINES above gmail.coma MOUTH that knows no BOUNDS -- -- http://mail.python.org/mailman/listinfo/python-list
Finding the variables (read or write)
I'd like to develop a small debugging tool for python programs.In Dynamic
Slicing How can I find the variables that are accessed in a statement? And find
the type of access (read or write) for those variables (in Python).
### Write: A statement can change the program state.
### Read : A statement can read the program state .
**For example in these 4 lines we have:
(1) x = a+b=> write{x} & read{a,b}
(2) y=6=> write{y} & read{}
(3) while(n>1) => write{} & read{n}
(4) n=n-1 => write{n} & read{n}
@@If I use dis(disassembler) How can I get output of dis in python as
dictionary?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
unit selection problem
Unit selection doesn't work properly. Pygames event.pos returns a tuple of the
coords within the current window, so it's not possible to select units outside
of the top left corner.
from pygamehelper import *
from pygame import *
from pygame.locals import *
from vec2d import *
from math import e, pi, cos, sin, sqrt
from random import uniform
from mapeditor import *
from entity import *
from spritesheet import *
# version alpha 0.1
# map drawing seems functional, albeit crude
class Starter(PygameHelper):
def __init__(self):
self.w, self.h = 1600, 900
PygameHelper.__init__(self, size=(self.w, self.h), fill=((255,255,255)))
self.map_layout = map_constructor("map.png", 2400)
self.object_counter = len(self.map_layout.all_map_objects)
map_textures = get_sprites( (48, 48) ,"spritesheet.png" , (0, 0) )
self.collision_map = []
# defines all map objects in readable format
self.map_sprite_list = {
'floor_red' : map_textures.sprites[0],
'floor_dark' : map_textures.sprites[2],
'wall' : map_textures.sprites[1],
'proto_unit' : map_textures.sprites[3],
}
# map scrolling modifiers
self.mod_w = 0
self.mod_h = 0
# introduce agents
self.agent_list = []
self.selected = []
# TODO: make surface size relative to map size
self.mapSurf = pygame.Surface( (3600, 3600) )
# draw the floor once
for e in self.map_layout.fixed_list:
if e.type == 1:
self.mapSurf.blit(self.map_sprite_list['floor_red'], e.rect)
self.mapSurfRect = self.mapSurf.get_rect()
# create a collision map based on wall positions
for e in self.map_layout.all_map_objects:
if e.type == 2:
wall_object = wall()
wall_object.pos = vec2d((e.x_position + 24), (e.y_position +
30))
wall_object.target = wall_object.pos
self.collision_map.append(wall_object)
for e in self.map_layout.all_map_objects: # check map for agents
if e.type == 3:
a = agent()
a.pos = vec2d(e.x_position, e.y_position)
print a.pos
a.target = a.pos
self.agent_list.append(a)
def update(self):
# map scrolling
self.mapSurfRect.center = (((self.w / 2) + self.mod_w), (((self.h / 2))
+ self.mod_h))
# update agent position
for a in self.agent_list:
dir = a.target - a.pos
if dir.length >= 3:
dir.length = 3
a.pos = a.pos + dir
# update the walls, so they are drawn above the floor
for e in self.map_layout.fixed_list:
if e.type == 2:
self.mapSurf.blit(self.map_sprite_list['wall'], e.rect)
# add agents to the mapSurf
for a in self.agent_list:
self.mapSurf.blit(self.map_sprite_list['proto_unit'], a.pos)
def keyUp(self, key):
pass
def keyDown(self, key):
# move the mapSurf object
# TODO: implement continuous camera movement while key is pressed
if key == K_RIGHT:
self.mod_w -= 100
if key == K_LEFT:
self.mod_w += 100
if key == K_UP:
self.mod_h += 100
if key == K_DOWN:
self.mod_h -= 100
def mouseUp(self, button, pos):
# select agent
if button==1:
print pos
for a in self.agent_list:
if a.pos.get_distance(vec2d(pos)) < 24:
self.selected.append(a)
print 'selected'
# right click to move selected agents
if button==3:
for a in self.selected:
a.target = vec2d(pos)
def mouseMotion(self, buttons, pos, rel):
pass
def draw(self):
#self.screen.fill((255,255,255))
self.screen.fill((0,0,0))
self.screen.blit(self.mapSurf, self.mapSurfRect)
#for a in self.selected:
#pygame.draw.circle(self.mapSurf, (50,200,50), a.pos.inttup(), 18,
1) # represent selected units
s = Starter()
s.mainLoop(100)
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Mon, Jan 14, 2013 at 12:35 PM, D'Arcy J.M. Cain wrote: > On Mon, 14 Jan 2013 11:51:50 -0700 > Ian Kelly wrote: >> On Sun, Jan 13, 2013 at 10:22 PM, Rick Johnson >> wrote: > ...Whatever > >> If you want us to understand the syntax, then you need to define > > If you are going to feed the trolls can I please ask that you Cc them > or send to them and Cc the list? That way those of us who filter out the > trolls can filter out the responses to them as well. Sorry about that. I actually have him filtered out too, but then I see other people's responses and I get sucked in. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Tue, Jan 15, 2013 at 6:43 AM, Peter wrote: > Real mature lot of responses here guys - shows how much you have grown up. > > Reading this thread looked more like observing a bunch of 3rd grader - > somebody offers an opinion and all you can do is ridicule it? > > Real mature - certainly gives Python a good name having followers like this... > > But then I guess I will cop flack for this rejoinder too... Rick Johnson is a well-known troll. Opinion is divided as to the best way to handle the matter; one school follows the "Don't feed the trolls" motto and ignores him, the other trolls him right back. Rick has promised for a long time now that he's going to produce a Python 4000 (though I suspect Guido will produce Python 4.0 first, so it'll become Python 5000), but so far we haven't seen *any* code. His eternal complaints about Python are thus pure trolling and not well respected. I'm sorry the forum comes across sounding immature, but it's like a good game of Whack-A-Troll, or what Railbastard calls an "apparatusing". It's the community's way of maintaining itself. Expressing opinions won't get you flamed. Demanding that other people write a whole lot of code to suit your ridiculous notions of "warts" and doing none of the coding yourself, and keeping this up for years and years, WILL eventually get you flamed. And along the way, it gets you into a lot of people's killfiles. Oh, and Dennis? Mal. Bad. From the Latin. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On 15 January 2013 07:57, Chris Angelico wrote: > > Oh, and Dennis? Mal. Bad. From the Latin. :) > I was about to point out the same thing, using the same quote ;) Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the variables (read or write)
On Tue, Jan 15, 2013 at 6:48 AM, wrote:
> I'd like to develop a small debugging tool for python programs.In Dynamic
> Slicing How can I find the variables that are accessed in a statement? And
> find the type of access (read or write) for those variables (in Python).
> ### Write: A statement can change the program state.
> ### Read : A statement can read the program state .
> **For example in these 4 lines we have:
> (1) x = a+b=> write{x} & read{a,b}
> (2) y=6=> write{y} & read{}
> (3) while(n>1) => write{} & read{n}
> (4) n=n-1 => write{n} & read{n}
An interesting question. What's your definition of "variable"? For
instance, what is written and what is read by this statement:
self.lst[2] += 4
Is "self.lst" considered a variable? (In C++ etc, this would be a
member function manipulating an instance variable.) Or is "self" the
variable? And in either case, was it written to? What about:
self.lst.append(self.lst[-1]+self.lst[-2])
(which might collect Fibonacci numbers)?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finding the variables (read or write)
On Mon, Jan 14, 2013 at 1:28 PM, Chris Angelico wrote:
> On Tue, Jan 15, 2013 at 6:48 AM, wrote:
> > I'd like to develop a small debugging tool for python programs.In
> Dynamic Slicing How can I find the variables that are accessed in a
> statement? And find the type of access (read or write) for those variables
> (in Python).
> > ### Write: A statement can change the program state.
> > ### Read : A statement can read the program state .
> > **For example in these 4 lines we have:
> > (1) x = a+b=> write{x} & read{a,b}
> > (2) y=6=> write{y} & read{}
> > (3) while(n>1) => write{} & read{n}
> > (4) n=n-1 => write{n} & read{n}
>
> An interesting question. What's your definition of "variable"? For
> instance, what is written and what is read by this statement:
>
> self.lst[2] += 4
>
> Is "self.lst" considered a variable? (In C++ etc, this would be a
> member function manipulating an instance variable.) Or is "self" the
> variable? And in either case, was it written to? What about:
>
> self.lst.append(self.lst[-1]+self.lst[-2])
>
> (which might collect Fibonacci numbers)?
>
And those aren't even covering the case that a, normally non-mutating,
method actually mutates. Consider the following class (untested):
class Test(object):
def __init__(self, value):
self.value = value
self.adds = 0
def __add__(self, other):
self.adds += 1
other.adds += 1
return Test(self.value + other.value)
With that class,
x = a + b
would mutate x, a, and b, presuming a and b are instances of Test.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finding the variables (read or write)
On 1/14/2013 4:28 PM, Chris Angelico wrote:
On Tue, Jan 15, 2013 at 6:48 AM, wrote:
I'd like to develop a small debugging tool for python programs.In Dynamic
Slicing How can I find the variables that are accessed in a statement? And find
the type of access (read or write) for those variables (in Python).
### Write: A statement can change the program state.
### Read : A statement can read the program state .
**For example in these 4 lines we have:
(1) x = a+b=> write{x} & read{a,b}
(2) y=6=> write{y} & read{}
(3) while(n>1) => write{} & read{n}
(4) n=n-1 => write{n} & read{n}
I would try compiling the source code to an ast (abstract syntax tree).
See the ast module for how to do that and how to 'read' the resulting tree.
An interesting question. What's your definition of "variable"? For
instance, what is written and what is read by this statement:
self.lst[2] += 4
Is "self.lst" considered a variable? (In C++ etc, this would be a
member function manipulating an instance variable.) Or is "self" the
variable? And in either case, was it written to?
'self' is read, 'lst' is written to.
What about:
self.lst.append(self.lst[-1]+self.lst[-2])
(which might collect Fibonacci numbers)?
'self' read, 'lst' read and written. Knowing that for non-builtins is
another matter ;-).
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finding the variables (read or write)
On Tue, Jan 15, 2013 at 8:37 AM, Chris Kaynor wrote:
> And those aren't even covering the case that a, normally non-mutating,
> method actually mutates.
If it's static analysis, I'd quietly ignore those sorts of cases.
Anything can be changed any time, including stuff that's completely
unrelated to what you're working on.
Now, if the OP just wants to know what names get referenced (without
distinguishing reads from writes), that's quite possible, and in fact
easy - if you're willing to analyze a whole function instead of a
single statement.
>>> def foo():
x=y+1
>>> foo.__code__.co_varnames
('x',)
>>> foo.__code__.co_names
('y',)
The first one is the ones that get assigned to (not quite the same as
"written to"), the second is ones that don't. Well, more or less. In
simple cases.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Mon, 14 Jan 2013 19:43:34 -, Peter wrote: Real mature lot of responses here guys - shows how much you have grown up. Reading this thread looked more like observing a bunch of 3rd grader - somebody offers an opinion and all you can do is ridicule it? Now read the rest of the thread. While it is true that Rick offers sufficiently many daft opinions that ridicule is actually likely to be the correct response, there have been detailed (and therefore ignored) responses pointing out his failure to understand both the English language and the last couple of decades of computer science. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
strace of python shows nonsense
Hi there, I am puzzled at how I borked my installation. Python loads slow on my machine, and I decided to use strace and /usr/bin/time to see what is actually happening. # sync && echo 3 > /proc/sys/vm/drop_caches $ /usr/bin/time python2 -c "" 0.19user 0.04system 0:01.22elapsed 19%CPU (0avgtext+0avgdata 4200maxresident)k 7312inputs+0outputs (4major+1145minor)pagefaults 0swaps And when all is in memory: $ /usr/bin/time python2 -c "" 0.19user 0.01system 0:00.21elapsed 98%CPU (0avgtext+0avgdata 4216maxresident)k 0inputs+0outputs (0major+1153minor)pagefaults 0swaps $ /usr/bin/time python2 -c "import argparse" 0.36user 0.02system 0:00.39elapsed 98%CPU (0avgtext+0avgdata 5752maxresident)k 0inputs+0outputs (0major+1699minor)pagefaults 0swaps .2 and .4 seconds to not even get started when all disk I/O is cached. So what is happening here? $ strace -c python2 -c "" % time seconds usecs/call callserrors syscall -- --- --- - - 93.260.001910 8 230 168 open 3.660.75 9 8 mprotect 3.080.63 197 fstat64 0.000.00 0 172 read 0.000.00 063 close <...> $ strace -c python2 -c "import argparse" % time seconds usecs/call callserrors syscall -- --- --- - - 51.890.003732 13 290 read 47.290.003401 18 192 155 stat64 0.820.59 0 129 mmap2 0.000.00 0 549 443 open 0.000.00 0 107 close <...> What puzzles me, is the amount of errors for open and stat64. There are references to stuff I don't know (~/GNUStep directory? Stuff under site-packages that does not exist? Subdirs of site-packages that are not included in sys.path?) What is python doing there, and why? And, more importantly, how can this be corrected? Probably irrelevant, but Python2 version 2.7.3, Archlinux (current as of previous weekend). Thanks, Joep -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Mon, 14 Jan 2013 12:00:13 -0600, Tim Chase wrote: > Clearly Python should use a keyword like "Kingdom" or "Phylum" instead. > I guess "Kingdom" should be reserved for metaclasses (or would they be > metaphylums? or metaphyla?) Metaphyla, of course. >kingdom Baz: > pass > >phylum Foo: > __metaphylum__ = Baz But it's obvious that kingdoms are metaphyla, and it would be silly for one phylum to inherit from another (let alone for a phylum to inherit from a class), so couldn't we just claim that Foo inherits from Baz and be done with it: phylum Foo(Baz): pass > That is SO much clearer ;-) For some definitions of "SO" and "much," yes. ;-) Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Tue, 15 Jan 2013 07:57:58 +1100, Chris Angelico wrote: > Rick Johnson is a well-known troll. I disagree that Rick is a troll. Trolling requires that the troll makes statements that he doesn't believe are true, simply in order to get a response. I do not believe that Rick is doing that. I think he simply has an imperfect, and poor, understanding of Python design principles, coupled with astonishingly high levels of arrogance and self-superiority. Pure Dunning-Kruger effect in action. http://rationalwiki.org/wiki/Dunning-Kruger_effect If I believed he was *dishonestly playing dumb to gain reactions*, then I would not bother to engage with him. But I truly believe that he is not beyond all hope. His posts on tkinter sometimes demonstrate actual knowledge. He is clearly articulate and knows more than one programming language -- although probably not *well*. But, I must admit, the sheer power of Rick's Reality Denial Field often defeats me. In frustration I too often killfile him so I don't have to read his screeds. So I certainly don't blame others who do the same. > Opinion is divided as to the best > way to handle the matter; one school follows the "Don't feed the trolls" > motto and ignores him, the other trolls him right back. I object to that characterisation. I am not dishonestly making provocative statements when I engage with Rick. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On 15 Jan 2013 02:08:38 GMT Steven D'Aprano wrote: > > Rick Johnson is a well-known troll. > > I disagree that Rick is a troll. Trolling requires that the troll Doesn't matter. He duck types as one. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. IM: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
code explanation
Can someone explain what's going on here. def _build_magic_dispatcher(method): def inner(self, *args, **kwargs): return self.__dict__[method](*args, **kwargs) inner.__name__ = method return inner Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: strace of python shows nonsense
On Tue, 15 Jan 2013 00:50:01 +0100, Joep van Delft wrote: > Hi there, > > > I am puzzled at how I borked my installation. Python loads slow on my > machine, and I decided to use strace and /usr/bin/time to see what is > actually happening. Before dropping down to such a low level, I suggest you start at a higher, Python level. Run `python -E` to disable any environment variables and startup file. Does that help? Compare sys.path when running with and without the -E switch. Any important differences? Anything unusual in sys.path, such as directories that don't exist? Run `python -v` to print modules as they are loaded. (Warning: there are a lot of them.) Can you see any obvious delays? [...] > What puzzles me, is the amount of errors for open and stat64. There are > references to stuff I don't know (~/GNUStep directory? Stuff under > site-packages that does not exist? Subdirs of site-packages that are not > included in sys.path?) What is python doing there, and why? And, more > importantly, how can this be corrected? What's the value of the environment variable PYTHONPATH? Do you have a PYTHONSTARTUP set? What is in that file? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code explanation
On Mon, 14 Jan 2013 23:00:16 -0500, Rodrick Brown wrote:
> Can someone explain what's going on here.
>
> def _build_magic_dispatcher(method):
> def inner(self, *args, **kwargs):
> return self.__dict__[method](*args, **kwargs)
> inner.__name__ = method
> return inner
>
> Thanks.
This is a factory function, probably intended to be used as a decorator:
class K:
@_build_magic_dispatcher
def something(self, x, y, z): ...
except that it appears to be broken. It seems to be expecting a *string*,
the name of a method, despite the function parameter claiming to require
a method itself. So maybe you use it like this:
class K:
def __init__(self):
self.parrot = _build_magic_dispatcher("parrot")
or something similar. Without seeing the context, it's hard for me to
tell whether it works or is broken. I suspect it is broken, or useless,
or both.
So, this factory function seems to take the *name* of a method as
argument. Then it builds an inner method, which accepts arbitrary
arguments (args and kwargs), renames the inner method to the name you
passed as argument, and returns it.
The inner method simply looks up an attribute with the same name, and
calls it as a function with whatever args and kwargs it gets.
Does this help?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: code explanation
On 1/14/2013 11:00 PM, Rodrick Brown wrote: Can someone explain what's going on here. def _build_magic_dispatcher(method): def inner(self, *args, **kwargs): return self.__dict__[method](*args, **kwargs) inner.__name__ = method return inner Nothing, until you run that with some particular version of Python. If you do run it, the result should be as documented for that particular version. If you write additional code to call the function, the result will depend on the Python version and argument. Now, what did you actually want to know ;-? You should likely find the answer in the reference manual, especially the section on def statements. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: code explanation
On Mon, Jan 14, 2013 at 11:38 PM, Steven D'Aprano < [email protected]> wrote: > On Mon, 14 Jan 2013 23:00:16 -0500, Rodrick Brown wrote: > > > Can someone explain what's going on here. > > > > def _build_magic_dispatcher(method): > > def inner(self, *args, **kwargs): > > return self.__dict__[method](*args, **kwargs) > > inner.__name__ = method > > return inner > > > > Thanks. > > > This is a factory function, probably intended to be used as a decorator: > > class K: > @_build_magic_dispatcher > def something(self, x, y, z): ... > > except that it appears to be broken. It seems to be expecting a *string*, > the name of a method, despite the function parameter claiming to require > a method itself. So maybe you use it like this: > > class K: > def __init__(self): > self.parrot = _build_magic_dispatcher("parrot") > > > or something similar. Without seeing the context, it's hard for me to > tell whether it works or is broken. I suspect it is broken, or useless, > or both. > > So, this factory function seems to take the *name* of a method as > argument. Then it builds an inner method, which accepts arbitrary > arguments (args and kwargs), renames the inner method to the name you > passed as argument, and returns it. > > Thanks Steven, here is the full context of the code. I'm trying to understand what exactly the author is trying to accomplish here. import sys PY3K = sys.version_info >= (3,) methods = set([ "__iter__", "__len__", "__contains__", "__lt__", "__le__", "__eq__", "__ne__", "__gt__", "__ge__", "__add__", "__and__", "__divmod__", "__floordiv__", "__lshift__", "__mod__", "__mul__", "__or__", "__pow__", "__rshift__", "__sub__", "__truediv__", "__xor__", ]) if PY3K: methods.add("__next__") methods.add("__bool__") else: methods.add("__div__") methods.add("__nonzero__") MAGIC_METHODS = frozenset(methods) del methods def _build_magic_dispatcher(method): def inner(self, *args, **kwargs): return self.__dict__[method](*args, **kwargs) inner.__name__ = method return inner class stub(object): _classes_cache = {} def __new__(cls, **kwargs): magic_methods_present = MAGIC_METHODS.intersection(kwargs) if magic_methods_present not in cls._classes_cache: attrs = dict( (method, _build_magic_dispatcher(method)) for method in magic_methods_present ) attrs["__module__"] = cls.__module__ cls._classes_cache[magic_methods_present] = type("stub", (cls,), attrs) new_cls = cls._classes_cache[magic_methods_present] return super(stub, new_cls).__new__(new_cls, **kwargs) def __init__(self, **kwargs): self.__dict__.update(kwargs) > The inner method simply looks up an attribute with the same name, and > calls it as a function with whatever args and kwargs it gets. > > > Does this help? > > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: code explanation
On Mon, Jan 14, 2013 at 9:51 PM, Rodrick Brown wrote:
> import sys
>
> PY3K = sys.version_info >= (3,)
>
>
> methods = set([
> "__iter__",
> "__len__",
> "__contains__",
>
> "__lt__",
> "__le__",
> "__eq__",
> "__ne__",
> "__gt__",
> "__ge__",
>
> "__add__",
> "__and__",
> "__divmod__",
> "__floordiv__",
> "__lshift__",
> "__mod__",
> "__mul__",
> "__or__",
> "__pow__",
> "__rshift__",
> "__sub__",
> "__truediv__",
> "__xor__",
> ])
> if PY3K:
> methods.add("__next__")
> methods.add("__bool__")
> else:
> methods.add("__div__")
> methods.add("__nonzero__")
> MAGIC_METHODS = frozenset(methods)
> del methods
>
> def _build_magic_dispatcher(method):
> def inner(self, *args, **kwargs):
> return self.__dict__[method](*args, **kwargs)
> inner.__name__ = method
> return inner
>
>
> class stub(object):
> _classes_cache = {}
>
> def __new__(cls, **kwargs):
> magic_methods_present = MAGIC_METHODS.intersection(kwargs)
> if magic_methods_present not in cls._classes_cache:
> attrs = dict(
> (method, _build_magic_dispatcher(method))
> for method in magic_methods_present
> )
> attrs["__module__"] = cls.__module__
> cls._classes_cache[magic_methods_present] = type("stub", (cls,),
> attrs)
> new_cls = cls._classes_cache[magic_methods_present]
> return super(stub, new_cls).__new__(new_cls, **kwargs)
>
> def __init__(self, **kwargs):
> self.__dict__.update(kwargs)
The stub class is called with keyword arguments where the keys are the
names of Python "magic methods" and the values are functions. When
called, it builds a new subclass of itself populated with a
corresponding set of methods, each of which is built by
_build_magic_dispatcher; these look up the method with the same name
in the instance dictionary and delegate the call to whatever they
find. For some reason that eludes me, the generated methods appear to
discard the "self" argument in the process. After the subclass is
generated, it constructs and returns an instance of the subclass, and
then when the __init__ method is called it simply populates the
instance dictionary with the functions that were passed in.
The purpose of this appears to be to construct objects with magic
methods that are defined on the object itself rather than on the
class. Normally, when Python calls a magic method it doesn't look in
the instance dictionary at all and only looks in the class dictionary.
The subclasses of "stub" side-step that by having the desired magic
methods on the class delegate calls to the instance.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart (Terminolgy): "Class"
On Monday, January 14, 2013 11:26:37 AM UTC-6, Steven D'Aprano wrote: > On Sun, 13 Jan 2013 22:46:44 -0800, Rick Johnson wrote: > [...] > Your knowledge of English has failed you. Here is the first definition > from Webster's Dictionary (1913 edition): > > Class [...] >1. A group of individuals ranked together as possessing > common characteristics; as, the different classes of > society; the educated class; the lower classes. > [1913 Webster] This is a poor definition for an object. I would rather apply this definition to a collection of objects than to the definition of a single object. Remember, we want to choose a word that is "self documenting". > And definitions 3 and 4: > >3. A comprehensive division of animate or inanimate objects, > grouped together on account of their common > characteristics, in any classification in natural science, > and subdivided into orders, families, tribes, genera, etc. > [1913 Webster] > >4. A set; a kind or description, species or variety. > [1913 Webster] But again, neither of these definitions describe what an object is, in fact, "class" creates a cognitive disconnect between "object definitions" and "objects". "Class" is only concerned with grouping, characteristics, or comparisons. And let's not forget the obvious. When we are defining "objects" we are wielding a paradigm called "Object Oriented Programming". Only a fool would choose something besides "object" as a keyword. > "Class" is an excellent ordinary English word to describe what computer > science calls a "class". Well if that statement is not a fine example of circular reasoning, i don't what is. o_O > > Thirdly, once people *DO* understand that a "class" is simply an "object > > definition", they still go on to say idiotic things like: "Classes are > > objects"! > > Your knowledge of Python has failed you. > > Classes are objects in Python, although not in all other languages. Python "classes" are OBJECT DEFINITIONS, not OBJECTS! > Classes are created at runtime, not compile time. 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. Would you argue as intently that the fictional characters of LOTR are real? They could be considered real in your imagination, but without a mind to interpret these characters they will be nothing more than text on a page. Same goes for classes. > They [classes] have an id, like > all instances. They have a __class__ attribute, like all instances. They > have a type, like all instances. They *are* instances. Replace "class" with object and you will be correct. > 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? Stop fooling around Steven, really. > > "subclass": > > Since every "user defined object" *must* subclass /something/, > > Only in Python 3. In Python 2, some classes are not subclasses. > > py> class OldStyleClass: > ... pass > ... > py> OldStyleClass.__bases__ > () Ignoring the fact that this comment has nothing to do with the main argument and is in fact an attempt to distract the audience from your downward spiral of circular reasoning... "OldStyleClasses are a direct result of GvR and his anti OOP (anti functional also) programming mentality and lend no weight to your argument. Gudio was wrong to allow classes to be defined without deriving from /something/. He wisely removed old style classes in Python3000. They don't exist in Python's future. Let them rest in peace. > > "template": > > This term is very close, but still lacking a concrete relationship > > between source code (definition of object) and the resulting "thing" > > living in memory (object). I think this one is TKO in round 3. > > A template is certainly not correct for class-based OOP languages like > Python, since it implies *copying*. It might be more appropriate for > prototype-cased OOP languages like Javascript. Agreed. I never really liked the term anyway, but i needed one more choice to round out my list of candidates. Think of "template" as the ugly friend the average girl brings to the bar to make herself seem prettier by comparison. *wink* -- http://mail.python.org/mailman/listinfo/python-list
sqlite3 puzzle
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Monday, January 14, 2013 11:34:56 AM UTC-6, Steven D'Aprano wrote: > Since both os and path are modules, you here say that they need a colon > between them. This contradicts the above when you say the syntax for > os.path won't change. But you forgot the rule about accessing module members with the dot :) > If even you don't understand your own proposal, how do you expect anyone > else to understand it? > > Perhaps you should start by explaining, unambiguously and IN FULL, under > what circumstances the programmer will need to use your : syntax. I will admit i may have confused a few of you (and myself) since i overused the word "module" when i really meant "package". pkg1:pkg2:pkgN.member1.member2.memberN -- http://mail.python.org/mailman/listinfo/python-list
Re: strace of python shows nonsense
Joep van Delft writes: > ... > What puzzles me, is the amount of errors for open and stat64. The high number of errors comes from Python's import logic: when Python should import a module/package (not yet imported), it looks into each member on "sys.path" for about 6 different potential filename spellings corresponding to the module -- until it succeeds or has tried all members. Most such filesystem lookups will fail - giving a high number of "stat" errors. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Module access syntax
On Monday, January 14, 2013 12:51:50 PM UTC-6, Ian wrote:
> I think the distinction you are trying to make here is based upon the
> submodule's actual source location on the disk. If you have a package
> folder A which contains a file B.py, then you would access that as
> A:B, correct? If on the other hand you have a module A.py or package
> A/__init__.py that loads a module from some other location and then
> stores it in the A module with the name "B", then that would be "A.B",
> correct?
Yes! The colon accesses package space (the "top-level namespace" if you will).
The dot accesses members.
> If I have that right, then the problem with this is that it breaks the
> virtualization and encapsulation of Python's package structure. When
> I import os.path, I don't have to know or care how the submodule
> relationship is implemented, whether it's a simple module in a package
> or something more complicated. All I need to know is that path is a
> submodule of os.
Well one the main problem with packages is that we have no rules for defining
them. I think of packages as namespaces. And as such they should have public
members, private members, and shared members. The author of ANY package should
place the /public members/ into the __init__ file *via import* for access by
the user. The user should NEVER access package sub-modules directly!
> What you're asking for is that I have to type either
> "os.path" or "os:path" depending on an implementation detail of the
> module structure, and if that implementation detail ever changes, then
> my code breaks.
You keep using os.path as an example. path should be it's OWN module living in
some package, and NOT a member of os. So you would import them separately. But
if insist on keeping "path" in "os", fine. Even IF os where a package, the
syntax would still be the same because there is only one level of package
("os") before you get to the member "path". Do you understand?
os.path.whatever
However, if "os" lived in a package named "lib" you would access via:
lib:os.path
See, the colon designates package namespace.
But these modules are bad examples because they do not require deep nesting of
packages. GUI libraries however are a great example. That is why i posted the
hypothetical path:
lib:gui:tk:dialogs.SimpleDialog
Here are few more to get a feel:
lib:gui:tk:dialogs.MessageBox
lib:gui:tk:dialogs.FileDlg
lib:gui:tk.constants
lib:gui:tk:widgets:Button
lib:gui:tk:widgets:XXX
If we build consistent packages and use a consistent syntax to access them, our
code will be self documenting. However, I don't think the Python devs take the
subject of packages very seriously.
For example, look at Tkinter in Py3000, we still have a single monolithic
"tkinter" module with every possible widget class stuffed into it, along with
ABCs, and variables classes, and outdated functions, and the kitchen sink! All
they did was to move and rename the dialog and font classes and then patted
themselves on the back.
This is NOT how you structure a package! We need to use a structured package
approach to tame this wild beast called Tkinter.
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)
But if he cannot even care enough about Python to send a single paragraph
email, or he's holding a grudge because i am critical of "some" parts of the
language, well then, don't be expecting any help from me! I would not bother to
criticize if i did not think Python was the best base for which to build a
great language.
Nobody can build a perfect language, Guido included. You give it you best shot
and then you tweak and tinker as new unforeseen problems arise. Sometimes you
have no choice but to break backwards compatibility. These are all necessary
stepping stones in a languages evolution. This snake needs to shed an old skin
so the new skin can grow.
--
http://mail.python.org/mailman/listinfo/python-list
