Re: WxPython versus Tkinter.
From: "Emile van Sebille" On 1/25/2011 3:33 PM rantingrick said... Tkinter is old and in many ways insufficient for 21st century GUIs. We need to decide what should come next. I believe wxPython is our best hope. Wx may not be the best it can be, but it is the best we have at this time. Then you should immediately volunteer to bring wxPython to python3 compatibility -- as it is, it's not even close... Start thinking about upping your game from ranting to doing. Emile Hi Emile, From my point of view this discussion is finished for the moment, because you are right, WxPython is not as fast developed as it needs, because Python 3 is not compatible with Python 2. If no solution is found for this big problem, then yes, WxPython can't be included in the Python distribution because there is nothing that can be included. I don't know why you didn't say this before. :-) The other part of the discussion is related to the accessibility and care for accessibility and that discussion is not nice at all, because it shows how selfish are most of the people and they consider this a virtue. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Emile van Sebille" Are third party installations nonsense? Or should python come with all libraries for all potential applications? And then always keep up with best of breed? Python should not include all the libraries for all the potential applications, but it should promote the tools that don't generate discrimination without even willing to do that. If there is no accessible portable GUI lib for Python 3 as you said, then it is very normal that Python can't promote it, because there is nothing to promote if Python 3 doesn't offer accessible portable interfaces. But this is the real reason and not the fact that the accessibility shouldn't be important nor that my atitude of caring for the others is not right and should be changed with a more selfish one. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "geremy condra" There's a difference between what you say and how you say it. If a friend came up to you and said "give me $100 right now!", you probably wouldn't do it. If the same friend came up to you and said "I know this is a big thing to ask, but I really need $100 and I can't guarantee I'll be able to pay you back. Could you please help me?" I Are you even thinking that the second sentence is much harder to express? Do you imagine that my knowledge of English is limited by the fact that it is not my native language and it is a language not spoken by very many people in my country? I simply might not be able to express so nice as you like that I need 100 bucks from you, but I might be able to just tell you that "need 100 dollars. now". I could argue much more nice and expressive if we were speaking Romanian and not English. But I don't condemn you for this, because many years ago when I was in school I had the opinion that some foreign colleagues are a little stupid just because they were not able to express very well the ideas which were not very simple, and well, they were not stupid at all, but they didn't know my language well enough and they probably would think the same thing about me if we were speaking in Russian. don't know very many people who would refuse if they were able to help. The reason is simple: the first does not acknowledge the value of the person doing the favor, and the second does. Exactly what I said. They are doing the same mistake as I did 20 years ago. By the way, can't you see any syntactic dissacords in my phrases? Haven't you think that my English might not be as fluent to be able to express everything I want to say very well? More concretely, you have an opinion that not supporting accessibility is discrimination. Tyler has an opinion that not supporting accessibility is a bug. This is not always true. Not supporting accessibility when *it is not possible* yes, it is a bug as you say, so we agree here. But not supporting accessibility because the programmer *doesn't want this*, it is not a bug, but discrimination. Don't you agree with this? And if Python would have been able to support accessibility it would have mean that it promotes discrimination because it promotes the wrong tool, but it seems that Python 3 doesn't have an accessible GUI lib for the moment, so no, it is not discrimination (but Emile told us that there is no support for WxPython in Python 3 just today, so I didn't know this and I already wondered why nobody told about this real problem). Are you going to demand that he change his opinion? Or are you going to ask that he consider yours? It seems that the discrimination should be something that should be discussed if and when it should be applied, isn't it? Well, I think that everyone should understand why the programs must be accessible and why everybody should care about all the users of an application and that it is not normal to not care. Have I said something wrong? Did I use bad words? Or what was it wrong? I think it was uncivil. It was rude, unkind, and generally disagreeable. I lost respect for you, and by proxy, for your point of view. In other words, you lost support not because fewer people agree with your position, but because fewer people want to agree with you. You are also very unkind and rude when you say that the disabled that need to use a screen reader should be a kind of second hand people that need to beg for a little accessibility. When you create a program, why do you create a visual interface for it? Why don't you create just an audio interface? You do this because otherwise you would not please those who can see. Why shouldn't be something normal, and that *should be not be discussable at all* to offer the same accessibility to everyone? And you didn't say what was rude from what I said. You said just that it was rude. Oh yes I know that it is unkind because most of the people don't even like to talk personally with disabled people, but this doesn't mean that the disabled people are something not normal, but those who have those biases towards those who are very different. I have just an opinion, but that opinion won't change until the opinion of those who pretend that the discrimination is something normal. Do you think that this is not normal? I didn't ask you to change your opinion. I told you that you would be more effective if you changed your attitude. Like rantingrick, you're free to ignore that advice, but it is good advice for both you and the community, and I urge you to take it. About what community? It would be better for the community of the disabled? Or you don't care about that community? Or you recommend me to be just like Tyler that can't use all the apps he could use if they were accessible, but he doesn't care because he cares much more to play nice in order to be accepted in this not-right society? I would recommend that you l
Re: WxPython versus Tkinter.
From: "Nicholas Devenish" Octavian, we get it - you are on the warpath about accessibility. And this is, in a way, a good thing, because, yes, programmers should in general think more about accessibility when designing their programs. But nobody was ever persuaded to consider a complicated and subtle issue by hostile holier-than-thou arrogance, which is what rantingricks posts started out with, and what your posts have been slowly turning into. This is what is 'not a good thing', in case you genuinely didn't understand the context of my previous message. Look at the response your earlier posts got, with experienced developers showing an interest in actually trying out accessibility tools. Compare this with the defensive replies you have been getting more recently. Hi Nicholas, Thank you for your nice words. I admit that I don't understand absolutely everything (for example I have met "holier-than-thou" only in a song of Metallica, but I don't know what it really means :-) I know only that Tk is very old and it is still not accessible and it doesn't mean too much if some developers say that they are interested in making it accessible, because even with a hard work, a GUI lib like Tkinter may be made accessible only after years of work, because the accessibility standards change, the main OS used by the majority of users also change... and I thought that Python already offers a solution for this problem. However I can see that for the moment it doesn't offer it because WxPython is not compatible with Python 3. (I am wondering if there would be any change if Python 3 could be used with WxPython). But this thread is not about that, and the accessibility issue is mostly a red herring that rantingrick has grabbed hold of to swing around like a battleaxe, because nobody is going to say that accessibility doesn't matter. Discrimination in many forms, is a real problem in our societies, and one that is not going to be solved overnight, much as you might wish it. Stigmatizing perfectly repectful people who haven't encountered your needs before, or don't agree that accessibility is the only thing that matters, is not going to solve any issues. Well, I am on this list just for a few weeks, and I don't know yet who is respectable and who is not, who is an expert or not, and so on. I just expressed my opinion that if there is a solution for accessibility it should be prefered and it should be promoted by Python. Actually this is the main idea. Nobody should force the developers to use that accessible solution, but those who don't use it should understand and accept that they are using a not recommended and a wrong tool. Of course that there may be many cases in which such a wrong tool would be prefered for commercial reasons, but the developers that do that should understand that they are doing something wrong. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Steven D'Aprano" Quality code is a good thing, but there are people who write good code but are so obnoxious that you wouldn't listen to a word they have to say, and people who are only mediocre or average coders, but are otherwise helpful and friendly. I'm amazed that Rick actually asked that question. Was he being sarcastic? In virtually every thread he takes part in, he is implicitly or explicitly told what he needs to do to be taken seriously: - stop ranting; - it's not all about him; - stop using "we" when he really means "me"; - he is not the conscience of the Python community; - stop pretending to be speaking for the community when it's obvious the community doesn't agree with him; - stop insulting everyone unless they agree with him; - if people don't agree with Rick, that doesn't mean they're in thrall to a hide-bound reactionary elite that has lost all touch with what makes Python good; - enough with the hero-worship of Guido (except when he's insulting Guido as well); - stop demanding others do all the work -- if Rick thinks something should be done, he should start a project and begin building it, then ask for volunteers to help; - listen to others' criticisms, don't just dismiss them without thought; - there's no shame in being mistaken if you are big enough to admit, and learn from, your errors; - enough with the over-blown melodrama, Python isn't going to be destroyed just because there's some tiny little corner that doesn't meet Rick's idea of perfection. That would do for starters. TL;DR. The shorter version: stop being a dick, and people will treat you seriously. Wow! now I think I understand some of the atitudes on this list. It seems that some of the list members know each other very well, and they have strong opinions, maybe for good reasons, I don't know, and I just dropped some messages without knowing who is considered good, who is the bad, who are those with valuable opinions and so on. I am sorry if I offended someone, but the main idea I just wanted to express was that Python should promote the accessibility and deprecate those tools which are not accessible. That's all. It should not force anyone to use anything but it just promote the right tools (which is not the case now, but it seems that there is a technical reason for this... the fact that WxPython can't be used in Python 3). Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/25/11 8:21 PM, Steven D'Aprano wrote: > TL;DR. The shorter version: stop being a dick, and people will treat you > seriously. I actually read the original list, and agreed with every point. But this concise summary spells it out perfectly. Stop being a dick, rick. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Need GUI pop-up to edit a (unicode ?) string
On 1/26/2011 2:11 AM, rantingrick wrote: On Jan 26, 12:53 am, Terry Reedy wrote: I only see "self.wait_window(self)" in the Dialog base class and not in SimpleDialog, which is what I though you were talking about. It is the last line of Dialog.__init__. Yes. In the module "tkSimpleDialog" In 3.x, the module is now tk.simpledialog -- all lower case. The purpose of all lowercase module names is to avoid confusion with upper case class names. the class "Dialog" is what i am referring to. Sorry for the confusion. and there is also a SimpleDialog class. It appears that the intention is that all configuration be done in the body and button_box methods which are called earlier. Yes exactly. And this works well most of the time. However there are many times where you may want to create a dialog with say a Label. And you do not want to hard code the string displayed on the label. However you cannot change the string once you initialize the dialog because it enters a "modal wait loop". So what i am proposing is that we change tkSimpleDialog to be like any other modal dialogs out there. SimpleDialog has a go method. Dialog does not, but I see no reason (yet) why it could not. We move the modal code into a show method and use the dialog like i suggested. I can send you a patch if you would be interested. I saw that first and was puzzled what you were asking. Clearer now. My patch does break backward compatibility. However we can make it compatible somehow. Or an alternative approach would be to create a new dialog module and then depreciate tkSimpleDialog. Let me know on or off list if you are interested. As far as I know, anything contributed to the stdlib has been licensed by the author to be redistributed under the Python license and can be patched by the developers. (This is one reason for people to not contribute their code to the stdlib.) I don't understand what that means. Are you suggesting that contributing code is bad? If you write code and want to keep absolute control over it -- the api, the doc, the coding style, and the test methods -- then yes it can be bad, especially for people who are not active core developers. Contributing can also be a great -- if the module already meets with approval or if one is flexible and wants the critical review and likely improvement and increased usage. It depends on one's goal in writing the code. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: A and B but not C in list
Terry Reedy writes:
> On 1/23/2011 4:05 PM, CM wrote:
>> In Python, is there a recommended way to write conditionals of the
>> form:
>>
>> "if A and B but not C or D in my list, do something." ?
>>
>> I may also have variations on this, like "if A but not B, C, or D".
>>
>> Do I have to just write out all the if and elifs with all possible
>> conditions, or is there a handier and more code-maintainable way to
>> deal with this?
>
> The straightforward code
>
> if a in L and b in L and c not in L and d not in L
>
> scans the list 4 times. One scan be be done generically as follows:
>
> def req_pro(iterable, required = set(), prohibited = set()):
> for item in iterable:
> if item in prohibited:
> return False
> elif item in required:
>required.remove(item)
> else:
> return not required # should now be empty
>
> if req_pro(my_list, {A,B}, {C,D}): ...
> # untested, of course..
But what's better? Four fast list scans or one slow one?
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Syntax help
How to read syntax like this given in the documentation of python? (Newbie) defparameter ::= parameter ["=" expression] http://docs.python.org/reference/compound_stmts.html#function-definitions -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding the right Python executable on Windows
On Tue, Jan 25, 2011 at 3:24 PM, Brian Curtin wrote: > On Tue, Jan 25, 2011 at 04:25, Geoff Bache wrote: >> >> Hi all, >> >> I have a Python process on Windows and would like to start a Python >> subprocess using the same interpreter. I wonder how to go about this? >> >> First, I tried the obvious >> >> subprocess.Popen([ sys.executable, "subproc.py", ... ]) >> >> but that fails, because my process has a "native launcher", (i.e. C: >> \path\mylauncher.exe, which is just a wrapper around the Python >> program) and hence sys.executable returns this path instead of the >> interpreter location. It isn't appropriate to use the launcher for the >> subprocess. >> >> I also tried using sys.exec_prefix but there didn't seem to be any >> standard location for the interpreter under this directory in any >> case. >> >> I feel certain there must be some way to do this as it seems a rather >> basic thing somehow, can anyone give me a hint? >> >> Regards, >> Geoff Bache > > If sys.executable doesn't work due to this "native launcher", you could > try something like this: import os import sys full_path = None for path in sys.path: > ... full = os.path.join(path, "python.exe") > ... if os.path.exists(full): > ... full_path = full > ... full_path > 'c:\\python31\\python.exe' Thanks Brian! It never occurred to me that the Python executable would be on sys.path, but it seems to be on the installations I've tried on Windows. It isn't on other platforms of course, but it's easy enough to only do this on Windows. I wonder why it's like this? I can't see anything in that directory I could import... Regards, Geoff -- http://mail.python.org/mailman/listinfo/python-list
Re: trouble installing MySQLdb (cygwin) + Bonus question
On 1/25/2011 3:51 PM, Matthew Roth wrote: On Jan 25, 6:20 pm, David Robinow wrote: On Tue, Jan 25, 2011 at 5:59 PM, Matthew Roth wrote: On Jan 25, 9:34 pm, John Nagle wrote: ... You can install a MySQL server under Windows, and talk to the server from the Cygwin environment. That's a useful way to test. John Nagle Right, that is precisely what I have. I am able to talk to it from cygwin, however, during the installing of the MySQLdb module it cannot find the mysql_config. This is because It is not installed? The setup sees that I am on a posix system not windows, as python is installed in cygwin, a virtual posix system. I am trying to bulid a mysql client from source for cygwin, however, I am running into an error there. Unless, can I talk to the windows mysql_config? if so, what does that look like The obvious answer is to use a Windows python. You haven't explained why you think you need to run a cygwin python. Can you explain that? Good question. There isn't a solid explanation. heretofore, I have been using a lot of bash scripting in combination with awk sed and some perl. I was directed to look into python. My tasks were becoming increasingly complex and memory intensive. I started with a desire to connect to a mysql server. For that I needed to install the MySQLdb module. I am having difficultly in acomplishment of this task. I suppose for the time it has taken, using windows python would have been the simpler route. Oh. And all this time, I thought it was because you needed to run on a Linux server and were using Cygwin for debugging. I routinely develop Python on Windows and run on Linux servers. This works fine, provided that you can find versions of any necessary C modules for Python for both platforms. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 11:18 am, "Octavian Rasnita" wrote: > From: "rantingrick" > On Jan 25, 3:41 pm, Corey Richardson wrote: > > > Do you honestly think he was talking about the accessibility problem? > > IMO that should move to another thread, because this one is simply > > about, as the subject suggests, "WxPython versus Tkinter". > > Corey again (like many) you lack a global perspective. Anybody who has > read along with his thread knows we are covering some pretty big > issues here. WxPython is just the vehicle. The big picture is simply: > Tkinter is old and in many ways insufficient for 21st century GUIs. We > need to decide what should come next. I believe wxPython is our best > hope. Wx may not be the best it can be, but it is the best we have at > this time. There is more than "meets the eye" Corey! > -- > > I will tell you what I think and many of you won't like this. :-) > I think that nothing is "sufficient" and nothing should last forever. > > The people don't need Tkinter. They don't need WxPython. They don't need > Python. Do you think that Python is a language that will be used forever? > The people don't necessarily need to use a computer. Do you think that the > computers as they are today will be used until the end of the time? > > The people do need to have an easier life, to make as little efforts as > possible and to obtain as much benefit as possible and for the moment the > computers and Python and a GUI lib help them do this, so these things are > just some other means for obtaining what they need. > > What we don't agree is that some of the list members think that only the > selfishness is the right ATITUDE AND SAY THAT I should change mine because I > should care more about my own benefits and don't care at all about the > others. > > Octavian Hi Octavian, Normally I would expect talks of selfishness etc to be too OT for a python list. However since nobody is saying that (yet) let me point you to a passage from the upanishads: http://www.hindu-blog.com/2007/10/brihadaranyaka-upanishads-quotes-sage.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Syntax help
On Wed, 26 Jan 2011 00:08:41 -0800, sl33k_ wrote: > How to read syntax like this given in the documentation of python? > (Newbie) > > defparameter ::= parameter ["=" expression] > > http://docs.python.org/reference/compound_stmts.html#function- definitions See here for an explanation: http://docs.python.org/reference/introduction.html#notation What you are looking at is not Python code, instead it is a formal description of what Python syntax looks like, based on a slightly modified BNF syntax: http://en.wikipedia.org/wiki/Backus–Naur_Form This tells you that a "defparameter" looks like a "parameter" followed optionally by an equals sign and an expression. For example, here is a line of Python code: def function(x, y=42**3): "x" is a defparameter made up of a parameter on it's own, while "y=42**3" is a defparameter made up of three parts: the parameter part "y", the equals sign, and the expression part "42**3". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Syntax help
On 26.01.2011 09:08, sl33k_ wrote: How to read syntax like this given in the documentation of python? (Newbie) defparameter ::= parameter ["=" expression] http://en.wikipedia.org/wiki/Backus-Naur_Form -- http://mail.python.org/mailman/listinfo/python-list
Re: Behaviour-based interface/protocol implementation?
On Tue, Jan 25, 2011 at 6:48 PM, Terry Reedy wrote: > This is correct! > > print(len(mo)) > TypeError: object of type 'MyObj' has no len() That's interesting. I must admit I was not thinking about special methods in my original post, I used that example just because of Chris response. by the way, define 'correct' - if that means 'that's how this works in python', it's a tautology, not correctness :-) Instead I think this highlights an asymmetry in how python handles special methods, and makes it less ducktyped than I wanted. Consider this: class MyObject(object): @staticmethod def __len__(): return 1 mo = MyObject() print mo.__len__ print len(mo) class LenObj(object): def __len__(self): return 3 lo = LenObj() print lo.__len__ print len(lo) import types class OtherObj(object): pass oo = OtherObj() def __len__(self): return 2 oo.__len__ = types.MethodType(__len__, oo, OtherObj) print oo.__len__ print len(oo) Output: 1 > 3 > Traceback (most recent call last): File "pymethods.py", line 34, in print len(oo) TypeError: object of type 'OtherObj' has no len() The problem is not "function attributes" - the problem is that the __len__() method must be set on the class, not on the instance. I think this is not completely clear here: http://docs.python.org/reference/datamodel.html By the way, my original post didn't take into account special methods - let's suppose they don't exist for a moment. I'd just like to check *at runtime* whether an object *any object!* respects a certain signature. *I don't want to care about the class of that object because I want true duck typing*. I mean, I should be able to pass *anything* that responds to a certain contract: @DuckType class MyInterface(object): def someMethod(self): pass def otherMethod(self, a, b): pass class SomeObj(object): @classmethod def someMethod(cls): pass @classmethod def otherMethod(cls, a, b): pass class OtherObj(object): def someMethod(self): pass def otherMethod(cls, a, b): pass class ThirdObj(object): pass oo = OtherObj() to = ThirdObj() to.someMethod = lambda: None to.otherMethod = lambda a,b: None MyInterface.maybe_implemented_by(oo) # -> True MyInterface.maybe_implemented_by(to) # -> True MyInterface.maybe_implemented_by(SomeObj) # -> True That's just what I'd like and I suppose can't be currently done with current ABC, PyProtocols or zope.interface implementations, right? -- Alan Franzoni -- contact me at public@[mysurname].eu -- http://mail.python.org/mailman/listinfo/python-list
Convert XML to SQL
I an not a Python newbie but working with xml is new to me.
I get data through a soap connection, using suds, and want to convert that
to objects which I can use to populate a rather complex database.
I have been able to parse the xml using
tree = etree.iterparse(infile,events=("start","end")) but it seems like a
lot of work to get that to sql-objects.
I have seen references to lxml.objectify and have created a object
containing the contents of a whole file using
tree = objectify.parse(fileobject)
That object contains for example the data of 605 records and I do not know
how to use it. I could not figure out from the lxml.objectify documentation
how to do it.
In the end I want to use data from about 54 fields of each records. I would
like to have a list of dictionaries as a result of the parsing. From there
it should not be too difficult to create sql.
I have seen some references to BeautifulSoap but I am not sure which is the
best way to go.
So:
Is there a better tool than lxml to do this?
Is it possible to do it just using suds? The suds documentation did not
really help me to do this with complex data.
Are there good tutorials for the xml->sql process?
Regards
Johann
--
May grace and peace be yours in abundance through the full knowledge of God
and of Jesus our Lord! His divine power has given us everything we need for
life and godliness through the full knowledge of the one who called us by
his own glory and excellence.
2 Pet. 1:2b,3a
--
http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "rusi" On Jan 26, 11:18 am, "Octavian Rasnita" wrote: From: "rantingrick" On Jan 25, 3:41 pm, Corey Richardson wrote: > Do you honestly think he was talking about the accessibility problem? > IMO that should move to another thread, because this one is simply > about, as the subject suggests, "WxPython versus Tkinter". Corey again (like many) you lack a global perspective. Anybody who has read along with his thread knows we are covering some pretty big issues here. WxPython is just the vehicle. The big picture is simply: Tkinter is old and in many ways insufficient for 21st century GUIs. We need to decide what should come next. I believe wxPython is our best hope. Wx may not be the best it can be, but it is the best we have at this time. There is more than "meets the eye" Corey! -- I will tell you what I think and many of you won't like this. :-) I think that nothing is "sufficient" and nothing should last forever. The people don't need Tkinter. They don't need WxPython. They don't need Python. Do you think that Python is a language that will be used forever? The people don't necessarily need to use a computer. Do you think that the computers as they are today will be used until the end of the time? The people do need to have an easier life, to make as little efforts as possible and to obtain as much benefit as possible and for the moment the computers and Python and a GUI lib help them do this, so these things are just some other means for obtaining what they need. What we don't agree is that some of the list members think that only the selfishness is the right ATITUDE AND SAY THAT I should change mine because I should care more about my own benefits and don't care at all about the others. Octavian Hi Octavian, Normally I would expect talks of selfishness etc to be too OT for a python list. However since nobody is saying that (yet) let me point you to a passage from the upanishads: http://www.hindu-blog.com/2007/10/brihadaranyaka-upanishads-quotes-sage.html -- Nice passage, but I think that you have also noticed that the most important things it talks about are the closed people, the gods, the brahmana and kshatriya, but well, in India there other chasts than brahmana and kshatriya but only these 2 chasts of priests - the spiritual power and the military - the force power are considered important. The indian culture is great for many things, but it is not great when talking about discrimination, because even now that their laws forbid the chasts-based discrimination, many people there still believe that somebody from brahman or kshatriya chasts have a bigger value than the others. I don't say that those people are not right, nor that those who have the power are not more valuable than the others right now, but I say that it is not normal to consider this way of thinking a right way, because on the long term this should change and there should be no privileged group. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert XML to SQL
Johann Spies, 26.01.2011 10:07:
I an not a Python newbie but working with xml is new to me.
I get data through a soap connection, using suds, and want to convert that
to objects which I can use to populate a rather complex database.
Your problem description is pretty comprehensive in general. It would be
helpful to see an example snippet of the XML that you parse.
I have been able to parse the xml using
tree = etree.iterparse(infile,events=("start","end")) but it seems like a
lot of work to get that to sql-objects.
I have seen references to lxml.objectify and have created a object
containing the contents of a whole file using
tree = objectify.parse(fileobject)
That object contains for example the data of 605 records and I do not know
how to use it. I could not figure out from the lxml.objectify documentation
how to do it.
In the end I want to use data from about 54 fields of each records. I would
like to have a list of dictionaries as a result of the parsing. From there
it should not be too difficult to create sql.
I think iterparse() is a good way to deal with this, as is objectify.
iterparse() has the advantage that you can dispose of handled records, thus
keeping memory usage low (if that's an issue here).
Using objectify, you would usually do something like this:
tree = objectify.parse(fileobject)
root = tree.getroot()
for record in root.xml_record_tag:
title_name = record.title.text
It really just depends on what your XML looks like. In the above, I assumed
that each record hangs directly below the root tag and is called
"xml_record_tag". I also assumed that each record has a "title" tag with
text content.
With iterparse(), you would intercept on your record elements and then use
the ElementTree API, commonly the findtext() and findall() methods of the
root object, to get at the specific record fields. Like this:
for _, element in ET.iterparse(fileobject):
if element.tag == 'xml_record_tag':
title_name = element.findtext('title')
Does this help?
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: List behaviours with Clustering Algorithm
James Ravenscroft wrote:
>> > I can't run your code because you didn't make it standalone,
> Thanks for the heads up, I've made a simple version of the clusterer
> which you can view on pastebin: http://pastebin.com/7HmAkmfj If you have
> time to look through my code I would be very grateful!
>
>
>
>> > but in your case that is probably not enough.
>> > Try something along these lines:
>> >
>> > # untested
>> > while len(self.clusters) > 1:
>> > c = self.clusters.pop()
>> > # find closest index
>> > for i, c2 in enumerate(self.clusters):
>> > ...
>> > if ...:
>> > closest_index = i
>> > closest = self.clusters.pop(closest_index)
>> > tmp.append(c + closest)
>> > if self.clusters:
>> >tmp.append(self.clusters[0])
> I had a go at implementing something along the lines above and I'm still
> getting very bizarre results. There does appear to be some sort of logic
> to it though, if you look at the graph chart, you can see that It seems
> to be doing the clustering right and then forgetting to remove the old
> groupings providing this "cloning" effect for some cluster groups.
I'm sorry I can't infer the intended algorithm from the code you provide.
Perhaps you can give a short description in plain English?
However, here's the implementation of the algorithm you mention as described
on wikipedia:
http://en.wikipedia.org/wiki/Cluster_analysis#Agglomerative_hierarchical_clustering
Repeatedly merge the two closest clusters until there's only one left.
To keep track of the two merged clusters I've added a "children" key to your
node dictionaries. The intermediate states of the tree are also put into the
levels variable (I suppose that's the purpose of your levels attribute).
The main difference to your code is that
(1) list modifications occur only in the outer while loop, so both inner
loops can become for-loops again.
(2) test all pairs before choosing the pair
debug = True
def cluster(self):
'''Run the clustering operation on the files
'''
clusters = []
#add a cluster for each track to clusters
for song in self.music:
clusters.append({'data' : [song]})
levels = []
while len(clusters) > 1:
# calculate weights
for c in clusters:
c["weight"] = self.__getClusterWeight(c['data'])
# find closest pair
closestDelta = float('inf')
closestPair = None
for i, a in enumerate(clusters):
for k, b in enumerate(clusters):
if i == k:
break
delta = abs(a['weight'] - b['weight'])
if delta < closestDelta:
closestPair = i, k
closestDelta = delta
# merge closest pair
hi, lo = closestPair
left = clusters[lo]
right = clusters.pop(hi)
clusters[lo] = {"data": left["data"] + right["data"],
"children": [left, right]}
# keep track of the intermediate tree states
levels.append(list(clusters))
if self.debug:
print ("stage %d" % len(levels)).center(40, "-")
for c in clusters:
print c["data"]
# store tree
self.clusters = clusters
self.levels = levels
Note that there's some potential for optimisation. For example, you could
move the weight calculation out of the while-loop and just calculate the
weight for the newly merged node.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Syntax help
sl33k_ wrote: How to read syntax like this given in the documentation of python? (Newbie) defparameter ::= parameter ["=" expression] http://docs.python.org/reference/compound_stmts.html#function-definitions Just in case you're about to learn python using these defintions: Nobody's learning a syntax that way. They are not meant to be understood by newcommers. They are accurate, non amiguous, exhaustive definition of the syntax. Some people familiar with working on grammars may effectively use it, but the majority of the people will prefer a fine explanation with examples (provided right after the grammar defintions). Unless you really need to work on some python parsing stuff, you can just ignore them. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert XML to SQL
Stefan Behnel, 26.01.2011 10:29:
Johann Spies, 26.01.2011 10:07:
I an not a Python newbie but working with xml is new to me.
I get data through a soap connection, using suds, and want to convert that
to objects which I can use to populate a rather complex database.
Your problem description is pretty comprehensive in general. It would be
helpful to see an example snippet of the XML that you parse.
[example received in private e-mail]
I have been able to parse the xml using
tree = etree.iterparse(infile,events=("start","end")) but it seems like a
lot of work to get that to sql-objects.
I have seen references to lxml.objectify and have created a object
containing the contents of a whole file using
tree = objectify.parse(fileobject)
That object contains for example the data of 605 records and I do not know
how to use it. I could not figure out from the lxml.objectify documentation
how to do it.
In the end I want to use data from about 54 fields of each records. I would
like to have a list of dictionaries as a result of the parsing. From there
it should not be too difficult to create sql.
I think iterparse() is a good way to deal with this, as is objectify.
iterparse() has the advantage that you can dispose of handled records, thus
keeping memory usage low (if that's an issue here).
Using objectify, you would usually do something like this:
tree = objectify.parse(fileobject)
root = tree.getroot()
for record in root.xml_record_tag:
title_name = record.title.text
It really just depends on what your XML looks like. In the above, I assumed
that each record hangs directly below the root tag and is called
"xml_record_tag". I also assumed that each record has a "title" tag with
text content.
The example you sent me is almost perfect for lxml.objectify. Basically,
you'd do something like this:
for record in root.REC:
refs = [ ref.text for ref in record.item.refs.ref ]
publisher = record.item.copyright.publisher.text
for issue in record.issue:
units = [ unit.text for unit in issue.units.unit ]
and so on. The same in ET:
for record in root.findall('REC'):
refs = [ ref.text for ref in record.findall('item/refs/ref') ]
publisher = record.findtext('item/copyright/publisher')
for issue in record.findall('issue'):
units = [ unit.text for unit in issue.findall('units/unit') ]
Not much harder either.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: python interpreter
On 01/-10/-28163 02:59 PM, nair rajiv wrote: Hi, I was exploring python. I wanted to know more about the python interpreter i.e the technical details of how it has been written. If I am directed to the code that also will be fine. The implementation of python data structures lists, tuples and dictionaries. If there exists any online documentation on the implementation aspects of python, please direct me to it. Rajiv Nair For sources: Go to www.Python.org, and click on the link on the left side called "Source Distribution" If yo do that in the 2.7.1 section you'll get a file called python-2.7.1.tar.bz2 Or you could click a little lower, and get the sources to 3.1.3 DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert XML to SQL
On 26 January 2011 12:51, Stefan Behnel wrote: > > The example you sent me is almost perfect for lxml.objectify. Basically, > you'd do something like this: > > Thank you very much. You have helped me a lot. Regards Johann -- May grace and peace be yours in abundance through the full knowledge of God and of Jesus our Lord! His divine power has given us everything we need for life and godliness through the full knowledge of the one who called us by his own glory and excellence. 2 Pet. 1:2b,3a -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert XML to SQL
Johann Spies, 26.01.2011 13:22: On 26 January 2011 12:51, Stefan Behnel wrote: The example you sent me is almost perfect for lxml.objectify. Basically, you'd do something like this: Thank you very much. You have helped me a lot. You're welcome. If you have any suggestions how to improve the documentation of lxml.objectify, you can take the opportunity to give something back. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Syntax help
On 01/26/2011 04:05 AM, Jean-Michel Pichavant wrote: How to read syntax like this given in the documentation of python? (Newbie) defparameter ::= parameter ["=" expression] Just in case you're about to learn python using these defintions: Nobody's learning a syntax that way. They are not meant to be understood by newcommers. They are accurate, non amiguous, exhaustive definition of the syntax. I second Jen-Michel's suggestion -- it's like learning to drive by reading the Chilton's (mechanic's manual) and all your local/national laws on transportation. I suppose it's theoretically possible, but you likely want something geared at teaching, and only reach for this when you're in trouble :) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
>I don't know why you didn't say this before. Comprehention, Octavian. I've made that point multiple times, but your to stuck on talking about how selfish people are. >The other part of the discussion is related to the accessibility and care for >accessibility and that discussion is not nice at all, because it shows how >selfish are most of the people and they consider this a virtue. Selfish? We've had multiple people get interested, and I've had a couple of messages off-list about the accessibility, (probably so they wouldn't have to deal with you). We've even had one person ask for a list of screen readers, (and I note you only gave him the one -you- use for the OS -you- use). There's no selfishness, just your not knowing when to jump off the soapbox and stop parroting something just for the sake of complaining about it. It's been admitted that TKInter is not accessible, and discussion has even been made about fixing it. Yes, it will take a while, but nothing comes in over night. And getting WXPython to the point where it is usable in python 3, as has also been mentioned before by many people is going to take a lot of work, as well. On 1/25/2011 11:25 PM, Octavian Rasnita wrote: block quote From: "Emile van Sebille" block quote On 1/25/2011 3:33 PM rantingrick said... block quote Tkinter is old and in many ways insufficient for 21st century GUIs. We need to decide what should come next. I believe wxPython is our best hope. Wx may not be the best it can be, but it is the best we have at this time. block quote end Then you should immediately volunteer to bring wxPython to python3 compatibility -- as it is, it's not even close... Start thinking about upping your game from ranting to doing. Emile block quote end Hi Emile, block quote From my point of view this discussion is finished for the moment, because block quote end you are right, WxPython is not as fast developed as it needs, because Python 3 is not compatible with Python 2. If no solution is found for this big problem, then yes, WxPython can't be included in the Python distribution because there is nothing that can be included. I don't know why you didn't say this before. The other part of the discussion is related to the accessibility and care for accessibility and that discussion is not nice at all, because it shows how selfish are most of the people and they consider this a virtue. Octavian block quote end -- Thanks, Ty -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Littlefield, Tyler" > >I don't know why you didn't say this before. > Comprehention, Octavian. I've made that point multiple times, but your > to stuck on talking about how selfish people are. You didn't say that WxPython can't be used with Python 3. Have you said that? > >The other part of the discussion is related to the accessibility and > care for >accessibility and that discussion is not nice at all, because > it shows how > >selfish are most of the people and they consider this a virtue. > Selfish? We've had multiple people get interested, I am not interested if the people are getting interested. I am interested to have a solution right now, and at least for Python 2, a solution is already available. > and I've had a couple > of messages off-list about the accessibility, (probably so they wouldn't > have to deal with you). We've even had one person ask for a list of > screen readers, (and I note you only gave him the one you use for the OS For the majority of blind users it is less relevant if a GUI is accessible under Linux or Mac. I gave that example because a GUI should be first accessible with JAWS because it is the most used screen reader. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Littlefield, Tyler" > >I don't know why you didn't say this before. > Comprehention, Octavian. I've made that point multiple times, but your > to stuck on talking about how selfish people are. You didn't say that WxPython doesn't work on Python 3, so I don't know what you are talking about. > >The other part of the discussion is related to the accessibility and > care for >accessibility and that discussion is not nice at all, because > it shows > how > >selfish are most of the people and they consider this a virtue. > Selfish? We've had multiple people get interested, and I've had a couple > of messages off-list about the accessibility, (probably so they wouldn't > have > to deal with you). We've even had one person ask for a list of screen > readers, (and I note you only gave him the one -you- use for the OS > -you- use). There's > no selfishness, just your not knowing when to jump off the soapbox and I couldn't find the word soapbox in the dictionary so I don't know what it means. I guess that not the soap + box. Please be more clear and not talk like the high school kids. > stop parroting something just for the sake of complaining about it. It's > been admitted that TKInter is not accessible, And I was saying the same thing. What's the problem? Because I keep telling it? > and discussion has even > been made about fixing it. Yes, it will take a while, but nothing comes > in over night. And getting WXPython to the point where it is usable in > python 3, as has also been mentioned before by many people is going to > take a lot of work, as well. Do you think that this really matters? Do you think that if Python 3 will have support for WxPython much earlier than Tkinter will be accessible, and if WxPython will be fixed to not give segfaults, WxPython will be included in the Python distribution? I guess that it won't, so it is less important that WxPython has bugs or that it is not available for Python 3. But we'll see. I can assure you that if after 5 years WxPython will be available for Python 3 but Tk will still be inaccessible for the most used screen reader, Tkinter will still be the default GUI lib. (And 5 years doesn't mean overnight) Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/25/2011 5:07 PM rantingrick said... On Jan 25, 6:55 pm, Emile van Sebille wrote: Oh, that everyone should blindly accept you as is and without regard for established protocols What protocols? Where is this standard posted? Can you give me a link? I would like to know what is expected of me. Do your homework. Roughly as follows: Write a PEP. See http://www.python.org/dev/peps/pep-0001/ Petition to reopen the GUI SIG list (probably not a major hurdle) and beat out the details there. Submit the PEP and defend it. Submit a prototype implementation. Substantiate that the project will be long term supportable. And finally, get it accepted. Emile -- http://mail.python.org/mailman/listinfo/python-list
Is it possible to pass CSV Reader Object As Argument to another Python File ???
I have following two python scripts -namelookupWrapper.py -namelookup.py The namelookupWrapper.py takes input of "memberId", "memberName" from CLI and has following code snippet idf = sys.argv[1] namef = sys.argv[2] real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" r = csv.reader(sys.stdin) os.execv(python_executable, [ python_executable, real_script ] + sys.argv[1:] ) Wondering how would i pass csv reader object "r" as an argument using os.execv() to another python script i.e. namelookup.py -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
>with JAWS because it is the most used screen reader. Get off your me soapbox. Jaws is not the most used. NVDA is taking over, quite fast, and lots of people have totally switched to mac or Vinux because of the problems with Jaws. It's most used in corporate sektors still maybe, but lots of end-users are migrating to Window Eyes, NVDA or OSX because of the fact that it is both cheaper and NVDA is open source, not to mention free. Just because Jaws -was- most used and -you- use it, doesn't mean it still remains so. On 1/26/2011 8:26 AM, Octavian Rasnita wrote: From: "Littlefield, Tyler" I don't know why you didn't say this before. Comprehention, Octavian. I've made that point multiple times, but your to stuck on talking about how selfish people are. You didn't say that WxPython can't be used with Python 3. Have you said that? The other part of the discussion is related to the accessibility and care for>accessibility and that discussion is not nice at all, because it shows how selfish are most of the people and they consider this a virtue. Selfish? We've had multiple people get interested, I am not interested if the people are getting interested. I am interested to have a solution right now, and at least for Python 2, a solution is already available. and I've had a couple of messages off-list about the accessibility, (probably so they wouldn't have to deal with you). We've even had one person ask for a list of screen readers, (and I note you only gave him the one you use for the OS For the majority of blind users it is less relevant if a GUI is accessible under Linux or Mac. I gave that example because a GUI should be first accessible with JAWS because it is the most used screen reader. Octavian -- Thanks, Ty -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/25/2011 10:08 PM Octavian Rasnita said... From: "Emile van Sebille" Why is WxPython ineligible? I think Terry's point was compatibility with python3 -- which wx apparently isn't yet. Emile Well, I didn't know this, and it is a valid reason. This means that it is true that there is no enough maintainance force to keep WxPython updated. Did I understand correctly? Not at all -- wxPython is an active funded ongoing project. Review the roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly the final paragraph on Python3.x support. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 9:47 am, "Octavian Rasnita" wrote: > I couldn't find the word soapbox in the dictionary so I don't know what it > means. I guess that not the soap + box. > Please be more clear and not talk like the high school kids. http://en.wikipedia.org/wiki/Soapbox -- http://mail.python.org/mailman/listinfo/python-list
Bugs/issues in tkinter.simpledialog!!
I just installed Python 3,0 on my machine. I cannot use 3.0 exclusively yet however i was interested in just poking around and acquiring a taste if you will. I was happy to find that the new Tkinter module names now follow convention and are placed correctly... example: "tkinter.simpledialog" However some things never change it seems and some improvements are actually a step backwards. The same problems with the unit test in 2.x got ported to 3.x. And the new SimpleDialog is just more lackluster code like we've seen before. I was hoping to be amazed, i am disappointed and disgusted. It is obvious that whoever is writing/ maintaining the tkinter code base does NOT understand tkinter completely and this is blinding apparent by reading the source code! --- Issues --- First lets start with the problems that migrated from 2.x... (tkinter.simpledialog) #-- ISSUE 1 --# In the test() function we still have code that uses the "quit" method instead of "destroy". Calling the "quit" method only tells Tkinter to stop processing events, IT DOES NOT DESTROY THE WIDGET!! And on windows the the root will then become unresponsive -- you cannot close the window, you cannot do anything. I have said time and time again. DO NOT USE THE QUIT METHOD UNLESS YOU KNOW WHAT THE HECK YOU ARE DOING! So the code needs to be this... OLD: q = Button(root, text='Quit', command=t.quit) NEW: q = Button(root, text='Quit', command=root.destroy) #-- ISSUE 2: --# The author used a very strange method by which to denote the default button in the SimpleDialog class. He choose to set the relief to RIDGE and the border "8". This not only looks horrible (and exposes the authors ignorance of tkinter) but a much more elegant solution is provided by the TclTk folks. All buttons have a "default" option that will display the button with a nice border so the user can visually see which button is active. So the code should be this OLD: if num == default: b.config(relief=RIDGE, borderwidth=8) NEW: if num == default: b.config(default=ACTIVE) Last but not least i am puzzled as to why we choose the method name "go" over "show". for "showing" the dialog. SimpleDialog uses no inheritance so name clashes are mum. Why would anyone choose "go" over "show" for a modal dialog? I would really like an explanation for this. Other minor issues exists. I may describe them later. At this time we need to fix these grave abominations first. -- http://mail.python.org/mailman/listinfo/python-list
Re: adding "Print" menu in wxPython
On Jan 26, 12:54 am, rantingrick wrote:
> On Jan 26, 12:19 am, rantingrick wrote:
>
> Actually i found more cruft. Here is something that would be
> acceptable although i had to wrap lines shorter than i normally would
> for the sake of Usenet. Who ever wrote that code should be lashed 50
> times! You still need some error handling for the open and save file
> methods but crikey i can't do everything ;-)
>
> #--STARTCODE--#
> import wx
> import os.path, sys
>
> class MainWindow(wx.Frame):
> def __init__(self, filename='noname.txt'):
> wx.Frame.__init__(self, None, size=(400,200))
> self.filename = filename
> self.dirname = '.'
> self.control = wx.TextCtrl(self, style=wx.TE_MULTILINE)
> self.CreateMenu()
> self.CreateStatusBar()
> self.SetTitle('Editor %s'%self.filename)
> self.dlgdefaults = {
> 'message':'Choose a file',
> 'defaultDir':self.dirname,
> 'wildcard':'*.*'
> }
>
> def CreateMenu(self):
> fileMenu = wx.Menu()
> item = fileMenu.Append(wx.ID_ABOUT, '&About', 'Info')
> self.Bind(wx.EVT_MENU, self.OnAbout, item)
> item = fileMenu.Append( wx.ID_OPEN, '&Open', 'Info')
> self.Bind(wx.EVT_MENU, self.OnOpen, item)
> item = fileMenu.Append(wx.ID_SAVE, '&Save', 'Info')
> self.Bind(wx.EVT_MENU, self.OnSave, item)
> item = fileMenu.Append(wx.ID_SAVEAS, 'Save &As', 'Info')
> self.Bind(wx.EVT_MENU, self.OnSaveAs, item)
> #
> # psst: Hey put the print menu here
> # psst: do the binding here
> #
> fileMenu.AppendSeparator()
> item = fileMenu.Append(wx.ID_EXIT, 'E&xit', 'Exit')
> self.Bind(wx.EVT_MENU, self.OnExit, item)
> menuBar = wx.MenuBar()
> # Add the fileMenu to the MenuBar
> menuBar.Append(fileMenu, '&File')
> # Add the menuBar to the Frame
> self.SetMenuBar(menuBar)
>
> def askUserForFilename(self, **kw):
> dialog = wx.FileDialog(self, **kw)
> if dialog.ShowModal() == wx.ID_OK:
> userProvidedFilename = True
> self.filename = dialog.GetFilename()
> self.dirname = dialog.GetDirectory()
> self.SetTitle('Editor %s'%(self.filename))
> else:
> userProvidedFilename = False
> dialog.Destroy()
> return userProvidedFilename
>
> def OnAbout(self, event):
> dialog = wx.MessageDialog(
> self,
> 'A sample editor in wxPython',
> 'About Sample Editor',
> wx.OK
> )
> dialog.ShowModal()
> dialog.Destroy()
>
> def OnExit(self, event):
> self.Close()
>
> def OnSave(self, event):
> textfile = open(os.path.join(self.dirname, self.filename),
> 'w')
> textfile.write(self.control.GetValue())
> textfile.close()
>
> def OnOpen(self, event):
> if self.askUserForFilename(
> style=wx.OPEN,
> **self.dlgdefaults
> ):
> textfile = open(os.path.join(self.dirname, self.filename),
> 'r')
> self.control.SetValue(textfile.read())
> textfile.close()
>
> def OnSaveAs(self, event):
> if self.askUserForFilename(
> defaultFile=self.filename,
> style=wx.SAVE,
> **self.dlgdefaults
> ):
> self.OnSave(event)
>
> def OnPrint(self, event):
> sys.stdout.write(self.control.GetValue())
>
> app = wx.App()
> frame = MainWindow()
> frame.Show()
> app.MainLoop()
>
> #--ENDCODE--#
I really appreciate your cooperation. The codes you have written print
in command window, but I want to print (i.e. a popup window will
appear to select printer in order to print). Please assist me
regarding this. I am optimist that I can take care menu creating,
binding, error handling by myself. Therefore you can only show me the
"OnPrint" function to fulfill my purpose.
-- Akand
--
http://mail.python.org/mailman/listinfo/python-list
Is it possible to pass CSV Reader Object As Argument to another Python File ??? Options
I have following two python scripts -namelookupWrapper.py -namelookup.py The namelookupWrapper.py takes input of "memberId", "memberName" from CLI and has following code snippet idf = sys.argv[1] namef = sys.argv[2] real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" r = csv.reader(sys.stdin) os.execv(python_executable, [ python_executable, real_script ] + sys.argv[1:] ) Wondering how would i pass csv reader object "r" as an argument using os.execv() to another python script i.e. namelookup.py Regards, Bansi - Bansilal Haudakari SUN Certified Enterprise JAVA Architect / Programmer http://bansihaudakari.wordpress.com/ L:703-445-2894 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to pass CSV Reader Object As Argument to another Python File ???
On 1/26/2011 7:51 AM bansi said... I have following two python scripts -namelookupWrapper.py -namelookup.py The namelookupWrapper.py takes input of "memberId", "memberName" from CLI and has following code snippet idf = sys.argv[1] namef = sys.argv[2] real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" r = csv.reader(sys.stdin) os.execv(python_executable, [ python_executable, real_script ] + sys.argv[1:] ) Wondering how would i pass csv reader object "r" as an argument using os.execv() to another python script i.e. namelookup.py I suspect you're on the wrong path. You probably want to import namelookup within namelooupWrapper to use the functions it defines. Consider: [root@fcfw2 src]# cat > test1.py def say(what): print what [root@fcfw2 src]# cat > test2.py #!/usr/local/bin/python import sys from test1 import say say(sys.argv[1]) [root@fcfw2 src]# chmod a+x test2.py [root@fcfw2 src]# ./test2.py hello hello HTH, Emile -- http://mail.python.org/mailman/listinfo/python-list
open() mode args
What is the correct file mode to pass to open() when I want to both read and write on the open file? -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/26/11 10:00 AM, Emile van Sebille wrote: On 1/25/2011 10:08 PM Octavian Rasnita said... From: "Emile van Sebille" Why is WxPython ineligible? I think Terry's point was compatibility with python3 -- which wx apparently isn't yet. Emile Well, I didn't know this, and it is a valid reason. This means that it is true that there is no enough maintainance force to keep WxPython updated. Did I understand correctly? Not at all -- wxPython is an active funded ongoing project. Review the roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly the final paragraph on Python3.x support. That's not Terry's point. The reasons he's referring to (and stated previously) are as follows: 1. The license of wxWidgets and wxPython is not as permissive as Python's. The Python developers, as a matter of policy, do not want to include code into the standard library that is less permissive than the current license. 2. The Python developers require someone to commit to maintaining contributed code for a number of years. No one has done so. See reason #3. 3. The wxPython developers do not want wxPython in the standard library, not least because they want to develop and release wxPython at a different pace and release cycle than the standard library. 4. The Python developers have committed to maintaining backwards compatibility in the standard library for a very long time. Even if they included wxPython into the standard library, they would have to provide a Tkinter module that works like the current one. I do not believe it is feasible to write a Tkinter workalike that uses wxPython, so we would still be relying on Tcl/Tk. There is certainly enough maintenance force to keep wxPython updated and ported to Python 3, but only *outside* of the standard library. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On 1/26/2011 8:00 AM rantingrick said... I just installed Python 3,0 on my machine. Try it again on the current release candidate -- http://www.python.org/download/releases/3.2/ -- testing old first release code and reporting on its problems won't get any traction. Verify the problem continues to exist in the current maintained version and then ask. If you get confirmation that the behavior is likely a bug, file a bug report so those who can and do can do (or at least consider). See http://docs.python.org/bugs.html http://www.python.org/dev/peps/pep-0003/ Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 22, 6:07 pm, rantingrick wrote: > --- > Challenge 1: (Simple Directory Viewer) > --- > > Create a simple Directory Viewer GUI. You CANNOT use a treectrl! The > point of this challenge is to show that Tkinter has no support for a > true ListCtrl widget. However the Wx::ListCtrl is fully featured! For > wxPython the code is simply wielding a few built in classes. For > Tkinter no such ListCtrl functionality exists. You CAN create the > functionality yourself (and i know this because i HAVE created it!) > however it involves tons of work and still can't hold a candle to the > wx::ListCtrl > > --- > Requirements: > --- > > How the user navigates to a folder is not important but you must > display the list of files/folders in two view modes with icons; > > 1. Display files in both ReportView and ListView. > > * Reportview: > ...scrollable vertical list with three columns. > > * Listview: > ...scrollable horizontal-ly wrapping list. > > Note: If you do not understand the view modes just run my code for an > example. But the user must be able to switch between these two modes > easily. How the switching is done is unimportant -- I simply used two > buttons. > > 2. Columns > * Minimum of three cols; Name, Size, and Type (reportview). > * the "Name" column must include an icon AND label (both views). > * columns must be sortable by the user (reportview). > * columns must be sizable by the user (reportview). > > 3. Items > * All must be editable in place (no popup editing allowed!). > * All items must be selectable/deselectable by user. > * All items must be delete-able by the user. > > That is the challenge. Step forth and battle if you can! > > - > WxPython code: > - > > https://sites.google.com/site/thefutureofpython/home/code-challenges > > I await any challengers... So we have come this far and still not one challenger. Neither can one person admit that the wxPython ListCtrl is far superior than widget TclTk contains. But that really does not matter now. The point is that TclTk have grown stagnate and have been that way for many years. Whilst Tkinter does sport a beautiful API we have no way to scale the module because TclTk is limited. New Python programmers will start out (like i did) with Tkinter and love its simplicity, however eventually they will come to understand that all their spend energy writing Tkinter has been for nothing. They will realize that Tkinter is 1990's technology migrated into the 21st century. That is point i am making. Some people can handle the truth. Denial is to be expected. If you are out there and your not one of the redundant trolls who keep parroting off and assassination my character please drop by and insert your opinion on the value of Tkinter. Just make sure to use facts and not emotion driven drivel. If you choose to be a troll i cannot stop you, and i would not. However i will not respond to trollish posts anymore. It is quite clear that a hand full of the same old folks want to stop me at all costs -- even at the expense of their own soul. Psst: If you notice they are not yelling about the code anymore because it is bug free. They are only interested in spreading discontent and not solving problems. That is a blindingly apparent fact. Anyway i still await a solid challenge. Either in code or in words based on facts. Until then i will consider myself victorious by default. -- http://mail.python.org/mailman/listinfo/python-list
Re: open() mode args
On Wed, 26 Jan 2011 11:32:03 -0500, mpnordland wrote:
> What is the correct file mode to pass to open() when I want to both read
> and write on the open file?
open("filename", "r+") for text mode, "r+b" for binary mode. If your
operating system does not distinguish between the two, you can use either.
More detail is available in the Fine Manual, or in the interactive help:
help(open)
at the Python prompt.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On Jan 26, 10:43 am, Emile van Sebille wrote: > On 1/26/2011 8:00 AM rantingrick said... > > I just installed Python 3,0 on my machine. > > Try it again on the current release candidate > --http://www.python.org/download/releases/3.2/-- testing old first > > Seehttp://docs.python.org/bugs.htmlhttp://www.python.org/dev/peps/pep-0003/ Why would i want to waste bandwidth downloading an RC? Can i not just browse the source online? I only need to check one module. Where is the source available for viewing "simpledialog" online? Thanks PS: The version i have now is 3.1.1 (but i would like to see the newest version available, just not download it!) -- http://mail.python.org/mailman/listinfo/python-list
method-to-instance binding, callable generator decorator
Am struggling to understand Python method-to-instance binding Anyone know why this example throws a TypeError? > #!/usr/bin/env python > > import functools > > # Take a generator function (i.e. a callable which returns a generator) and > # return a callable which calls .send() > class coroutine: > def __init__(self, function): > self.function = function > > functools.update_wrapper(self, function) > > def __call__(self, *args, **kwds): > try: > return self.generator.send(args) > > except AttributeError: > self.generator = self.function(*args, **kwds) > > return self.generator.next() > > # Each time we're called, advance to next yield > @coroutine > def test(): > yield 'call me once' > yield 'call me twice' > > # Works like a charm : ) > assert 'call me once' == test() > assert 'call me twice' == test() > > class Test: > > # Each time we're called, advance to next yield > @coroutine > def test(self): > yield 'call me once' > yield 'call me twice' > > test = Test() > > # TypeError, WTF? > assert 'call me once' == test.test() > assert 'call me twice' == test.test() https://gist.github.com/797019 Am trying to write a decorator such that each time I call a function, it advances to the next "yield" - I plan to use functions like this as fixtures in tests Does a decorator like this already exist in the Python standard library? -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 2011, at 10:26 AM, Octavian Rasnita wrote: > You didn't say that WxPython can't be used with Python 3. Have you said that? Some besides Peter pointed this out a few days ago. >>> The other part of the discussion is related to the accessibility and >> care for >accessibility and that discussion is not nice at all, because >> it shows how >>> selfish are most of the people and they consider this a virtue. >> Selfish? We've had multiple people get interested, > > I am not interested if the people are getting interested. I am interested to > have a solution right now, and at least for Python 2, a solution is already > available. Python 2 is in bug-fix mode and no major modifications will be done to this version of Python. This means that Tkinter will not be replaced in Python 2. If you want a fix now, you either have to fix Tkinter in a backwards compatible way to work with Python 2, or you have to get wxPython (or some other GUI package) ready for Python 3. Cheers Tommy -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to pass CSV Reader Object As Argument to another Python File ???
On Jan 26, 11:30 am, Emile van Sebille wrote: > On 1/26/2011 7:51 AM bansi said... > > > > > > > I have following two python scripts > > -namelookupWrapper.py > > -namelookup.py > > > The namelookupWrapper.py takes input of "memberId", "memberName" from > > CLI and has following code snippet > > > idf = sys.argv[1] > > namef = sys.argv[2] > > real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" > > r = csv.reader(sys.stdin) > > os.execv(python_executable, [ python_executable, real_script ] + > > sys.argv[1:] ) > > > Wondering how would i pass csv reader object "r" as an argument using > > os.execv() to another python script i.e. namelookup.py > > I suspect you're on the wrong path. You probably want to import > namelookup within namelooupWrapper to use the functions it defines. > > Consider: > > [root@fcfw2 src]# cat > test1.py > > def say(what): print what > > [root@fcfw2 src]# cat > test2.py > > #!/usr/local/bin/python > import sys > from test1 import say > say(sys.argv[1]) > > [root@fcfw2 src]# chmod a+x test2.py > > [root@fcfw2 src]# ./test2.py hello > hello > > HTH, > > Emile- Hide quoted text - > > - Show quoted text - Emile, Thanks for quick response. I am not sure if "import namelookup within namelooupWrapper" helps because they are two independent scripts which has to be executed in sequence. First namelookupWrapper.py running under Python 2.6 accept arguments from stdin and uses csv reader object to read it i.e. r=csv.reader(sys.stdin) And then it has to pass csv reader object to another python script namelookup.py running under Python 2.7 because it uses pyodbc to connect to database and iterates thru reader object Any better ideas/suggestions will be greatly appreciated -- http://mail.python.org/mailman/listinfo/python-list
Slice lists and extended slicing
I'm looking at extended slicing and wondering when and how to use slice lists:
slicing ::= simple_slicing | extended_slicing
simple_slicing ::= primary "[" short_slice "]"
extended_slicing ::= primary "[" slice_list "]"
slice_list ::= slice_item ("," slice_item)* [","]
slice_item ::= expression | proper_slice | ellipsis
proper_slice ::= short_slice | long_slice
short_slice ::= [lower_bound] ":" [upper_bound]
long_slice ::= short_slice ":" [stride]
lower_bound ::= expression
upper_bound ::= expression
stride ::= expression
ellipsis
The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list
contains at least one comma, the key is a tuple containing the
conversion of the slice items; otherwise, the conversion of the lone
slice item is the key. The conversion of a slice item that is an
expression is that expression. The conversion of an ellipsis slice
item is the built-in Ellipsis object. The conversion of a proper slice
is a slice object (see section The standard type hierarchy) whose
start, stop and step attributes are the values of the expressions
given as lower bound, upper bound and stride, respectively,
substituting None for missing expressions.
I'd thought that I could do this:
>>> l = [1,2,3,4,5]
>>> l[0:1, 3:4]
Traceback (most recent call last):
File "", line 1, in
TypeError: list indices must be integers, not tuple
but that clearly doesn't work! So, when and how can one use slice lists?
--
Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
Re: open() mode args
thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: method-to-instance binding, callable generator decorator
On 1/26/2011 9:04 AM Jack Bates said... Am struggling to understand Python method-to-instance binding Anyone know why this example throws a TypeError? > #!/usr/bin/env python > > import functools > > # Take a generator function (i.e. a callable which returns a generator) and > # return a callable which calls .send() > class coroutine: > def __init__(self, function): > self.function = function > > functools.update_wrapper(self, function) > > def __call__(self, *args, **kwds): > try: > return self.generator.send(args) > > except AttributeError: > self.generator = self.function(*args, **kwds) > > return self.generator.next() > > # Each time we're called, advance to next yield > @coroutine > def test(): > yield 'call me once' > yield 'call me twice' define test > > # Works like a charm : ) > assert 'call me once' == test() > assert 'call me twice' == test() > > class Test: > > # Each time we're called, advance to next yield > @coroutine > def test(self): > yield 'call me once' > yield 'call me twice' > > test = Test() I'm not sure, but you've shadowed the test function above here. > > # TypeError, WTF? > assert 'call me once' == test.test() > assert 'call me twice' == test.test() https://gist.github.com/797019 Am trying to write a decorator such that each time I call a function, it advances to the next "yield" - I plan to use functions like this as fixtures in tests Does a decorator like this already exist in the Python standard library? -- http://mail.python.org/mailman/listinfo/python-list
Re: adding "Print" menu in wxPython
On Jan 26, 10:07 am, Akand Islam wrote: > I really appreciate your cooperation. The codes you have written print > in command window, but I want to print (i.e. a popup window will > appear to select printer in order to print). Please assist me > regarding this. Ok, read on... > I am optimist that I can take care menu creating, > binding, error handling by myself. Therefore you can only show me the > "OnPrint" function to fulfill my purpose. Yes but how can i be sure? You still failed to post code proving that you can do this. I don't mind helping folks and i will go out on a limb for anyone however i will not build the tree of knowledge for you. You must prove that you are at least making an attempt to learn. If i do all the work then you won't learn anything. Heck, i even cleaned up the horrible code and put comments exactly where you need to create the menu. I could not have made this challenge any easier. So show me some proof that you are trying then we will move on to next step. You must attack problems step by step. -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Robert Kern" > That's not Terry's point. The reasons he's referring to (and stated > previously) > are as follows: > > 1. The license of wxWidgets and wxPython is not as permissive as Python's. > The > Python developers, as a matter of policy, do not want to include code into > the > standard library that is less permissive than the current license. This is the worst and... sorry for the word, but real stupid thing. I mean, I don't consider a correct thinking to care more about the permissiveness of a licence which is anyway open source, more than about the accessibility. Try to think that for some people Tkinter displays just a black filled rectangle. In that case would you still think that it is "correct" to keep that kind of GUI because of some differences between open source licences? > 2. The Python developers require someone to commit to maintaining contributed > code for a number of years. No one has done so. See reason #3. In that case I understand that there are enough WxPython developers, well funded, but there is no commitment from them. >From Python's perspective, there are not enough maintainers that can offer >that commitment and yes, this is a real reason why the core Python developers >can't include WxPython. > 3. The wxPython developers do not want wxPython in the standard library, not > least because they want to develop and release wxPython at a different pace > and > release cycle than the standard library. >From the message of a list member which (but maybe I am wrong) appear to be a >WxPython developer, I suspected that the WxPython developers might not want >their work to be included in the Python distribution. I am not really sure about this because I haven't seen any message from a WxPython developer telling that yes, I am a WxPython developer and we don't want to allow including WxPython in the Python distro, and I almost don't believe that, but if it is true, I don't know why they didn't said that, because WxPython is their work and of course that if they don't accept to maintain a WxPython as apart of Python distribution, then this discussion doesn't have any meaning. I have only heard that WxPython will never be included, but without beeing more clear. Who knows, maybe some of those who said that are WxPython developers but for me they are just some names because I don't know them... The next (or previous) points are not important anymore if the WxPython developers don't want their work to be included in the Python distribution. So, is it true? That was the cause for which WxPython can't be promoted by Python? Because the WxPython developers don't want this? If the answer is yes, then too bad, because as I said, it's their work and they can do whatever they like with it. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Slice lists and extended slicing
On Wed, Jan 26, 2011 at 12:20 PM, Gerald Britton
wrote:
> I'm looking at extended slicing and wondering when and how to use slice lists:
>
> slicing ::= simple_slicing | extended_slicing
> simple_slicing ::= primary "[" short_slice "]"
> extended_slicing ::= primary "[" slice_list "]"
> slice_list ::= slice_item ("," slice_item)* [","]
> slice_item ::= expression | proper_slice | ellipsis
> proper_slice ::= short_slice | long_slice
> short_slice ::= [lower_bound] ":" [upper_bound]
> long_slice ::= short_slice ":" [stride]
> lower_bound ::= expression
> upper_bound ::= expression
> stride ::= expression
> ellipsis
>
> The semantics for an extended slicing are as follows. The primary must
> evaluate to a mapping object, and it is indexed with a key that is
> constructed from the slice list, as follows. If the slice list
> contains at least one comma, the key is a tuple containing the
> conversion of the slice items; otherwise, the conversion of the lone
> slice item is the key. The conversion of a slice item that is an
> expression is that expression. The conversion of an ellipsis slice
> item is the built-in Ellipsis object. The conversion of a proper slice
> is a slice object (see section The standard type hierarchy) whose
> start, stop and step attributes are the values of the expressions
> given as lower bound, upper bound and stride, respectively,
> substituting None for missing expressions.
>
> I'd thought that I could do this:
>
l = [1,2,3,4,5]
l[0:1, 3:4]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: list indices must be integers, not tuple
>
> but that clearly doesn't work! So, when and how can one use slice lists?
>
> --
> Gerald Britton
If you're trying to learn a language, I would suggest reading
tutorials, not the grammar. As you can see from the error thrown, the
operation is syntactically valid (you don't get a syntax error). It's
just that lists don't accept them. I don't know of any built-in data
type that takes slice lists but numpy matrices will.
>>> a = numpy.matrix([[1,2,3],[4,5,6],[7,8,9]])
matrix([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]])
>>> a[0:2,1:3]
matrix([[2, 3],
[5, 6]])
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Emile van Sebille" ... >> Well, I didn't know this, and it is a valid reason. >> This means that it is true that there is no enough maintainance force to >> keep WxPython updated. >> Did I understand correctly? > > Not at all -- wxPython is an active funded ongoing project. Review the > roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly > the final paragraph on Python3.x support. > > Emile But somebody said that the core Python developers, or Guido said that WxPython won't be included in the core distribution because it doesn't have a strong team of maintainers... with other words but this was the idea. So I still don't understand why WxPython can't be a good solution. If WxPython is well maintained, let's pretend that the maintainers solved that bug that make the apps give a segfault, and let's pretend that it works under Python 3. Can it be a good choice for replacing Tkinter? I don't know why, but I have a feeling that even in these cases WxPython is still not wanted and I don't understand why. I can see that the people try to find some false arguments like the one that WxPython is bigger than Tkinter, but really, who cares today about a few aditional megabytes? What do you think it is more important, to offer accessibility for most of the users, or to create small applications? (Note that I didn't say that Tkinter should be forbidden, so if somebody in some edge cases need to make a very small program, he/she could do it very well.) So I still don't understand why WxPython wouldn't be prefered even all its problems would be solved. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On Wed, Jan 26, 2011 at 11:53 AM, rantingrick wrote: > On Jan 26, 10:43 am, Emile van Sebille wrote: >> On 1/26/2011 8:00 AM rantingrick said... > >> > I just installed Python 3,0 on my machine. >> >> Try it again on the current release candidate >> --http://www.python.org/download/releases/3.2/-- testing old first >> >> Seehttp://docs.python.org/bugs.htmlhttp://www.python.org/dev/peps/pep-0003/ > > Why would i want to waste bandwidth downloading an RC? Can i not just > browse the source online? I only need to check one module. Where is > the source available for viewing "simpledialog" online? > > Thanks > > PS: The version i have now is 3.1.1 (but i would like to see the > newest version available, just not download it!) The code is hosted on http://svn.python.org If you just one that one file, it's at http://svn.python.org/view/python/trunk/Lib/lib-tk/tkSimpleDialog.py?view=markup > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: method-to-instance binding, callable generator decorator
Jack Bates wrote: Am struggling to understand Python method-to-instance binding Anyone know why this example throws a TypeError? #!/usr/bin/env python import functools # Take a generator function (i.e. a callable which returns a generator) and # return a callable which calls .send() class coroutine: def __init__(self, function): self.function = function functools.update_wrapper(self, function) def __call__(self, *args, **kwds): try: return self.generator.send(args) except AttributeError: self.generator = self.function(*args, **kwds) return self.generator.next() # Each time we're called, advance to next yield @coroutine def test(): yield 'call me once' yield 'call me twice' # Works like a charm : ) assert 'call me once' == test() assert 'call me twice' == test() class Test: # Each time we're called, advance to next yield @coroutine def test(self): yield 'call me once' yield 'call me twice' test = Test() # TypeError, WTF? assert 'call me once' == test.test() assert 'call me twice' == test.test() https://gist.github.com/797019 Am trying to write a decorator such that each time I call a function, it advances to the next "yield" - I plan to use functions like this as fixtures in tests Does a decorator like this already exist in the Python standard library? At the time you set the self.function attribute, its value is an unbound method, and thus must be called with the instance as first attribute. Since "self.generator = self.function(*args, **kwds)" doesn't pass the self arguement as 1st parameter, you have to do it yourself. replace your last 2 lines by assert 'call me once' == test.test(test) assert 'call me twice' == test.test(test) One alternative is to decorate, once the instance is created, ie. the method is bound to the instance and does not require to pass the instance as 1st argument: class Test2: def test2(self): yield 'call me once' yield 'call me twice' test2 = Test2() test2.test2 = coroutine(test2.test2) assert 'call me once' == test2.test2() assert 'call me twice' == test2.test2() I'm not sure it's a standard way to proceed though, it looks rather strange. I'm not familiar with decorators, but my guess is that one decorator cannot (except through the above tricks) decorate functions AND unbound methods. In order to make your original coroutine decorator work with unbound methods, and only unbound methods, change self.generator = self.function(*args, **kwds) into self.generator = self.function(self, *args, **kwds) Hope it helps, JM -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Tommy Grav" >> You didn't say that WxPython can't be used with Python 3. Have you said that? > > Some besides Peter pointed this out a few days ago. I don't remember to have read that. But who knows, maybe I have missed it. Does anyone have that message? > Python 2 is in bug-fix mode and no major modifications will be done to this > version of Python. This means that Tkinter will not be replaced in Python 2. Of course. That's why I said that this is a real problem and that I understand the real reason why WxPython can't be included in the Python distribution. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "Littlefield, Tyler" > >with JAWS because it is the most used screen reader. > Get off your me soapbox. Jaws is not the most used. NVDA is taking over, > quite fast, and lots of people have totally switched to mac or Vinux Lots of people means an insignifiant percent of users compared with the percent of Windows users. NVDA is mostly used as a second screen reader in case that something wrong happends with the first one. It doesn't support a good voice synthesizer like Eloquence or IBM Via voice, but only eSpeak which sounds horrible, it doesn't have a scripting language ready to use as JAWS and Window Eyes do, it doesn't offer the possibility of reading with the mouse cursor as JAWS does with its so called JAWS cursor, it offers a poor accessibility in many applications and many other issues. > because of the problems with Jaws. It's most used in corporate sektors > still maybe, but lots of end-users are migrating to Window Eyes, NVDA or > OSX because of the fact that it is both cheaper and NVDA is open source, > not to mention free. Just because Jaws -was- most used and -you- use it, > doesn't mean it still remains so. Window Eyes always was cheaper than JAWS, however it was never the most used screen reader because it also have its problems. I don't understand why you care so much about what will *probably* happen in the future and don't care about the present. An indian saying says that on the long term will be everything fine (because we will be all dead:) But you are talking just to show how right you are. If you remember about our discussion, we were talking about how inaccessible is Tkinter, and well Tkinter has the same inaccessibility level under Window Eyes and NVDA just like under JAWS, so I don't know why is it so important to name all those screen readers if someone wants to test Tkinter. I thought that if someone wants to test how inaccessible is Tkinter, JAWS would be enough because Tkinter is also inaccessible for the other screen readers, and I thought that it would be normally to test the accessibility using the screen reader that offer the most features. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Slice lists and extended slicing
On 1/26/11 11:20 AM, Gerald Britton wrote:
I'm looking at extended slicing and wondering when and how to use slice lists:
slicing ::= simple_slicing | extended_slicing
simple_slicing ::= primary "[" short_slice "]"
extended_slicing ::= primary "[" slice_list "]"
slice_list ::= slice_item ("," slice_item)* [","]
slice_item ::= expression | proper_slice | ellipsis
proper_slice ::= short_slice | long_slice
short_slice ::= [lower_bound] ":" [upper_bound]
long_slice ::= short_slice ":" [stride]
lower_bound ::= expression
upper_bound ::= expression
stride ::= expression
ellipsis
The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list
contains at least one comma, the key is a tuple containing the
conversion of the slice items; otherwise, the conversion of the lone
slice item is the key. The conversion of a slice item that is an
expression is that expression. The conversion of an ellipsis slice
item is the built-in Ellipsis object. The conversion of a proper slice
is a slice object (see section The standard type hierarchy) whose
start, stop and step attributes are the values of the expressions
given as lower bound, upper bound and stride, respectively,
substituting None for missing expressions.
I'd thought that I could do this:
l = [1,2,3,4,5]
l[0:1, 3:4]
Traceback (most recent call last):
File "", line 1, in
TypeError: list indices must be integers, not tuple
but that clearly doesn't work! So, when and how can one use slice lists?
The object just needs to implement its __getitem__(self, key) method
appropriately. list objects have an implementation that only processes integer
indices and slices.
The original semantics that motivated this syntax feature is not to take several
slices from a sequence and concatenate them together. Rather, it was to support
multidimensional slices for numpy arrays (or rather, numpy's predecessor Numeric).
[~]
|1> from numpy import arange
[~]
|2> A = arange(20).reshape([4,5])
[~]
|3> A
array([[ 0, 1, 2, 3, 4],
[ 5, 6, 7, 8, 9],
[10, 11, 12, 13, 14],
[15, 16, 17, 18, 19]])
[~]
|4> A[1:3, 2:4]
array([[ 7, 8],
[12, 13]])
list objects could be written to interpret a tuple of slices any way it wants
to, including the semantics you seem to have expected. I would suggest, though,
that the need for those semantics isn't common enough to warrant the syntactic
sugar.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Slice lists and extended slicing
On Wed, Jan 26, 2011 at 9:20 AM, Gerald Britton
wrote:
> I'm looking at extended slicing and wondering when and how to use slice lists:
>
> slicing ::= simple_slicing | extended_slicing
> simple_slicing ::= primary "[" short_slice "]"
> extended_slicing ::= primary "[" slice_list "]"
> slice_list ::= slice_item ("," slice_item)* [","]
> slice_item ::= expression | proper_slice | ellipsis
> proper_slice ::= short_slice | long_slice
> short_slice ::= [lower_bound] ":" [upper_bound]
> long_slice ::= short_slice ":" [stride]
> lower_bound ::= expression
> upper_bound ::= expression
> stride ::= expression
> ellipsis
>
> The semantics for an extended slicing are as follows. The primary must
> evaluate to a mapping object, and it is indexed with a key that is
> constructed from the slice list, as follows. If the slice list
> contains at least one comma, the key is a tuple containing the
> conversion of the slice items; otherwise, the conversion of the lone
> slice item is the key. The conversion of a slice item that is an
> expression is that expression. The conversion of an ellipsis slice
> item is the built-in Ellipsis object. The conversion of a proper slice
> is a slice object (see section The standard type hierarchy) whose
> start, stop and step attributes are the values of the expressions
> given as lower bound, upper bound and stride, respectively,
> substituting None for missing expressions.
>
> I'd thought that I could do this:
>
l = [1,2,3,4,5]
l[0:1, 3:4]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: list indices must be integers, not tuple
>
> but that clearly doesn't work! So, when and how can one use slice lists?
When the object you're slicing supports it, which is rarely. None of
the built-in types support multiple proper_slices like your example; I
know of no std lib classes that do either. However, the 3rd party
matrix library NumPy very well might.
Normally, one would instead write your example as:l[0:1] + l[3:4]
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 10:35 am, Robert Kern wrote: > On 1/26/11 10:00 AM, Emile van Sebille wrote: > That's not Terry's point. The reasons he's referring to (and stated > previously) > are as follows: > > 1. The license of wxWidgets and wxPython is not as permissive as Python's. The > Python developers, as a matter of policy, do not want to include code into the > standard library that is less permissive than the current license. This is actually a weak argument and i'll explain why. GUI libraries are very complicated and time consuming projects. Just think of all the work involved just to get a library working on one platform... much less THREE or more platforms! And while i am a huge believer in 100% open source software you've got to understand why most libraries are restrictive for commercial usage or worse. Yes TclTk IS fully opensource and i applaud them for it! However like the old adage say: "You get what you pay for". > 2. The Python developers require someone to commit to maintaining contributed > code for a number of years. No one has done so. See reason #3. > > 3. The wxPython developers do not want wxPython in the standard library, not > least because they want to develop and release wxPython at a different pace > and > release cycle than the standard library. I have already shown why this does not matter. The current wxPython API is NOT good for Python. We DO NOT want segfaults and "C++ looking" code written by the users of a Python stdlib module. Robin has stated that there exists room for an abstraction layer on top of wxPython and he is correct. He has also stated that he wants to keep "his wxPython" as close to WxWidgets as possible. So be it! We will never want to include wxPython "proper" in the stdlib anyway because it is SO unpythonic!! No. All we have to do is create an abstraction API that calls wxPython until we can create OUR OWN wxPython from WxWidgets. Call it Wxpy if you like. > 4. The Python developers have committed to maintaining backwards compatibility > in the standard library for a very long time. Even if they included wxPython > into the standard library, they would have to provide a Tkinter module that > works like the current one. I do not believe it is feasible to write a Tkinter > workalike that uses wxPython, so we would still be relying on Tcl/Tk. Fine support Tkinter until Python4000 i don't care. But we must move forward. We must accept that Tkinter is already legacy and there is no moving forward now. We will support Tkinter for backwards compadibility however we will start to integrate a truly Pythonic WxPython abstraction API and include just the API module in the stdlib. Then we don't have to maintain a huge library, just a small module with a wxPython 3rd party dependency. Then at some point in the future when the stdlib is ripe, we can THEN include some form of wxWidgets, and dump Tkinter forever. At least then we would be moving towards something. Currently we are stagnate. > > There is certainly enough maintenance force to keep wxPython updated and > ported > to Python 3, but only *outside* of the standard library. So let wxPython due what wxPython does best. We will use them as long as we need until we can create a stdlib compliant wxPython ourselves. They would be fools not to work with us! Because eventually when no 3rd party download is needed, all their work would go into the bit bucket. I doubt Robin is that foolish. He seems like a smart fellow to me -- even though he refuses to comply with PEP8 :) SUMMARY: We create an abstraction API atop "Robin's WxPython". We include only the API in the stdlib at this time and we keep Tkinter in maintenance. Then over the next few years we start a fresh wxPython project that will be acceptable for the stdlib. Something that we can plug our API into. We steal as much from Robin as we can (or get him to cooperate). Then when the time is right, we dump Tkinter and integrate the new Wxpy module into the stdlib. Then we will be back on track. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On Wed, Jan 26, 2011 at 11:53 AM, rantingrick wrote: > Why would i want to waste bandwidth downloading an RC? Can i not just > browse the source online? If I understand what you're asking for, the answer is http://svn.python.org/view . If you're specifically looking for 3.2rc1, then I believe you could look at http://svn.python.org/view/python/tags/r32rc1/ > I only need to check one module. Where is > the source available for viewing "simpledialog" online? > Again, assuming you're looking for the 3.2rc1 code in particular: http://svn.python.org/view/python/tags/r32rc1/Lib/tkinter/simpledialog.py?view=markup -- Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Slice lists and extended slicing
On 1/26/2011 9:20 AM Gerald Britton said...
I'm looking at extended slicing and wondering when and how to use slice lists:
I think the use of the term slice_list below is simply as the content
between the encompassing brackets, eg in mylist[1:2:3] slice_list refers
to 1:2:3. So, you don't actually 'use' a slice_list - that's what the
passed in value is called.
So, here are some example of how slicing is used:
>>> a = range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> a[:3] # the first three
[0, 1, 2]
>>> a[-3:] # the last three
[7, 8, 9]
>>> a[3:-3] # start and stop
[3, 4, 5, 6]
>>> a[::2] # take every other
[0, 2, 4, 6, 8]
>>> a[::-2] # take every other from the end
[9, 7, 5, 3, 1]
>>> a[3:-3:2] # take every other within start stop
[3, 5]
>>> a[3:-3:-2] # I'm not sure exactly why I didn't get something here
[]
>>> a[-3:3:-2] # but apparently the polarity of stride within start
stop matters
[7, 5]
>>>
HTH
Emile
slicing ::= simple_slicing | extended_slicing
simple_slicing ::= primary "[" short_slice "]"
extended_slicing ::= primary "[" slice_list "]"
slice_list ::= slice_item ("," slice_item)* [","]
slice_item ::= expression | proper_slice | ellipsis
proper_slice ::= short_slice | long_slice
short_slice ::= [lower_bound] ":" [upper_bound]
long_slice ::= short_slice ":" [stride]
lower_bound ::= expression
upper_bound ::= expression
stride ::= expression
ellipsis
The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list
contains at least one comma, the key is a tuple containing the
conversion of the slice items; otherwise, the conversion of the lone
slice item is the key. The conversion of a slice item that is an
expression is that expression. The conversion of an ellipsis slice
item is the built-in Ellipsis object. The conversion of a proper slice
is a slice object (see section The standard type hierarchy) whose
start, stop and step attributes are the values of the expressions
given as lower bound, upper bound and stride, respectively,
substituting None for missing expressions.
I'd thought that I could do this:
l = [1,2,3,4,5]
l[0:1, 3:4]
Traceback (most recent call last):
File "", line 1, in
TypeError: list indices must be integers, not tuple
but that clearly doesn't work! So, when and how can one use slice lists?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Behaviour-based interface/protocol implementation?
> That's just what I'd like and I suppose can't be currently done with > current ABC, PyProtocols or zope.interface implementations, right? It can. With __instancecheck__ you can override isinstance. It is possible (for example) to write a subclass of abc.ABCMeta, which extends __instancecheck__ to use an _instancehook classmethod similarly to __subclasshook__. Then in your MyInterface class you can implement _instancehook to check for methods/signatures/whatever you want. Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Tue, Jan 25, 2011 at 11:10 PM, Octavian Rasnita wrote: > From: "geremy condra" >> >> There's a difference between what you say and how you say it. If a >> friend came up to you and said "give me $100 right now!", you probably >> wouldn't do it. If the same friend came up to you and said "I know >> this is a big thing to ask, but I really need $100 and I can't >> guarantee I'll be able to pay you back. Could you please help me?" I > > Are you even thinking that the second sentence is much harder to express? > Do you imagine that my knowledge of English is limited by the fact that it > is not my native language and it is a language not spoken by very many > people in my country? > I simply might not be able to express so nice as you like that I need 100 > bucks from you, but I might be able to just tell you that "need 100 dollars. > now". > I could argue much more nice and expressive if we were speaking Romanian and > not English. At least 40% of my coworkers do not speak English as their native language. Your problem is not the language. Your problem is your attitude. > But I don't condemn you for this, because many years ago when I was in > school I had the opinion that some foreign colleagues are a little stupid > just because they were not able to express very well the ideas which were > not very simple, and well, they were not stupid at all, but they didn't know > my language well enough and they probably would think the same thing about > me if we were speaking in Russian. I don't have that problem. >> don't know very many people who would refuse if they were able to >> help. The reason is simple: the first does not acknowledge the value >> of the person doing the favor, and the second does. > > Exactly what I said. They are doing the same mistake as I did 20 years ago. > By the way, can't you see any syntactic dissacords in my phrases? Haven't > you think that my English might not be as fluent to be able to express > everything I want to say very well? As I mentioned earlier, you'll find I don't have a lot of pity for you in this. >> More concretely, you have an opinion that not supporting accessibility >> is discrimination. Tyler has an opinion that not supporting >> accessibility is a bug. > > This is not always true. Not supporting accessibility when *it is not > possible* yes, it is a bug as you say, so we agree here. > But not supporting accessibility because the programmer *doesn't want this*, > it is not a bug, but discrimination. Don't you agree with this? > And if Python would have been able to support accessibility it would have > mean that it promotes discrimination because it promotes the wrong tool, but > it seems that Python 3 doesn't have an accessible GUI lib for the moment, so > no, it is not discrimination (but Emile told us that there is no support for > WxPython in Python 3 just today, so I didn't know this and I already > wondered why nobody told about this real problem). Keep in mind, I'm not saying this. This is a sketch of your point of view and Tyler's point of view. >> Are you going to demand that he change his >> opinion? Or are you going to ask that he consider yours? > > It seems that the discrimination should be something that should be > discussed if and when it should be applied, isn't it? > Well, I think that everyone should understand why the programs must be > accessible and why everybody should care about all the users of an > application and that it is not normal to not care. Ah! I think I see where you're going wrong. It *is* normal not to care- not just about this, but about any given special interest other than your own. You have to convince people to care, or they don't- and you're not convincing, just yelling. >>> Have I said something wrong? Did I use bad words? Or what was it wrong? >> >> I think it was uncivil. It was rude, unkind, and generally >> disagreeable. I lost respect for you, and by proxy, for your point of >> view. In other words, you lost support not because fewer people agree >> with your position, but because fewer people want to agree with you. > > You are also very unkind and rude when you say that the disabled that need > to use a screen reader should be a kind of second hand people that need to > beg for a little accessibility. I don't say this. Don't try to stuff me into a strawman argument. > When you create a program, why do you create a visual interface for it? Why > don't you create just an audio interface? I don't create a visual interface. I have never found it necessary for my line of work, and have little stake in this discussion besides that of advocating civility on this list. > You do this because otherwise you would not please those who can see. Why > shouldn't be something normal, and that *should be not be discussable at > all* to offer the same accessibility to everyone? You can discuss it. You just have to convince others that you're right, and you're not doing that well. I offered you some advice on ho
Re: Is it possible to pass CSV Reader Object As Argument to another Python File ???
On Wed, Jan 26, 2011 at 7:51 AM, bansi wrote: > I have following two python scripts > -namelookupWrapper.py > -namelookup.py > > > The namelookupWrapper.py takes input of "memberId", "memberName" from > CLI and has following code snippet > > idf = sys.argv[1] > namef = sys.argv[2] > real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" > r = csv.reader(sys.stdin) > os.execv(python_executable, [ python_executable, real_script ] + > sys.argv[1:] ) > > Wondering how would i pass csv reader object "r" as an argument using > os.execv() to another python script i.e. namelookup.py It's not possible to pass Python objects between processes in such a manner. Given that "independent" scripts can't directly take objects as input anyway, I doubt the two scripts are truly independent from each other. I would therefore concur with van Sebille that you should just rewrite them so that one script imports from the other rather than spawning the other. It should not be too hard to port the Python 2.6 script to Python 2.7 (or vice-versa if necessary). Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
> However some things never change it seems and some improvements are > actually a step backwards. The same problems with the unit test in 2.x > got ported to 3.x. And the new SimpleDialog is just more lackluster > code like we've seen before. I was hoping to be amazed, i am > disappointed and disgusted. It is obvious that whoever is writing/ > maintaining the tkinter code base does NOT understand tkinter > completely and this is blinding apparent by reading the source code! > --- > Issues > --- > > First lets start with the problems that migrated from 2.x... > (tkinter.simpledialog) > > #-- ISSUE 1 --# > In the test() function we still have code that uses the "quit" method > instead of "destroy". Calling the "quit" method only tells Tkinter to > stop processing events, IT DOES NOT DESTROY THE WIDGET!! And on > windows the the root will then become unresponsive -- you cannot close > the window, you cannot do anything. I have said time and time again. > DO NOT USE THE QUIT METHOD UNLESS YOU KNOW WHAT THE HECK YOU ARE > DOING! So the code needs to be this... > > OLD: > q = Button(root, text='Quit', command=t.quit) > > NEW: > q = Button(root, text='Quit', command=root.destroy) > > > #-- ISSUE 2: --# > The author used a very strange method by which to denote the default > button in the SimpleDialog class. He choose to set the relief to RIDGE > and the border "8". This not only looks horrible (and exposes the > authors ignorance of tkinter) but a much more elegant solution is > provided by the TclTk folks. All buttons have a "default" option that > will display the button with a nice border so the user can visually > see which button is active. So the code should be this > > OLD: >if num == default: >b.config(relief=RIDGE, borderwidth=8) > > NEW: >if num == default: >b.config(default=ACTIVE) > > > Last but not least i am puzzled as to why we choose the method name > "go" over "show". for "showing" the dialog. SimpleDialog uses no > inheritance so name clashes are mum. Why would anyone choose "go" over > "show" for a modal dialog? I would really like an explanation for > this. > > Sounds like you need to help by: Creating a bug report Attaching a patch Thanks for the help, Rick. Nick -- http://mail.python.org/mailman/listinfo/python-list
Question on Open Project
Dear Room, I am a python programmer, from India(New Delhi area), and was in Bangalore for long days. My specialization is Natural Language Processing, -Machine Learning(worked on Naive Bayes, SVM, HMM, CRF). I am looking for some open projects in Python-in Machine Learning/NLP area, preferably from India(as many a times personal interaction is helpful) which I can do from home. If anyone knows of any reliable link. Best, Subhabrata. -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/26/11 11:46 AM, Octavian Rasnita wrote: From: "Robert Kern" That's not Terry's point. The reasons he's referring to (and stated previously) are as follows: 1. The license of wxWidgets and wxPython is not as permissive as Python's. The Python developers, as a matter of policy, do not want to include code into the standard library that is less permissive than the current license. This is the worst and... sorry for the word, but real stupid thing. I mean, I don't consider a correct thinking to care more about the permissiveness of a licence which is anyway open source, more than about the accessibility. Being able to say that all of a project is available under the substantively the same license is really important. It's very hard to get people to use your software if some parts are under one license and other parts are under a substantively different one. You are free to decide what licenses you want to distribute software under; the PSF has that freedom as well. Try to think that for some people Tkinter displays just a black filled rectangle. In that case would you still think that it is "correct" to keep that kind of GUI because of some differences between open source licences? This is a reason for application developers to use wxPython, not for the Python developers to include wxPython in the standard library. The standard library neither claims nor aims to do everything. There are many things that Tkinter cannot do that wxPython can. None of those things are reasons to replace Tkinter with wxPython in the standard library. Not everything useful has to be in the standard library. Python has a vibrant ecosystem of third party packages. wxPython is probably the most widely used GUI toolkit in Python. It has not been harmed (and I would argue that it has been very much helped) by not being in the standard library. Nor has it been harmed by the presence of Tkinter in the standard library. If wxPython had been included in the Python standard library, it would not have been able to easily follow the advancements of the underlying wxWidgets toolkit, and it would be a much less strong GUI toolkit. 2. The Python developers require someone to commit to maintaining contributed code for a number of years. No one has done so. See reason #3. In that case I understand that there are enough WxPython developers, well funded, but there is no commitment from them. Correct, they have not committed to maintaining wxPython as part of the standard library (although they are committed to maintaining wxPython outside of it). They have not even suggested that wxPython should be part of the standard library. From Python's perspective, there are not enough maintainers that can offer that commitment and yes, this is a real reason why the core Python developers can't include WxPython. 3. The wxPython developers do not want wxPython in the standard library, not least because they want to develop and release wxPython at a different pace and release cycle than the standard library. From the message of a list member which (but maybe I am wrong) appear to be a WxPython developer, I suspected that the WxPython developers might not want their work to be included in the Python distribution. I am not really sure about this because I haven't seen any message from a WxPython developer telling that yes, I am a WxPython developer and we don't want to allow including WxPython in the Python distro, and I almost don't believe that, but if it is true, I don't know why they didn't said that, because WxPython is their work and of course that if they don't accept to maintain a WxPython as apart of Python distribution, then this discussion doesn't have any meaning. Robin, if you're still paying attention to this thread, would you mind chiming in? Robin Dunn is the wxPython project lead. I have only heard that WxPython will never be included, but without beeing more clear. Who knows, maybe some of those who said that are WxPython developers but for me they are just some names because I don't know them... The next (or previous) points are not important anymore if the WxPython developers don't want their work to be included in the Python distribution. So, is it true? That was the cause for which WxPython can't be promoted by Python? There is a large difference between the being "promoted by Python" and being "included in Python's standard library. The latter is the issue at hand, not the former. wxPython is already "promoted" by Python's documentation: http://docs.python.org/library/othergui.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 26/01/2011 18:19, rantingrick wrote: SUMMARY: We create an abstraction API atop "Robin's WxPython". We include only the API in the stdlib at this time and we keep Tkinter in maintenance. Then over the next few years we start a fresh wxPython project that will be acceptable for the stdlib. Something that we can plug our API into. We steal as much from Robin as we can (or get him to cooperate). Then when the time is right, we dump Tkinter and integrate the new Wxpy module into the stdlib. Then we will be back on track. I look forward to reading your PEP and initial design documents, though I suspect you would need the latter and to get some a decent portion of work done before it would even be considered as an inclusion into the standard library. I strongly suspect that your response to this suggestion would be the ironic "more talk and no action from X". Many capable developers have their own occupations and might not have the spare time or desire to spend on a project where all evidence suggests would be a (non-benevolent) dictatorship where they would be endlessly browbeaten. You have continuously tried to outright present yourself as a 'visionary' and speaker for the python community and then asked why people don't take you seriously. People would take you a lot more seriously if you showed that you had the vision and capability to drive development of such a serious undertaking, and manage such a team of developers, whom you have first managed to attract to the project. If you actually seriously believe this should happen and that you are the best person to drive it, the way to go about it is probably: - Write some design documents, or even code, laying out what you think the interface should be. - Put it out to the community, listen to advice, make changes (it will NOT be perfect) and gather support. - Provide an initial implementation Somebody in the old thread said something which made sense, which I paraphrase as: "Only idiots think they can command communities of equals." This is something to keep closely in mind in your continuing, what can only be described as 'crusades'. This, along with the fact that people remember first impressions, and are usually cautious about reversing opinions developed through many examples of uncivility. Heck, I am probably wasting my time with this post; but you come across as genuine in your held central beliefs, and so either serious or the most dedicated and adept troll I have ever encountered. In the case of the former, I hold an optimistic view that most people are capable of self-asessment. In the case of the latter, consider me successfully trolled. Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/26/11 11:19 AM, Octavian Rasnita wrote: From: "Emile van Sebille" ... Well, I didn't know this, and it is a valid reason. This means that it is true that there is no enough maintainance force to keep WxPython updated. Did I understand correctly? Not at all -- wxPython is an active funded ongoing project. Review the roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly the final paragraph on Python3.x support. Emile But somebody said that the core Python developers, or Guido said that WxPython won't be included in the core distribution because it doesn't have a strong team of maintainers... with other words but this was the idea. No, you are misrepresenting what was said. What is required is that someone make an active commitment to maintain wxPython as part of the standard library *specifically*. That means that the package has to follow Python's release cycle. The wxPython developers do not wish to do that. They can develop wxPython much better outside of the standard library. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 26.01.2011 18:04, Octavian Rasnita wrote: From: "Littlefield, Tyler" with JAWS because it is the most used screen reader. Get off your me soapbox. Jaws is not the most used. NVDA is taking over, quite fast, and lots of people have totally switched to mac or Vinux Lots of people means an insignifiant percent of users compared with the percent of Windows users. Please don't use the lower Linux user percentage as an argument here. If you follow that path further, you would need to agree that it's only an "insignificant" percent of people who need a screen reader, so why bother? Note carefully: I am *not* saying that one shouldn't bother about the "minority" of people who need accessibility, just that you can't use an argument that ignores another minority (Linux user) if you fight for your minority (and no, Linux isn't anymore a "freak-os". Several countries (getting more) have started to migrate governmental IT infrastructures to Linux, so if you mean it serious, you just need to care for their, possibly impaired, workers too.) (Also please don't weigh my words to strong; I'm no native english speaker and my wording might be clumsy. Try to understand what I really wanted to say or ask back.) -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
It doesn't support a good voice synthesizer like Eloquence or IBM Via voice, but only eSpeak which sounds horrible, it doesn't have a scripting language ready to use as JAWS and Window Eyes do, it doesn't offer the possibility of reading with the mouse cursor as JAWS does with its so called JAWS cursor, it offers a poor accessibility in many applications and many other issues. You are wrong, on all accounts. On 1/26/2011 10:04 AM, Octavian Rasnita wrote: From: "Littlefield, Tyler" with JAWS because it is the most used screen reader. Get off your me soapbox. Jaws is not the most used. NVDA is taking over, quite fast, and lots of people have totally switched to mac or Vinux Lots of people means an insignifiant percent of users compared with the percent of Windows users. NVDA is mostly used as a second screen reader in case that something wrong happends with the first one. It doesn't support a good voice synthesizer like Eloquence or IBM Via voice, but only eSpeak which sounds horrible, it doesn't have a scripting language ready to use as JAWS and Window Eyes do, it doesn't offer the possibility of reading with the mouse cursor as JAWS does with its so called JAWS cursor, it offers a poor accessibility in many applications and many other issues. because of the problems with Jaws. It's most used in corporate sektors still maybe, but lots of end-users are migrating to Window Eyes, NVDA or OSX because of the fact that it is both cheaper and NVDA is open source, not to mention free. Just because Jaws -was- most used and -you- use it, doesn't mean it still remains so. Window Eyes always was cheaper than JAWS, however it was never the most used screen reader because it also have its problems. I don't understand why you care so much about what will *probably* happen in the future and don't care about the present. An indian saying says that on the long term will be everything fine (because we will be all dead:) But you are talking just to show how right you are. If you remember about our discussion, we were talking about how inaccessible is Tkinter, and well Tkinter has the same inaccessibility level under Window Eyes and NVDA just like under JAWS, so I don't know why is it so important to name all those screen readers if someone wants to test Tkinter. I thought that if someone wants to test how inaccessible is Tkinter, JAWS would be enough because Tkinter is also inaccessible for the other screen readers, and I thought that it would be normally to test the accessibility using the screen reader that offer the most features. Octavian -- Thanks, Ty -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 27, 12:02 am, Nicholas Devenish wrote: > > Heck, I am probably wasting my time with this post; but you come across > as genuine in your held central beliefs, and so either serious or the > most dedicated and adept troll I have ever encountered. In the case of > the former, I hold an optimistic view that most people are capable of > self-asessment. In the case of the latter, consider me successfully trolled. RR: I'd just like to add -- Do consider whom your verbal violence hurts most. You may also want to google for Erik Naggum -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 1:02 pm, Nicholas Devenish wrote: > I look forward to reading your PEP and initial design documents, though > I suspect you would need the latter and to get some a decent portion of > work done before it would even be considered as an inclusion into the > standard library. Yes i want to create an API similar to Tkinter but we cannot mirror exactly Tkinter because wx takes a completely different approach to GUI building. We need to steal all the good attributes of Tkinter (and there are quite a few!), learn from them, and evolve the next generation of API. Tkinter will not be a waste because we will stand on the shoulders of Tkinter and reach even higher! Some of the worthwhile "must haves" are: * Geometry managers (pack, place, grid) The geometry managers of Tkinter are just too beautiful to let die. Wx forces you to use Sizers which are a terrible obstacle to the new GUI programmer. And if you want focus traversal then you must also use Panels. This multiplicity is just too ugly for a high level API like i am suggesting. We will need some auto generation of panels and easier to use Sizers wrapped up in a nice Tkinter Geometry Manager like API. This will take some work. However it can be done. * Tagging systems for a TextCtrl and Canvas. Although i challenged Guido on his argument about tagging, i do much agree that tagging is a *very* powerful feature of the TK::Text and TK::Canvas widgets and we should no doubt incorporate this into the API. And this would be one of the easier aspects of the design. * Event binding Here is another area for improvement. While wx has been moving towards a more "Tkinter like" binding of widget events there is still much to be desired. However the binding is not all bad so we should not spend too much time here if only for very small payoffs. * Segfaults We must protect Python users from segfaults. This is really a wxPython's problem however we could insulate the programmer through many techniques on our end. Like for instance: Recreating the columns of a list control after configuration of a single style. However configuration needs a look at also! * Styles One of the things that always bothered me about Tkinter was lack of styles. I know this has been addressed however in the past one would create many widgets that should share a similar style but Tkinter forced you to feed redundant style options to all of them. We need a way to create style objects and then use them everywhere. I think wx supports this already. This is just a very meager list. Much more needs consideration. However this would be a good launch point toward some stated and attainable goals. There is already a quite mature (citaion needed) start with a project called wax. Check it out here... http://wiki.wxpython.org/Wax > Many capable developers have > their own occupations and might not have the spare time or desire to > spend on a project where all evidence suggests would be a > (non-benevolent) dictatorship where they would be endlessly browbeaten. Well i don't want to be a dictator. I believe that in any healthy community, every member should be a king, however no ONE member ever wears the crown. What i mean is, everyone has a special skill that makes them stand out from the crowd. Something that you do better than the other members. So when the needs of my skill-set are present, i will step forth and lead, and when the needs of your skill-set are present, i will sit back and listen and follow YOUR lead. This is how the strongest groups tackle the largest problems with ease. > You have continuously tried to outright present yourself as a > 'visionary' and speaker for the python community and then asked why > people don't take you seriously. People would take you a lot more > seriously if you showed that you had the vision and capability to drive > development of such a serious undertaking, and manage such a team of > developers, whom you have first managed to attract to the project. Agreed, and i hope to demonstrate these skills soon. However like i mentioned in my last statement, i am not a god, much less a dictator. No single man or woman can accomplish these huge problems alone. It takes a team of united folks all simultaneousness willing to lead AND follow when the time is right for the greater good of a common goal. > > - Write some design documents, or even code, laying out what you think > the interface should be. > - Put it out to the community, listen to advice, make changes (it will > NOT be perfect) and gather support. > I believe we are in this stage now. However much more discussion is needed. -- http://mail.python.org/mailman/listinfo/python-list
how to read the last line of a huge file???
I have do some log processing which is usually huge. The length of each line is variable. How can I get the last line?? Don't tell me to use readlines or something like linecache... -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 1/26/11 9:19 AM, Octavian Rasnita wrote: > From: "Emile van Sebille" > ... >>> Well, I didn't know this, and it is a valid reason. >>> This means that it is true that there is no enough maintainance force to >>> keep WxPython updated. >>> Did I understand correctly? >> >> Not at all -- wxPython is an active funded ongoing project. Review the >> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly >> the final paragraph on Python3.x support. > > But somebody said that the core Python developers, or Guido said that > WxPython won't be included in the core distribution because it doesn't have a > strong team of maintainers... with other words but this was the idea. That isn't, at all, what people said. What they said was that for a new library to be included in the stdlib, it must have maintainers willing to *commit* for years to *maintain* it IN the stdlib. Maintaining something in the stdlib is very different then maintaining something out of the stdlib. The stdlib has quite a few rules: and it evolves at a certain set speed. wxPython is a wrapper around a third-party library which evolves at a totally different rate: if wxPython were included in the stdlib, these two completely separate development cycles could result in significant hardship for the maintainers and more importantly, for the USERS. Does Python now hold up a release waiting for the wxWidgets team to put out a new version with great new features? Or, does Python release as normal, and just by happenstance does wxWidgets release a great new release a month later-- and now Python users can't get it for a year or two when the next feature release of Python is available? Either way, the maintainers job is more difficult, and users are harmed. There's a reason that libs that go into the stdlib tend to be very static and extremely slow paced in their evolution. Now, Robin could decide to maintain wxPython in two places: as a third-party library, and every release cycle sync in the latest to the core stdlib. That's been done: but its actually extremely problematic itself, and is asking for a lot of extra work. wxPython as a third-party library is maintained: certainly. But that doesn't mean wxPython in the stdlib would be maintained. Then again, it may be that they would be fine with moving into the stdlib-- but since its not a viable option for numerous other reasons, they never bothered to give it any real consideration. > So I still don't understand why WxPython can't be a good solution. > If WxPython is well maintained, let's pretend that the maintainers solved > that bug that make the apps give a segfault, and let's pretend that it works > under Python 3. > Can it be a good choice for replacing Tkinter? That's hand-waving a LOT of stuff with "let's pretend", but okay. Let's pretend that the lib is modified and fixed up so that segfaults don't happen (and, IIUC, the next version may be); and let's pretend it works under Python 3 (does that leave me in the dust, as someone who would love to get some wxPython updates but who is only using Python 2.5?). There's a bunch of hurdles that would need solving before its a candidate for inclusion: (off the top of my head) 1. Tkinter can not be removed without a 100% compatible replacement for the forseeable future. 100%. No exception on that 100%. This includes people downloading TK extensions and using them in their Python apps: because if thats not possible, real applications will fail. Please understand before you move on. This is one of the hurdles of the stdlib that make maintaining something in it harder then maintaining something out of it: there are strict compatibility requirements and rules. It might be a great thing for humanity to have Python include an accessible GUI toolkit in the standard library: but that doesn't mean the rules can be broken in doing it. Since its basically impossible to be compatible as such, what you'd have to do is add wx while leaving tk, not replacing it. So: 2. New additions must be PEP-8 compliant; wx is not. 3. New additions must include unit tests; I actually don't know if wx does. I've always found it a pain in the butt to test GUI stuff-- but TK is tested (to some degree, I'm not sure how good the coverage is: I just remember tweaking my buildslave to make it run the tests :)). 4. The documentation would have to all be totally rewritten to fit the stdlib documentation format 5. The license thing needs solving from a legal standpoint (new code is traditionally donated to the PSF under the Apache license, which then in turn re-licenses the code under the Python license). You may think its stupid to let something like that get in the way, but sorry: we live in a lawyer's world. 6. Someone would have to commit to maintaining it _in_ the stdlib. 7. Someone would have to work on integrating the wx build requirements with the stdlib's build requirements for all the platforms -- and this can be quite a bit. If this makes
Re: Is it possible to pass CSV Reader Object As Argument to another Python File ???
On Jan 26, 1:31 pm, Chris Rebert wrote: > On Wed, Jan 26, 2011 at 7:51 AM, bansi wrote: > > I have following two python scripts > > -namelookupWrapper.py > > -namelookup.py > > > The namelookupWrapper.py takes input of "memberId", "memberName" from > > CLI and has following code snippet > > > idf = sys.argv[1] > > namef = sys.argv[2] > > real_script = "C:\\Splunk\\etc\\apps\\search\\bin\\namelookup.py" > > r = csv.reader(sys.stdin) > > os.execv(python_executable, [ python_executable, real_script ] + > > sys.argv[1:] ) > > > Wondering how would i pass csv reader object "r" as an argument using > > os.execv() to another python script i.e. namelookup.py > > It's not possible to pass Python objects between processes in such a > manner. Given that "independent" scripts can't directly take objects > as input anyway, I doubt the two scripts are truly independent from > each other. I would therefore concur with van Sebille that you should > just rewrite them so that one script imports from the other rather > than spawning the other. It should not be too hard to port the Python > 2.6 script to Python 2.7 (or vice-versa if necessary). > > Cheers, > Chris > --http://blog.rebertia.com- Hide quoted text - > > - Show quoted text - Thanks Chris. Sorry for mis-communicating, the two python scripts are dependant in a way that namelookupWrapper.py needs to pass csv record object to another python script If thats not possible then please let me know how to do the workaround i didnt understood the import thing and not sure if it helps in my case Here are the details namelookupwrapper.py - takes input from stdin. Using csv reader object i iterate thru the input which looks like as shown below [MemberId, MemberName] [123, ] [456, ] [989, ] Now i have another script i.e. namelookup.py running under Python 2.7 using pyodbc to retrieve Member Names from database for a given Member Id in namelooupWrapper.py So please let me know how to accomplish this -- http://mail.python.org/mailman/listinfo/python-list
Return Statement
How does "return True" and "return False" affect the execution of the calling function? -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On Jan 26, 2:07 pm, Stephen Hansen wrote: > And some people have absolutely no need-- no need at all-- for any sort > of GUI programming at all. This group is actually really, really big. Stephen "Strawman" Hansen: If he only had a brain! :-) That is the most obvious straw-man to date in this thread. What about the large portion of folks who don't use all the datatypes (queue, weakref, etc) or how about numeric and math modules (fractions, decimal, etc) or how about data persistence, or Cryptograhic, or curses! or, multimedia services, or, or. You see NOT everyone uses everything in the stdlib and most use much less than half. However we would be fools to claim "batteries included" and NOT support GUI! -- http://mail.python.org/mailman/listinfo/python-list
Re: Return Statement
On Jan 26, 2:26 pm, sl33k_ wrote: > How does "return True" and "return False" affect the execution of the > calling function? >>> def f1(): pass >>> print f1() None >>> def f2(): return >>> print f2() None >>> def f3(): return True >>> print f3() True >>> def f4(): return False >>> print f4() False >>> def f5(): return 'Strawman' >>> print f5() Strawman ...any questions? -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On Jan 26, 11:55 am, Benjamin Kaplan wrote: > The code is hosted onhttp://svn.python.org Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Bugs/issues in tkinter.simpledialog!!
On Jan 26, 11:55 am, Benjamin Kaplan wrote: [...snip...] Well i should have looked before i leaped :) This looks like an old 2.x version. I am looking for the newest version with is renamed to "simpledialog" and contains a new class called "SimpleDialog". Do you know were i can view this module? Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
From: "geremy condra" > At least 40% of my coworkers do not speak English as their native > language. Your problem is not the language. Your problem is your > attitude. The atitude considered nice is just duplicity for convincing others, and I don't like duplicity. I like to know exactly what the people think and I want them know what I think. I don't want to convince anyone, but I just want to inform the others and let them know if they are doing something not recommended. I agree, telling the people that they are doing something wrong, directly, without sugar, might be considered a bad atitude by those who prefer duplicity and nice words just for the sake of socializing, but is that atitude worst than of those who don't care about discriminatory practices? >> But I don't condemn you for this, because many years ago when I was in >> school I had the opinion that some foreign colleagues are a little stupid >> just because they were not able to express very well the ideas which were >> not very simple, and well, they were not stupid at all, but they didn't know >> my language well enough and they probably would think the same thing about >> me if we were speaking in Russian. > > I don't have that problem. Oh yes you do as well as many others and it is obvious because I have seen that some of you consider me to be very angry, but I am not angry nor nervous at all so there may be something else. If I say that I don't like a certain country because it attacks other countries, it doesn't mean that I am nervous or angry. I am just expressing my opinions about that country. About those who use Tkinter I can't even say that I don't like them or something like that, because it is very normal that most of Python programmers should prefer it, because it was promoted a long time by Python. What I said is that it is not OK that Python promoted and keeps promoting a GUI lib that creates discrimination, but I don't know where you have seen that anger. >> Exactly what I said. They are doing the same mistake as I did 20 years ago. >> By the way, can't you see any syntactic dissacords in my phrases? Haven't >> you think that my English might not be as fluent to be able to express >> everything I want to say very well? > > As I mentioned earlier, you'll find I don't have a lot of pity for you in > this. I don't need your pitty, but I can see that you misunderstand me, thinking that I am angry, thinking that I want to force everyone to use a GUI lib, and I thought that my English may not be clear enough to make you understand what I want to say. >> But not supporting accessibility because the programmer *doesn't want this*, >> it is not a bug, but discrimination. Don't you agree with this? >> And if Python would have been able to support accessibility it would have >> mean that it promotes discrimination because it promotes the wrong tool, but >> it seems that Python 3 doesn't have an accessible GUI lib for the moment, so >> no, it is not discrimination (but Emile told us that there is no support for >> WxPython in Python 3 just today, so I didn't know this and I already >> wondered why nobody told about this real problem). > > Keep in mind, I'm not saying this. Saying what? I don't understand what you were not saying. > This is a sketch of your point of view and Tyler's point of view. What has the phrase I told above with what Tyler said? I said that if somebody can create accessible programs but doesn't *want* to do that, this generates discrimination. Don't you agree with this? >> Well, I think that everyone should understand why the programs must be >> accessible and why everybody should care about all the users of an >> application and that it is not normal to not care. > > Ah! I think I see where you're going wrong. It *is* normal not to > care- not just about this, but about any given special interest other > than your own. You have to convince people to care, or they don't- and > you're not convincing, just yelling. Where did I say that it is normal to not care about other things? I have also agreed that it is important to have support for Python 3, that it is also important the commercial point of view, it is also important to have a GUI lib without bugs that generates errors, and you are again and again misunderstanding me thinking that I am yelling, even though I am writing all these things very calm. And I am not trying to convince anyone. I mean, we are not in the previous century and I hope that I don't need to convince anyone that offering accessibility for everyone is very important. Do you think that on this list there still are members that need to be convinced about this things? Do you really think that there are members that can't understand the importance of accessibility and they need to be convinced, persuaded, motivated with nice words? Do you have such a bad idea about them? I am sure that they all know very well why the accessibility is important and I
Re: WxPython versus Tkinter.
On Jan 26, 2:37 pm, rantingrick wrote: > On Jan 26, 2:07 pm, Stephen Hansen wrote: > > > And some people have absolutely no need-- no need at all-- for any sort > > of GUI programming at all. This group is actually really, really big. > > Stephen "Strawman" Hansen: If he only had a brain! :-) > > That is the most obvious straw-man to date in this thread. What about > the large portion of folks who don't use all the datatypes (queue, > weakref, etc) or how about numeric and math modules (fractions, > decimal, etc) or how about data persistence, or Cryptograhic, or > curses! or, multimedia services, or, or. > > You see NOT everyone uses everything in the stdlib and most use much > less than half. However we would be fools to claim "batteries > included" and NOT support GUI! You show a remarkable, awe-inspiring ability to completely miss every salient point of a well articulated argument. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need GUI pop-up to edit a (unicode ?) string
On Jan 26, 2:11 am, Terry Reedy wrote: > In 3.x, the module is now tk.simpledialog -- all lower case. The purpose > of all lowercase module names is to avoid confusion with upper case > class names. Yes Terry, i found the new module and documented the bugs in a new thread. I am not sure if the bugs are still present in the current RC (Note: i have 3.1.1 installed) however i would bet they are. As soon as i can find the current source in svn i'll update the "bug thread". However i cannot find it. If you can give a link that would be great! -- http://mail.python.org/mailman/listinfo/python-list
Re: how to read the last line of a huge file???
On 1/26/2011 2:59 AM Xavier Heruacles said...
I have do some log processing which is usually huge. The length of each line
is variable. How can I get the last line?? Don't tell me to use readlines or
something like linecache...
seek
-rw-rw1 autofax mail 1061716366 Jan 26 12:45 autofax
[root@wsgfw3 root]# python2
Python 2.3.5 (#1, Aug 3 2005, 08:40:39)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('/var/spool/mail/autofax')
>>> f.seek(106171)
>>> lines = f.read()
>>> len(lines)
6366
>>>
flavor to taste.
Emile
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to read the last line of a huge file???
On 26/01/2011 10:59, Xavier Heruacles wrote: I have do some log processing which is usually huge. The length of each line is variable. How can I get the last line?? Don't tell me to use readlines or something like linecache... Seek to somewhere near the end and then read use readlines(). If you get fewer than 2 lines then you can't be sure that you have the entire last line, so seek a little farther from the end and try again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 88, Issue 69
Sent from my LG phone python-list-requ...@python.org wrote: >Send Python-list mailing list submissions to > python-list@python.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list >or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > >You can reach the person managing the list at > python-list-ow...@python.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Python-list digest..." > >Today's Topics: > > 1. Re: Python use growing fast (Alice Bevan?McGregor) > 2. Re: order of importing modules (Chris Rebert) > 3. Re: How to Buffer Serialized Objects to Disk (MRAB) > 4. Re: How to Buffer Serialized Objects to Disk (Chris Rebert) > 5. Re: How to Buffer Serialized Objects to Disk (Peter Otten) > 6. Re: Best way to automatically copy out attachments from an > email (Chris Rebert) > 7. Re: Parsing string for " " (Aahz) > 8. Re: Nested structures question (Tim Harig) > 9. Re: How to Buffer Serialized Objects to Disk (Scott McCarty) > >On 2011-01-10 19:49:47 -0800, Roy Smith said: > >> One of the surprising (to me, anyway) uses of JavaScript is as the >> scripting language for MongoDB (http://www.mongodb.org/). > >I just wish they'd drop spidermonkey and go with V8 or another, faster >and more modern engine. :( > > - Alice. > > > > >> Dan Stromberg wrote: >>> On Tue, Jan 11, 2011 at 4:30 PM, Catherine Moroney >>> wrote: In what order does python import modules on a Linux system? I have a package that is both installed in /usr/lib64/python2.5/site-packages, and a newer version of the same module in a working directory. I want to import the version from the working directory, but when I print module.__file__ in the interpreter after importing the module, I get the version that's in site-packages. I've played with the PYTHONPATH environmental variable by setting it to just the path of the working directory, but when I import the module I still pick up the version in site-packages. /usr/lib64 is in my PATH variable, but doesn't appear anywhere else. I don't want to remove /usr/lib64 from my PATH because that will break a lot of stuff. Can I force python to import from my PYTHONPATH first, before looking in the system directory? >>> Please import sys and inspect sys.path; this defines the search path >>> for imports. >>> >>> By looking at sys.path, you can see where in the search order your >>> $PYTHONPATH is going. >>> >On Wed, Jan 12, 2011 at 11:07 AM, Catherine Moroney > wrote: >> I've looked at my sys.path variable and I see that it has >> a whole bunch of site-package directories, followed by the >> contents of my $PYTHONPATH variable, followed by a list of >> misc site-package variables (see below). > >> But, I'm curious as to where the first bunch of 'site-package' >> entries come from. The >> /usr/lib64/python2.5/site-packages/pyhdfeos-1.0_r57_58-py2.5-linux-x86_64.egg >> is not present in any of my environmental variables yet it shows up >> as one of the first entries in sys.path. > >You probably have a .pth file somewhere that adds it (since it's an >egg, probably site-packages/easy-install.pth). >See http://docs.python.org/install/index.html#modifying-python-s-search-path > >Cheers, >Chris >-- >http://blog.rebertia.com > > >On 12/01/2011 21:05, Scott McCarty wrote: >> Sorry to ask this question. I have search the list archives and googled, >> but I don't even know what words to find what I am looking for, I am >> just looking for a little kick in the right direction. >> >> I have a Python based log analysis program called petit >> (http://crunchtools.com/petit). I am trying to modify it to manage the >> main object types to and from disk. >> >> Essentially, I have one object which is a list of a bunch of "Entry" >> objects. The Entry objects have date, time, date, etc fields which I use >> for analysis techniques. At the very beginning I build up the list of >> objects then would like to start pickling it while building to save >> memory. I want to be able to process more entries than I have memory. >> With a strait list it looks like I could build from xreadlines(), but >> once you turn it into a more complex object, I don't quick know where to go. >> >> I understand how to pickle the entire data structure, but I need >> something that will manage the memory/disk allocation? Any thoughts? >> >To me it sounds like you need to use a database. > > >On Wed, Jan 12, 2011 at 1:05 PM, Scott McCarty wrote: >> Sorry to ask this question. I have search the list archives and googled, but >> I don't even know what words to find what I am looking for, I am just >> looking for a little kick in the right direction. >> I have a Python based log analysis program called petit >> (http://crunchtools.com/petit). I
Re: Python-list Digest, Vol 88, Issue 69
Sent from my LG phone python-list-requ...@python.org wrote: >Send Python-list mailing list submissions to > python-list@python.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list >or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > >You can reach the person managing the list at > python-list-ow...@python.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Python-list digest..." > >Today's Topics: > > 1. Re: Python use growing fast (Alice Bevan?McGregor) > 2. Re: order of importing modules (Chris Rebert) > 3. Re: How to Buffer Serialized Objects to Disk (MRAB) > 4. Re: How to Buffer Serialized Objects to Disk (Chris Rebert) > 5. Re: How to Buffer Serialized Objects to Disk (Peter Otten) > 6. Re: Best way to automatically copy out attachments from an > email (Chris Rebert) > 7. Re: Parsing string for " " (Aahz) > 8. Re: Nested structures question (Tim Harig) > 9. Re: How to Buffer Serialized Objects to Disk (Scott McCarty) > >On 2011-01-10 19:49:47 -0800, Roy Smith said: > >> One of the surprising (to me, anyway) uses of JavaScript is as the >> scripting language for MongoDB (http://www.mongodb.org/). > >I just wish they'd drop spidermonkey and go with V8 or another, faster >and more modern engine. :( > > - Alice. > > > > >> Dan Stromberg wrote: >>> On Tue, Jan 11, 2011 at 4:30 PM, Catherine Moroney >>> wrote: In what order does python import modules on a Linux system? I have a package that is both installed in /usr/lib64/python2.5/site-packages, and a newer version of the same module in a working directory. I want to import the version from the working directory, but when I print module.__file__ in the interpreter after importing the module, I get the version that's in site-packages. I've played with the PYTHONPATH environmental variable by setting it to just the path of the working directory, but when I import the module I still pick up the version in site-packages. /usr/lib64 is in my PATH variable, but doesn't appear anywhere else. I don't want to remove /usr/lib64 from my PATH because that will break a lot of stuff. Can I force python to import from my PYTHONPATH first, before looking in the system directory? >>> Please import sys and inspect sys.path; this defines the search path >>> for imports. >>> >>> By looking at sys.path, you can see where in the search order your >>> $PYTHONPATH is going. >>> >On Wed, Jan 12, 2011 at 11:07 AM, Catherine Moroney > wrote: >> I've looked at my sys.path variable and I see that it has >> a whole bunch of site-package directories, followed by the >> contents of my $PYTHONPATH variable, followed by a list of >> misc site-package variables (see below). > >> But, I'm curious as to where the first bunch of 'site-package' >> entries come from. The >> /usr/lib64/python2.5/site-packages/pyhdfeos-1.0_r57_58-py2.5-linux-x86_64.egg >> is not present in any of my environmental variables yet it shows up >> as one of the first entries in sys.path. > >You probably have a .pth file somewhere that adds it (since it's an >egg, probably site-packages/easy-install.pth). >See http://docs.python.org/install/index.html#modifying-python-s-search-path > >Cheers, >Chris >-- >http://blog.rebertia.com > > >On 12/01/2011 21:05, Scott McCarty wrote: >> Sorry to ask this question. I have search the list archives and googled, >> but I don't even know what words to find what I am looking for, I am >> just looking for a little kick in the right direction. >> >> I have a Python based log analysis program called petit >> (http://crunchtools.com/petit). I am trying to modify it to manage the >> main object types to and from disk. >> >> Essentially, I have one object which is a list of a bunch of "Entry" >> objects. The Entry objects have date, time, date, etc fields which I use >> for analysis techniques. At the very beginning I build up the list of >> objects then would like to start pickling it while building to save >> memory. I want to be able to process more entries than I have memory. >> With a strait list it looks like I could build from xreadlines(), but >> once you turn it into a more complex object, I don't quick know where to go. >> >> I understand how to pickle the entire data structure, but I need >> something that will manage the memory/disk allocation? Any thoughts? >> >To me it sounds like you need to use a database. > > >On Wed, Jan 12, 2011 at 1:05 PM, Scott McCarty wrote: >> Sorry to ask this question. I have search the list archives and googled, but >> I don't even know what words to find what I am looking for, I am just >> looking for a little kick in the right direction. >> I have a Python based log analysis program called petit >> (http://crunchtools.com/petit). I
Re: Python-list Digest, Vol 88, Issue 67
Sent from my LG phone python-list-requ...@python.org wrote: >Send Python-list mailing list submissions to > python-list@python.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list >or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > >You can reach the person managing the list at > python-list-ow...@python.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Python-list digest..." > >Today's Topics: > > 1. Re: Python use growing fast (Colin J. Williams) > 2. Career path - where next? (Alan Harris-Reid) > 3. Re: Career path - where next? (Terry Reedy) > 4. Re: Python use growing fast (Terry Reedy) > 5. Re: Ideas for a module to process command line arguments > (Alice Bevan?McGregor) > 6. Re: Python use growing fast (Krzysztof Bieniasz) > 7. Re: Career path - where next? (Jon Clements) > 8. Re: Career path - where next? (Philip Semanchuk) > 9. Best way to automatically copy out attachments from an email > (Matty Sarro) > 10. How to populate all possible hierarchical clusterings from a > set of elements? (justin) > >On 10-Jan-11 16:02 PM, MRAB wrote: >> On 10/01/2011 20:29, Dan Stromberg wrote: >>> I invite folks to check out Tiobe's Language Popularity Rankings: >>> >>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >>> >>> The gist is: Python grew faster than any other programming language >>> over the last year, according to this (slightly arbitrary, but better >>> than no indicator) ranking. >>> >>> ...despite our wikipedia page whose first paragraph almost seems like >>> it was written with the intention of scaring off new converts, with >>> its "unusual" comment: >>> >>> http://en.wikipedia.org/wiki/Python_%28programming_language%29 >>> >>> (Like it or not, people do frequently confuse the descriptive for the >>> normative) >> >> It shows an example of Python code, which happens to have 2 syntax >> errors! > >Why not correct the Wikipedia entry? > >Colin W. > > > >Hi there, I wonder if any Python folk out there can help me. > >For many years I was a contractor developing desktop and web >applications using Visual Foxpro as my main language, with Foxpro, >SQL-server and Oracle as back-end databases. Unfortunately Foxpro was >killed-off by Microsoft, hence my work dried-up and my last 'big' >contract ended about a year ago. Since then I have taken time off >programming doing house-renovation, and in the last 6 months I have been >updating my programming skills by learning Python (3) with SQLite, >JavaScript, HTML and CSS to a level where I can create and deploy >data-based web-sites. > >My situation now is that I am reasonably comfortable with the above >languages and am now in a position where I wish to return to employment >using my new and/or existing skills (contract/permanent, full/part-time >or teleworking). However, I have yet to find any UK vacancy which will >accept a relative 'beginner' - they all require at least 2-3 years >Python in a commercial environment. It's a catch-22 situation - it's >hard to get a job without experience, but you need a job to get >experience in the 1st place! > >I would even consider doing small projects for nothing so that I can >'get my foot in the door' (although I hope to be wise-enough to know >when I am being taken advantage of!). I am also mailing CVs to agencies >I think may be interested. > >If anyone out has ideas as to how to proceed towards achieving my goal, >I would be grateful for any advice. > >Regards, >Alan Harris-Reid > > > >On 1/12/2011 11:37 AM, Alan Harris-Reid wrote: > >... >> updating my programming skills by learning Python (3) with SQLite, >> JavaScript, HTML and CSS to a level where I can create and deploy >> data-based web-sites. >... >> I would even consider doing small projects for nothing so that I can >> 'get my foot in the door' (although I hope to be wise-enough to know > >I believe both Roundup/Python tracker and PyPI (Python package index) >are based on sqlite and have small projects available/needed. I cannot >help you otherwise. Good luck. > >-- >Terry Jan Reedy > > > >On 1/12/2011 9:51 AM, Colin J. Williams wrote: > >>> It shows an example of Python code, which happens to have 2 syntax >>> errors! >> >> Why not correct the Wikipedia entry? > >As I reported early, the errors, if any, are in .png and .svg images of >text, which would have to be replaced, not corrected. Would be good >since the imaged snippet is a haphazard except from a much larger file >and inane out of context. > >-- >Terry Jan Reedy > > > >On 2011-01-11 21:41:24 -0800, Michele Simionato said: > >> Originally plac too was able to recognize flags automatically by >> looking at the default value (if the default value is a boolean then >> the option is a flag); however I removed that functionality becau
Re: Return Statement
On 1/26/11 12:26 PM, sl33k_ wrote: > How does "return True" and "return False" affect the execution of the > calling function? It doesn't -- the value 'True' or 'False' is simply returned, and assigned to a name if the calling function does so explicitly. But there's no built in affects. If you want it to alter the execution, you have to do so yourself, i.e.: def myfun(): return True def myfun2(): return False if myfun(): print "Something is true!" myfun2() print "I'm called. Cuz, the return value of myfun2 was simply discarded." -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 01/26/2011 01:18 AM, Octavian Rasnita wrote: > From: "rantingrick" > On Jan 25, 3:41 pm, Corey Richardson wrote: > >> Do you honestly think he was talking about the accessibility problem? >> IMO that should move to another thread, because this one is simply >> about, as the subject suggests, "WxPython versus Tkinter". > > Corey again (like many) you lack a global perspective. Anybody who has > read along with his thread knows we are covering some pretty big > issues here. WxPython is just the vehicle. The big picture is simply: > Tkinter is old and in many ways insufficient for 21st century GUIs. We > need to decide what should come next. I believe wxPython is our best > hope. Wx may not be the best it can be, but it is the best we have at > this time. There is more than "meets the eye" Corey! I think he was referring to the large amount of trolling and immature behaviour displayed. It would be a horrible thing to think that accessibility is _bad_, unless of course it takes away from usability to sighted users or is tons harder to implement (the technical reasons you mentioned earlier). I understand that this thread is about the deficiencies of Tkinter (and many other GUI toolkits) and that Wx is far better than lots of what we have (but still has its issues). I personally despise writing GUI's, but I do it when I have to. I'm a fan of tkinter and wx because they are (in my very little experience) very easy to use. The issue I was raising with your post was really context. He wasn't bashing specifically on accessibility or a toolkit, but more of the attitudes and overall tone of some of the posts. Hope that cleared it up for you. (This would be a good time for python-gui to be opened up IMO, since it appears lots of discussion is being generated) ~Corey -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
Since it seems the python motto is "Batteries included", then it would seem to me that wxPython is the natural fit as it also has "Batteries included" (e.g. accessibility, native look-n-feel, mature and evolving, can produce simple or complex gui programs, etc, etc). -- Brendan Simon www.etrix.com.au -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to pass CSV Reader Object As Argument to another Python File ???
bansi writes: > Thanks Chris. Sorry for mis-communicating, the two python scripts are > dependant in a way that namelookupWrapper.py needs to pass csv record > object to another python script Why have you structured them that way, though? What constraint is keeping you from doing the work in a single process, where the CSV reader object can be shared? > If thats not possible then please let me know how to do the workaround > i didnt understood the import thing and not sure if it helps in my > case The problem as you've described it so far is best solved by having a single process accessing the CSV reader object in memory. If that doesn't suit your use case, you'll need to explain why not. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__)master.” —Richard M. Stallman, 2007-05-16 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
use class factory to set required class variables?
I have a class ``A`` that is intentionally incomplete: it has methods that refer to class variables that do not exist. The class ``A`` has several complicated methods, a number of which reference the "missing" class variables. Obviously, I do not directly use ``A``. I have a class factory ``f``` that subclasses ``A`` *only* in order to define the class variables. The motivation/problem: I did this because I need many versions of class ``A``, which differ only in the class variables, which are not known until run time. Q: On the face of it, did I pick a reasonable solution to my problem? If so is this a standard pattern? If not, can you mention a better approach? My solution is working for me, but the class ``A`` is bugging me, because of the odd (to me) way in which it is incomplete. Obviously, I'm not a computer science type ... Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Return Statement
On 1/26/2011 12:26 PM sl33k_ said... How does "return True" and "return False" affect the execution of the calling function? That depends on the calling function. It will control what it does next generally based on the returned value, but it could also simply store the result. def isACustomer(custID): 1 return custID in currentCustList def isActive(custId): 2 return custID in openInvoicesByCustID for custID in custList: 3 if isACustomer(custID): 4activeFlag = isActive(custID) Here, 1 and 2 return True or False depending on the inclusion test. 3 causes the subsequent code block to be executed when True is returned 4 stores True of False in activeFlag for subsequent use. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: Return Statement
On 26.01.2011 21:26, sl33k_ wrote: How does "return True" and "return False" affect the execution of the calling function? If only affects the calling function if you use the return value: def foo(): return True def bar1(): foo() # nothing difference, whether foo() returns True or False def bar2() if foo(): print "foo returned True or any other non-false value" else: print "foo returned False or any other non-True value" -- http://mail.python.org/mailman/listinfo/python-list
Re: use class factory to set required class variables?
On Jan 26, 4:37 pm, Alan wrote: > I have a class factory ``f``` that subclasses ``A`` *only* in > order to define the class variables. I suppose it would be clearer to say that `f` *returns* subclasses of `A`. Hopefully that was clear ... Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
On 2011-01-26, Octavian Rasnita wrote: > From: "geremy condra" >> At least 40% of my coworkers do not speak English as their native >> language. Your problem is not the language. Your problem is your >> attitude. > > The atitude considered nice is just duplicity for convincing others, > and I don't like duplicity. And, based on your behavior, you apparently don't like convincing others or advancing the cause of accessibility. It seems you prefer to annoy and alienate others. > I like to know exactly what the people think and I want them know > what I think. That can be accomplished in a polite and respectful manner. You claim to be advocating for , and trying to accomplish , yet your actions indicate the opposite by their counter-productive nature. > I don't want to convince anyone, but I just want to inform the others > and let them know if they are doing something not recommended. IOW, you don't really care about increasing accessibility, you just want to hear the sound of your own voice as you shout into the wind. If you actually cared about accessibility for the handicapped, you would care about convincing others to care also -- because that's the only way the situation can be improved. > I agree, telling the people that they are doing something wrong, > directly, without sugar, might be considered a bad atitude by those > who prefer duplicity and nice words just for the sake of socializing, > but is that atitude worst than of those who don't care about > discriminatory practices? Yes, it is worse. People who don't care are neither helping nor hurting your cause. However, you're actively hurting it. People will not separate your personality from the cause you espouse. You may not like it, but that's a fact. If you are in favor of XYZ, and act rude and insulting while espousing XYZ, people will react against not only you but _also_ XYZ. You can claim that's neither "right" nor "fair" nor "good" nor whatever. But it's a fact -- just like gravity. You may not like it or find it convenient. But if you insist on ignoring it you're just going to crash into the ground over and over and over again. -- Grant Edwards grant.b.edwardsYow! I smell a RANCID at CORN DOG! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
replacing lines in a file
Attached are a config file parser that i'm working on, and a example
config file. Basically, what my problem is is in write_config, it should
search through the file, and replace the lines with whatever the
modified version is, it is also designed to ignore comments. To see my
problem (which is hard to describe) please first look at the config
file, and then run config-parse.py then look at the config file again.
One of two things should happen: nothing, or something weird should
happen on the last line.
#!/usr/bin/python
import fileinput
def read_config(file):
config={}
if isinstance(file, type('str')) :
config_file=open_config_file(file, 'r')
if not config_file:
return 1
for option in config_file:
option=option.replace('\n','')
if option!='' and '#' not in option:
option=option.split(':')
config[option[0]]=option[1]
config_file.close()
return config
else:
print "the file paramenter should be a string contianing a file path"
return 1
def write_config(config, file):
if isinstance(config, type({})) and isinstance(file, type('str')):
config_file=open_config_file(file,'r+')
if not config_file:
return 1
for line in config_file:
line=line.replace('\n','')
if line!='' and '#' not in line:
option=line.split(':')
new_line = option[0]+':'+config[option[0]] + '\n'
print config_file.write(line.replace(line, new_line))
config_file.close()
else:
print "The config arg must be a dictionary and/or the file arg must be a string containing a file path"
def open_config_file(file, mode):
try:
config_file=open(file,mode)
except IOError:
print "That File Doesn't exist!"
return None
return config_file
if __name__ == '__main__':
file = './net-responsibility.conf2'
config=read_config(file)
print config
config["logfile"]=' 5'
file = './net-responsibility.conf2'
write_config(config, file)
logfile: /var/log/example.log
pidfile: /var/run/example.pid
report_frequency: 7
online_user: Test
--
http://mail.python.org/mailman/listinfo/python-list
