[issue10012] httplib shadows builtin, assumes strings
New submission from Cliff Wells cl...@develix.com: httplib.py ~Line 924 def putheader(self, header, *values): str = '%s: %s' % (header, '\r\n\t'.join(values)) self._output(str) should be changed to something like: def putheader(self, header, *values): ... s = '%s: %s' % (header, '\r\n\t'.join([str(v) for v in values])) self._output(s) The current version shadows str builtin with a local variable. join method assumes strings so they should probably be explicitly cast (at least one 3rd party library appears to pass Content-length as an integer, causing this to fail. Of course, this can't be done unless the str builtin is no longer shadowed. -- components: Library (Lib) messages: 117852 nosy: cwells priority: normal severity: normal status: open title: httplib shadows builtin, assumes strings versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Default parameter for a method
On Wed, 2008-04-16 at 13:47 -0500, Larry Bates wrote: [EMAIL PROTECTED] wrote: I wanted to know if there's any way to create a method that takes a default parameter, and that parameter's default value is the return value of another method of the same class. For example: class A: def __init__(self): self.x = 1 def meth1(self): return self.x def meth2(self, arg=meth1()): # The default `arg' should would take the return value of meth1() print 'arg is', arg This obviously doesn't work. I know I could do ... def meth2(self, arg=None): if arg is None: arg = self.meth1() but I'm looking for a more straightforward way. You can write this as: def meth2(self, arg=None): arg = arg or self.meth1() IMHO - You can't get much more straightforward than that. What if arg is 0 an empty list or anything else that's False? def meth2(self, arg=None): arg = (arg is not None) or self.meth1() is what you want. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Is anyone happy with csv module?
On Wed, 2007-12-12 at 07:04 -0800, massimo s. wrote: If by thoroughly you mean it actually describes technically what it is and does but not how to really do things, yes, it is thoroughly documented. The examples section is a joke. Actually I rarely use the csv module these days, but I find a quick glance at the examples to be sufficient in most cases. It gives good examples for the simplest usage cases (good), then it almost immediately digs into details like the Unicode stuff, leaving aside the rest. DictWriter and DictReader are absent from the examples. And also the Sniffer. I take full responsibility for the lack of documentation on the Sniffer. If you are interested in using it, I'd be happy to help you out and maybe we could get some docs submitted. It's actually remarkably simple to use, but I admit looking at the source won't make you think so ;-) Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Is anyone happy with csv module?
On Wed, 2007-12-12 at 09:50 +1100, Ben Finney wrote: massimo s. [EMAIL PROTECTED] writes: Yes, but it's natural for a spreadsheet-like thing to have organized columns of data, often. Perhaps, but that's not relevant. CSV is a serialisation format for tabular data, and is only a spreadsheet-like thing in its heritage. The CSV data stream is not spreadsheet-like at all. To add some weight to this point, if CSV *weren't* considered a serialization format (or protocol) this module most likely would have never been accepted into the standard library in the first place. There was some debate when the PEP was submitted over whether CSV was to be considered a file format (like an .XLS file) or a serialization protocol (like XML or HTTP). Fortunately the latter was agreed up and so the module was deemed appropriate for inclusion in the standard libraries. Whether or not anyone agrees with this point of view is now mostly irrelevant, since *by definition* the Python csv module intends to implement a protocol. Other implementations remain free to vary in their definition of CSV. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Some pythonic suggestions for Python
On Thu, 2007-11-08 at 15:00 -0500, Frank Samuelson wrote: I love Python, and it is one of my 2 favorite languages. I would suggest that Python steal some aspects of the S language. In general, I agree that Python has some antiquated concepts at its core (statements being a major one) and that some of these things make the language inconsistent and introduce additional syntax. However, despite the apparent close-mindedness of some of the respondents (it doesn't look like current Python syntax, hence it's ugly), I also agree with them to a degree: changing Python at this level would mean it would no longer be Python, it would be some other language. What you are basically asking is that GvR abandon Python (like ABC before it) and start on a next generation language. That's quite a request. I'm not saying it's a bad request, simply that you should recognize the scale of request you are making. On a more practical level, you might take a look at Boo. It's intentionally Python-like in appearance, yet lifts several key limitations (and is probably far more open to suggestions at this early stage in its life). Unfortunately it's nowhere near Python in completeness (notably documentation, size of community and overall maturity) and, for better or worse, it runs on .NET/Mono. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: How to sort using hash's key?
On Thu, 2007-02-01 at 04:54 +0800, JoJo wrote: I want to sort a dict via its key,but I have no idea on how to do it. Please help me,thanks. You can't. There is, however, a recipe for an ordered dict on ASPN: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438823 3webXS HiSpeed Dial-up...surf up to 5x faster than regular dial-up alone... just $14.90/mo...visit www.get3web.com for details You pay $15/mo for dialup??? Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Type casting a base class to a derived one?
On Thu, 2007-01-11 at 08:41 -0600, Chris Mellon wrote: On 11 Jan 2007 15:01:48 +0100, Neil Cerutti [EMAIL PROTECTED] wrote: On 2007-01-11, Frederic Rentsch [EMAIL PROTECTED] wrote: If I derive a class from another one because I need a few extra features, is there a way to promote the base class to the derived one without having to make copies of all attributes? class Derived (Base): def __init__ (self, base_object): # ( copy all attributes ) ... This looks expensive. Moreover __init__ () may not be available if it needs to to something else. Thanks for suggestions How does it make sense to cast a base to a derived in your application? I can't figure out any circumstance when you'd need to do this in Python. Upcasting like this is something you do in statically typed languages. I suspect that the OP doesn't really believe dynamic casting works and doesn't want to pass a derived class for some reason. I actually encountered a need to do so (and I recalled seeing this thread which is why I'm replying to it now). I've got a dispatch system based on object type. Objects come from an external source (an ORM), so I can't efficiently set their types at the point of creation (nor would I necessarily want to). However, in different contexts, I may want them to be dispatched differently (i.e as if they are a different type). In fact, often the same object will be handled differently within two or more contexts during the lifetime of that object. It would be nice to be able to cast them to a derived class (which actually adds no new methods or attributes, just changes the type) at that exact moment to cause the dispatcher to handle them differently. Now, that being said, it's quite possible the system *could* have been designed to not dispatch based on type, but quite frankly it works quite elegantly and naturally for everything but this one case. Just pointing out that just because we don't see a need for something doesn't invalidate it. It just makes it something we had thought of ;-) Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Type casting a base class to a derived one?
On Wed, 2007-01-24 at 12:57 -0600, Chris Mellon wrote: In Python, you can do this simply by re-assigning the __class__. I'm not convinced that your type system makes sense, here though. Any reasonable ORM should be able to persist and reload an object without losing the type information. Perhaps it's just a blind spot in the way I think about types. Assuming that the limitations of your ORM are external and out of your control, I would still ensure that whatever generic objects are being loaded from the ORM are converted into real objects of the correct type as soon as possible. For example, if you're persisting a file, you might just save the filename, and your ORM might return a string of the filename. I would want to convert that back into a file object ASAP, rather than writing all my code to accept either a FLO or a string and converting then. If you know what to upcast something to, then you know what type it is. If you know what type it is, then (in Python) you can simply assume it is of that type. Probably being more specific would help in this case ;-) What I'm doing is implementing an object-publishing mechanism in my template engine (Breve). The type decision isn't known until the moment of rendering (i.e. in the template itself). Say for instance a set of records is pulled from the ORM (SQLAlchemy in this case) and that these records represent articles in a blog. These records, until they hit the template, have no real representation in HTML. The decision about how to present them is up to the template. The dispatch mechanism I referred to earlier is a way that I allow users of the template system to register how a particular object should be rendered in HTML (a flattener). This allows commonly represented objects to be used without a lot of template clutter. However, if you consider the case of a blog, then if the template receives a list of articles, it would seem reasonable to present those articles in at least two ways: first as a table of contents in the page gutter, and then perhaps as two or three summaries in the main part of the page. But this isn't known to the lower layers of the application, only to the template. Therefore it would be nice if the template user could register two classes with the flattener, both representations of the original object but simply with a different type. I'll give a concrete example: class Person: # assume this is something from the ORM name = Kenny class PersonRow ( Person ): pass def flatten_person ( p ): return spanomg, you've killed %p/span % p.name def flatten_personrow ( p ): return trtd%s/td/tr % p.name register_flattener ( PersonRow, flatten_personrow ) register_flattener ( Person, flatten_person ) Now, assuming a list of Person records were passed in as 'persons', then in the template the template author could simply use: div [ # show the first person persons [ 0 ], # show a table of all persons table [ [ PersonRow ( p ) for p in persons ] ] ] What you're describing is a disjoint between your actual type system (that is, the one you have in code) and your theoretical type system (the one that you model your code around). To me, this is a huge red warning flag. What I'm describing is a disjoint between how I want my template engine to be used (I tend to build backwards, writing the desired template code and then the engine code to support that use) and what can be easily and efficiently achieved. But yes, in a way you are correct since my theoretical type system is constrained by Python's type system (Breve templates are Python expressions). That being said, I'm certain I'll come up with a solution that doesn't bug me too much, it's just that the obvious solution doesn't exist (type casting). I'm arguing against the idea that it makes sense, in Python, to upcast. I think it's definitely a corner-case, but I'd be reluctant to claim it would never be of use. I agree, but without a use case it's hard to understand the limits and needs of a requirement. So if you can't think of a need for a feature, it becomes difficult to understand how you might implement that feature. Certainly. Several years of using Python has never suggested a use to me prior to this. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Type casting a base class to a derived one?
On Wed, 2007-01-24 at 11:37 -0800, Cliff Wells wrote: class Person: # assume this is something from the ORM name = Kenny class PersonRow ( Person ): pass def flatten_person ( p ): return spanomg, you've killed %p/span % p.name def flatten_personrow ( p ): return trtd%s/td/tr % p.name register_flattener ( PersonRow, flatten_personrow ) register_flattener ( Person, flatten_person ) Now, assuming a list of Person records were passed in as 'persons', then in the template the template author could simply use: div [ # show the first person persons [ 0 ], # show a table of all persons table [ [ PersonRow ( p ) for p in persons ] ] ] I should add that the reason I don't want to just say, call flatten_personrecord() directly from the template (which would be a reasonable solution in this example) is because I have a longer-term goal that would require an object at that point. What I expect I'll end up doing is using a factory function that returns the desired object at that point, but it will require a bit more explanation at the template level than I'd like: table [ [ render_as ( PersonRow, p ) for p in persons ] ] or something similar. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dejavu 1.5.0RC1
On Wed, 2007-01-24 at 14:57 -0800, Robert Brewer wrote: 1. Expressions: pure Python lambda querying. This is perhaps the most appealing feature of Dejavu. Actually I just went and looked and personally I find the documentation the most appealing feature. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: template engine
piotr wrote: On Sat, 13 Jan 2007 16:42:16 -0200, Jorge Godoy wrote: Take a look at Kid (http://www.kid-templating.org/) and Genshi (http://genshi.edgewall.org/). I've already done a short look at kid, but to be honest I don't like it's XML/Python syntax. I strongly prefer idea from SimpleTAL or HTMLTemplates where HTML and Python code are separated. But syntax is for me not so important like functionality so maybe I have to get back and look at kid again :) any other engines? :) Perhaps Breve might interest you: http://breve.twisty-industries.com Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sun, 2006-12-10 at 01:28 -0800, Kay Schluehr wrote: Who really wants to write web apps? Web apps are just an excuse for Pythonistas to write web frameworks. I've been lurking, waiting for the right moment to toss in my two cents, and finally, and here it is. I've been using Python heavily for many years (since late 1.5.1) and frankly I've gotten a bit bored with it. I think your statement indirectly (and unintentionally I'm sure) sums up why. Python is certainly pragmatic. Python has *everything* you'd want for writing applications: extensive libraries, flexibility, etc. Unfortunately, writing applications is boring. The way I like to overcome this boredom (and hence stay productive) is by writing clever code. I don't mean obfuscated one-liners (although I'm guilty of that too), rather I mean generalizing code, creating frameworks and then developing the application in that framework, that sort of thing. Python has been pretty good for me so far in keeping the ceiling high enough that I could stretch but not bump my head too often. I suspect I'm not alone in this need (hence the unusual number of web frameworks written in Python). However lately I've noticed that the ceiling is quite apparent: Python programmers are free to define DSL's via functions, classes, clever operator overloading, etc, but not in the one way that actually makes them really interesting: macros. It might be true that macros would make it more difficult for someone else to understand my code (although I doubt much more than say, Zope or Twisted, or any of the popular ORMs floating about). Regardless, let's take a moment to consider another point of view: I. DON'T. CARE. That's right. I don't care if anyone else can read it. Frankly I may not even care if *I* can read it in a year. Every year I look back at what I've written the previous year and think about how much better I could have done it *this* year. This has gone on for over twenty years now and I suspect that if that fact ever changed it would probably be time for me to retire from programming as I'd have stopped learning (or would at least be bored out of my mind). The majority of code is throwaway. That is, whatever need it was written to fulfill will cease to exist, the coder will think of some brilliant new approach that requires a major rewrite, another programmer with different ideas will rewrite it from the ground up (probably in a new language), a library will appear that renders it moot, etc, etc. While I'm sure there is a huge base of ancient code out there somewhere, faithfully powering our banks and dams and pushing fractions of pennies about, I simply don't care. Someone may have to read it, please god don't let it be me. I don't care about old application code. It's effing boring. I don't just program because it pays the bills. I program because I *like to program*. That means not having arbitrary limits to what I can express so that some hypothetical 8th grader can come along in some future decade and grok some one-off program I hacked together over a weekend. If I write code during a drunken binge, then dammit, I'll run that code in another drunken binge. If not, then I'll damn well rewrite it when I'm sober. I neither want nor need moral programming imperatives handed down from above. I will write crappy code whenever I damn well feel like it. If I learn something from it, all the better. If not, well that's my choice as an adult to take that path. There is lots of talk about how, if Python had macros, everyone would create their own mini-languages and it would be a virtual Tower of Babel, etc, etc. Perhaps. But of course, given how much syntax Python has grown since 1.5 (most of which is there to compensate for statement-oriented syntax and lack of macros) I'd suggest that perhaps the tower is already being built directly into the language. As an aside, it's pretty sad when many of the c.l.lisp folks on this thread seem more polite in general than the c.l.py crowd. Lisp may have expression-based syntax and macros, but it's also got Eric Naggum. If we can't have the nice features of Lisp, let's at least not adopt its downsides. Regards, Cliff P.S. As a disclaimer, I *have* had a few beers tonight already and have, in fact, been binge-coding, so if this seems like a rant, I reserve the right to deny all knowledge of anything I may have written up to this point. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Mon, 2006-12-11 at 08:11 -0800, [EMAIL PROTECTED] wrote: Bill Atkins wrote: On the plus side, Python makes less demands on the capabilities of the editor. All you really need is block-shifting commands. Bracket matching is handy for expressions but not vital, and you certainly don't need bracket-based auto-indenting. Oh, please. So we should restrict the power of the languages we choose just to make sure that our code can be edited in Notepad? In the real world, it's a non-negligible consideration, IMO. I find myself needing to write code on machines that aren't my usual dev machine at least a couple of times a year, and not having to install a particular editor is nice (especially in terms of keeping the modifications to someone else's machine down to a minimum). It's hardly a dealbreaker for a particular language, but it's far from worthless. For the most part, editing Python isn't an issue, but I think it's a fallacy to claim that significant whitespace has no impact on editing and refactoring. There's a reason indent-region doesn't work for Python code in Emacs (and probably never will - I consider the hopefully uncommon practice of putting pass statements at the end of blocks marginally silly). There was a time (many years ago) when I used this feature of Emacs to catch indentation errors in C code. Just run indent-region on the entire file and you get a fast visual indication of where you misplaced a brace. Trying this on Python code would require you to restore from a backup file. Another example is copying and pasting from external sources (web pages for instance) where the indentation gets totally screwed. In a language with block delimiters this is fixed with a couple keystrokes in Emacs. In Python it requires manually comparing each line with the original (or typing it in manually to begin with). I *like* the significant whitespace in Python but let's not pretend there isn't at least a small penalty. And I strongly suspect Python's varied syntactical rules impose far more of a load on code editors than Lisp does (it certainly offers more opportunity for the editor to do the wrong thing). Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Sat, 2006-12-09 at 00:26 -0800, hankhero wrote: The Common-Lisp object systems has all and more OO-features, some which you never probably have thought of before. Here's one: Inheritance lets you specialise a method so a rectangle and a circle can have a different Draw method. If you wouldn't have OO you would need a function with if statements to dispatch on thing, if thing=rectange then drawRectangle if thing=circle then drawCircle. What if you want a draw method that takes a thing and a backend, then you need if statements again, draw(self,backend): if backend == postscript do one thing else do another. Maybe you can solve this with multiple inheritance, creating RectangePostscript and CirclePostscript objects. Lisp supports multiple inheritance too, but also multimethods which allow a looser coupling between objects and dispatching on all parameters, not only the first parameter (self in python speak). Just define one method draw(rectange,postscript) and another draw(rectangle, pdf) This mechanism doesn't make much sense in Python since dispatching based on type rather than on capability is considered bad in the Python world, and for good reason. The classic example is file-like objects. What if you have two methods, one that takes a file object and another that takes a string and you pass an object that has string as a base class but provides file-like capabilities? Which method should be called? Better to explicitly call the desired method. Multimethods may make sense in many languages but not so much in Python. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: profanity on comp.lang.python (was Re: Pyro stability)
On Wed, 2006-11-08 at 06:49 -0800, Beliavsky wrote: Cliff Wells wrote: The LA Times had a story that claimed that 64% of U.S. citizens use the word fuck and that 74% of us have heard it in public (I'll assume the remainder are your fellow AOL users). I expect extrapolating these results worldwide wouldn't be far off the mark (the Brits were quite successful at spreading this versatile word). If this is supposed to justify using bad language in a public forum, it is poorly reasoned. Having heard f*** does not mean they were not annoyed. 100% of people have seen trash on the street, but that does not justify littering. Poorly reasoned or not, it was clearly poorly read, since the article I mentioned also claimed that the majority of people also used the word. Odd, I'd think with your selective reading skills you'd simply be able to ignore words you don't like. Regardless, I think the idea that certain words are profanity is fairly silly. They are words. It's the meaning and intent behind them that can be offensive. If someone says fuck off then I'd expect you to be offended *since that was the intent of the message* (of course if you manage to not be offended then that makes you the better man, but apparently that's rarely strived for). On the other hand if someone says that's fucking great in a positive way and you are offended by it, well I'd say that's *your* problem and your best bet is to turn off your TV, your PC, your radio, stop reading and try to limit interactions with other people lest you be overwhelmed by how they really speak and act. If a group of people don't mind profanity, there is no harm in their swearing to each other. But Usenet is read by a wide range of people, and needlessly offending some of them is wrong. I halfway agree with you. I tend to limit my profanity in public forums and when speaking to strangers, etc. On the other hand, when in public I also expect to hear that language from others and am not offended by it. And expecting anyone to escape without offense on Usenet is pretty unrealistic. The OP used f** just for emphasis. English is a rich language, and there are better ways of doing that. Hm, lots of people disagree with you. In fact, simply because that word *does* happen to be less widely used in this group it gave it extra emphasis and was probably the most effective word he could have used in this particular instance. I don't think anyone here will have forgotten his endorsement anytime soon. Incidentally, using to disguise profanity when the intended word is perfectly understood is pretty silly too. I strongly suspect you'd be just as offended if I said f*** off as if I'd typed it out. Once again, intent and meaning are what matter rather than a particular sequence of characters. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: profanity on comp.lang.python (was Re: Pyro stability)
On Wed, 2006-11-08 at 10:12 -0800, Carl J. Van Arsdall wrote: BartlebyScrivener wrote: I agree. And Python is an extremely serious matter calling for decorum and propriety. Lol, is it really now? And I suppose its your definition of decorum and not mine right? Things like that are always relative. I think decorum would state that you should be an adult and not make a big deal out of nothing. But that's just me, and as I said, its all relative. I think you missed the irony in his statement (or perhaps confused BartlebyScrivener with Beliavsky, who was the original plaintiff). Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: profanity on comp.lang.python (was Re: Pyro stability)
On Wed, 2006-11-08 at 10:42 -0800, Paddy wrote: I too know your wrong Aahz. The written word is not the same as that spoken. People should make an effort to put across their meaning in a clear manner. If I were going to an interview I would be very careful about swearing and most likely not do it. People complain about the friendliness and tone of groups, and mention it when talking about programming languages. But of course, this was never about friendliness or tone. The person who uttered the dreaded word was actually speaking quite positively about Pyro. The complaint was about the use of a particular word, not the intent of it. Not everyone swears like Eddy Murphy in Beverley Hills Cop, and a lot of those that do, would not do so when they want to impress, or communicate with a stranger. But of course not everyone is a double-edged sword that can just as easily be turned against either party. If we limit ourselves to saying what is going to be the most palatable for the widest audience we will most likely find ourselves confined to discussing the weather. And of course, people who worry too much about impressing others rarely do. Just ask DHH of Ruby on Rails fame: http://static.flickr.com/47/127984254_ddd4363d6a_m.jpg Personally I find people trying to impose their personal beliefs on others to be at least as offensive as any particular swear word and about a million times as dangerous. P.S. I did a google search and found 540,000 hits for python in c.l.p. and only 121 for f***. thats less than one in a thousand. Lets keep it that way please. Well, I think that's a good point: the one instance we had that spawned this thread fell well within this one-in-a-thousand boundary. So there was no indication that c.l.py was in danger of turning into a sailor's bar. I'll apply an old software maxim (from sendmail?) to the topic of public interaction: Be liberal in what you accept, conservative in what you send. Applying this would suggest that both parties were equally at fault in this situation, so perhaps we can just leave it at that. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: profanity on comp.lang.python (was Re: Pyro stability)
On Wed, 2006-11-08 at 11:18 -0800, Aahz wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I'm with Beliavsky on this one. I can't see any particular reason to curse in a forum such as c.l.py. It just coarsens the discussion with no obvious positive benefit as far as I can see. Actually, I do agree that profanity should be avoided on c.l.py; what I disagree with rather vociferously is having language police like Beliavsky. I consider Beliavsky's offense far worse than the original post. I think this sums up my point of view as well (although I would have used around 3215 more words to say it). Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode/ascii encoding nightmare
On Tue, 2006-11-07 at 08:10 +0200, Hendrik van Rooyen wrote: John Machin [EMAIL PROTECTED] wrote: 8--- I strongly suggest that you read the docs *FIRST*, and don't tinker at all. This is *good* advice - its unlikely to be followed though, as the OP is prolly just like most of us - you unpack the stuff out of the box and start assembling it, and only towards the end, when it wont fit together, do you read the manual to see where you went wrong... I fall right into this camp(fire). I'm always amazed and awed at people who actually read the docs *thoroughly* before starting. I know some people do but frankly, unless it's a step-by-step tutorial, I rarely read the docs beyond getting a basic understanding of what something does before I start tinkering. I've always been a firm believer in the Chinese proverb: I hear and I forget I see and I remember I do and I understand Of course, I usually just skip straight to the third step and try to work backwards as needed. This usually works pretty well but when it doesn't it fails horribly. Unfortunately (for me), working from step one rarely works at all, so that's the boat I'm stuck in. I've always been a bit miffed at the RTFM crowd (and somewhat jealous, I admit). I *do* RTFM, but as often as not the fine manual confuses as much as clarifies. I'm not convinced this is the result of poor documentation so much as that I personally have a different mental approach to problem-solving than the others who find documentation universally enlightening. I also suspect that I'm not alone in my approach and that the RTFM crowd is more than a little close-minded about how others might think about and approach solving problems and understanding concepts. Also, much documentation (including the Python docs) tends to be reference-manual style. This is great if you *already* understand the problem and just need details, but does about as much for *understanding* as a dictionary does for learning a language. When I'm perusing the Python reference manual, I usually find that 10 lines of example code are worth 1000 lines of function descriptions and cross-references. Just my $0.02. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode/ascii encoding nightmare
On Mon, 2006-11-06 at 15:47 -0800, John Machin wrote: Gabriel Genellina wrote: At Monday 6/11/2006 20:34, Robert Kern wrote: John Machin wrote: Indeed yourself. Have you ever considered reading posts in chronological order, or reading all posts in a thread? That presumes that messages arrive in chronological order and transmissions are instantaneous. Neither are true. Sometimes I even got the replies *before* the original post comes. What is in question is the likelihood that message B can appear before message A, when both emanate from the same source, and B was sent about 7 minutes after A. Usenet, email, usenet/email gateways, internet in general... all in all, pretty likely. I've often seen replies to my posts long before my own post shows up. In fact, I've seen posts not show up for several hours. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Python extensions on Win32
For various sundry reasons, I find myself needing to deliver a Windows-based Python app. I also chose Python 2.5 for this platform. The app has several requirements, all of which are available for Python 2.5/Win32 except one: pycurl. So I decided to try building the source but as it turns out, building C programs on Windows isn't nearly as straightforward as on Linux, so I'm a bit lost. I've downloaded the free Visual C++ Studio 2005, the pycurl sources (and the requisite curl libs, etc), but pycurl insists I don't have a C compiler compatible with VC++ 2003 (which I'm assuming is what Python 2.5 is built with). So, for anyone who might know: 1) Is VC++ 2005 compatible with VC++ 2003? If not, how can someone acquire VC++ 2003 (aside from thepiratebay.org)? The Microsoft site seems to be a dead end here unless you've put out for a spendy MSDN subscription. 2) If it is compatible, is there some specific incantation needed (env variables, etc) to make pycurl use it? 3) If this is a dead-end, will mingw32 work instead (the error message from pycurl implies it might, but I have doubts)? Or will this only work with the cygwin version of Python? 4) How much alcohol will be required to forget all this when I'm done? Thanks, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python blogging software
On Wed, 2006-09-13 at 19:28 +0200, Irmen de Jong wrote: Cliff Wells wrote: I'm currently using Frog, and it's decent, but lacks some fundamental features (tags for one). Since Irmen is probably going to scrap it anyway, I'm kind of fishing about for something new. That is not really true. I won't scrap Frog. One of the reasons would be that I'm using it myself ;-) Perhaps you confused it with the possible scrapping of the Snakelets appserver it runs on? I'm thinking about rebuilding Frog on one of the more established servers such as Turbogears. But haven't had the time to start this. Yes, I saw that and took it to mean you were scrapping Frog as well (of course, if you scrap Snakelets, I suspect any new Frog would have little in common with the existing one except perhaps the moniker). BTW, I still like Frog (it's still near the top of the Python blog heap IMO), I just needed some things it didn't have. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not event-driven packages in other than the main thread?
On Thu, 2006-09-14 at 11:13 +0200, Tor Erik wrote: Hi, I've developed an application were I've used Tkinter for the GUI. When I ran the GUI in another thread than the main, it kept locking up. I experienced similar problems with Twisted. Both of these tools are event-based, so I guess that is the root of the problem... But could anyone tell me why running these in a thread other than the main one doesn't work? They probably use signals (Twisted I'm sure does) and it's documented that signals don't work with threads: http://docs.python.org/lib/module-signal.html Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not event-driven packages in other than the main thread?
On Thu, 2006-09-14 at 03:22 -0700, Cliff Wells wrote: They probably use signals (Twisted I'm sure does) and it's documented that signals don't work with threads: http://docs.python.org/lib/module-signal.html Er, specifically, they only work with the main thread. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Python blogging software
There's been a lot of blogs started in Python, but given the recent spate of web frameworks, I'm surprised that some blogging package hasn't taken front seat yet. I'm currently using Frog, and it's decent, but lacks some fundamental features (tags for one). Since Irmen is probably going to scrap it anyway, I'm kind of fishing about for something new. I've seen a few written in Zope/Plone, but they looked not quite interesting enough given the resources it would take to run them. At least two were started in TurboGears but seem to have vaporized. Anyone aware of any functional (doesn't need to be complete, beta is fine) blog software written in Python? Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python blogging software
On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote: Anyone aware of any functional (doesn't need to be complete, beta is fine) blog software written in Python? Hmph. And as soon as I hit send I find http://wiki.python.org/moin/PythonBlogSoftware Okay, so is there any *not* on that list that should be considered (and perhaps added to the list)? Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python blogging software
On Wed, 2006-09-13 at 08:22 -0700, Fuzzyman wrote: Cliff Wells wrote: On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote: Anyone aware of any functional (doesn't need to be complete, beta is fine) blog software written in Python? Hmph. And as soon as I hit send I find http://wiki.python.org/moin/PythonBlogSoftware Okay, so is there any *not* on that list that should be considered (and perhaps added to the list)? Firedrop2 is a client-side blog program (generates static HTML to be uploaded to your webserver). I looked at this but didn't care for it as it doesn't appear to allow for comments (feature-wise it's a few steps down from Frog, which I already have working). For anyone who's interested, what I finally settled on was Bitakora. It violated one of my own requirements (it runs on Zope), but because it's multiuser and quite featureful and modern, the tradeoff seemed worth it: http://www.codesyntax.com/bitakora/about I will say that installing it was something of a pain. If the Zope guys want to know why Zope has been left behind, one of the first things I'd suggest is to clean up zope.org. Bitakora has several dependencies and nearly all of the links to these dependencies led me on a wild goose chase of broken links, multiple incompatible versions, incompatible forks, etc. For those who might follow in my footsteps, the dependencies (with correct links to correct versions) are: Epoz: http://iungo.org/products/Epoz/ Localizer: http://www.ikaaro.org/localizer TextIndexNG2: http://opensource.zopyx.biz/OpenSource/TextIndexNG CookieCrumbler: http://hathawaymix.org/Software/CookieCrumbler It also depends on BTreeFolder2, but that's included in the latest Zope 2.8 series. I think the worst of all of these was surprisingly Epoz. There are at least three distinct branches of this product: the original (deprecated), it's replacement (kupu), and a fork (which happens to be the correct one). The information on zope.org gives little indication that there might be such a fork (but is quite happy to lead you in circles). I noticed that several of the products mentioned the pain of maintaining software on zope.org (and so had moved their software elsewhere), so this is probably the root of the problem. Anyway, Zope complaints aside, Bitakora is really great and I'd recommend that anyone looking for a friendly, multiuser blog take a look. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On Wed, 2006-09-13 at 10:30 +0200, Fredrik Lundh wrote: Antoon Pardon wrote: One place where I would use such a feature is in a unittest package. I think being able to write self.assert or self.raise looks better than having to append an underscore. patch here: http://mail.python.org/pipermail/python-list/2001-June/047996.html Did you happen to remember this post or is Google *really* your friend? Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
On Tue, 2006-09-12 at 13:01 +0200, Fredrik Lundh wrote: Mike Owens wrote: Crackpot? And now we get to why I took the flamebait -- wonderfully constructive comments such as this. I know SQLite's author. Besides being a nice and clearly very intelligent person, he also holds a master's degree in electrical engineering from Georgia Tech and a PhD in computer science from Duke University. His crackpot software is used by Sun, Apple, Symbian, Google, AOL, Philips, DLink, and I don't know how many other companies, not to mention countless open source projects such as Mozilla, PHP, and now Python. but is he a member of Mensa? Now *there's* a group of crackpots. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: best small database?
On Mon, 2006-09-11 at 13:23 +, David Isaac wrote: I have no experience with database applications. This database will likely hold only a few hundred items, including both textfiles and binary files. I would like a pure Python solution to the extent reasonable. Since no one's mentioned it: http://schevo.org/trac/wiki -- -- http://mail.python.org/mailman/listinfo/python-list
Re: best small database?
On Tue, 2006-09-12 at 12:29 -0700, Kay Schluehr wrote: Just one stupid remark since the limits of my language are the limits of my world: I've not the slightest association with the seemingly nonsense word buzhug and don't even know how to pronounce it correctly. Would you have the kindness to enlighten me/us ? I simply assumed it was guhzub backwards. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote: metaperl wrote: Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... You are missing the point: the point is that the above could be considered correct if the rules of Python were that an assignment statement takes IDENTIFIER '=' LVALUE Also class IDENTIFIER COLON could also be considered correct. Yes it could but it isn't and isn't likely to be. Simply do not use reserved words. That rule is hardly limited to Python. I'm surprised so many people misunderstand his complaint. It isn't as simple as don't do it. The OP is referring to autogenerated code and attributes. This means you must tell the source of the generated items (perhaps a database table) that it can't have a column named class or pass or add hacks in to work around it (an easy one would be to prefix autogenerated attributes, which also helps work around the lack of private attributes in Python). Whether or not this should be changed is tangential to the OP's point. It must be a bit frustrating to state the obvious over and over and see it misinterpreted each time. Python has shortcomings. This is one of them, whether there's valid reasons for it or not. It's better to acknowledge it and offer something useful rather than that isn't the Python way, don't do it. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: python-database
On Sun, 2006-09-03 at 21:30 -0700, sridhar wrote: is there any way to call stored procedures from python as in java? I mostly use PostgreSQL, so perhaps it's different for some other databases, but calling stored procedures doesn't require any special support from the language or driver. Usually you simply SELECT from the stored procedure. Also, you might be interested to know that with PostgreSQL you can also *write* stored procedures in Python which I consider a huge plus. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote: On 8/31/06, Jorge Vargas [EMAIL PROTECTED] wrote: On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote: Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, Untrue. Even though I don't use widgets much myself, I wanted to make sure they *could* be used with TurboStan, so I did a quick test with Kevin's autocomplete widget. Worked fine. I can't see why Cheetah would be any different. no auto-generated code What auto-generated code? The example templates that you get with quickstart? Hardly a loss. and the (incomplete) documentation won't apply anymore (it assumes Kid templates ofcourse). True. However I've had little trouble translating from Kid to Stan (and that's probably a longer jump than from Kid to Cheetah). If you use SQLAlchemy instead of SQLObject, no identity framework, Completely false. no administrative tools (tg-admin sql, True. CatWalk etc True. ) and no documentation. Partially true. The documentation exists but some of it is out-of-date and it was never very complete to begin with. Of course, like many OSS projects, the mailing list is your best resource and SQLAlchemy itself has quite good documentation. If you use prototype instead of MochiKit... I have no idea what happens You get Prototype instead of MochiKit. and using another webserver than CherryPy isn't possible right now, I guess? Not that I'm aware of. Nor do I think it would make much sense since CherryPy is the heart of TurboGears. I typically use CherryPy to serve the dynamic content and a real webserver (Nginx) to serve static files. I've never felt this was a handicap. In fact, if you decide to replace so many modules that TurboGears depend on, what do you gain in using TurboGears at all? If you got to the point where you were replacing more parts than you were using, then you'd certainly want to find a different framework as TurboGears is clearly not for you. I fail to see your point. Personally I've chosen to go a different route on a couple things and leave the rest intact. I expect most people are the same. With most frameworks, there's typically one or two things most people don't like and it's nice to be able to replace those things without a lot of fuss. I don't see how that's a liability. It seems like the TurboGears developers have a lot of work to do, (and a lot of documentation to write) if they want to make their framework as easy to use as others (ie: Django) that takes a more holistic approach. That's odd, because I've actually used both and found TurboGears far easier to get started with (no mucking about with Apache and mod_python for one thing, no need to setup explicit url regexes just to get hello, world on a page). Judging from your above comments it sounds to me like you're mostly speculating about TurboGears. TurboGears more seem to be like emacs than Ubuntu - infinitely customizable... Not quite enough IMO, but close enough. In the future both Rails and TurboGears will probably be great. But since someone mentioned Rails moving to YARV, and TurboGears moving to SQLAlchemy and Markup, it seems to me that they are both in a state of flux and not quite ready yet. TurboGears is certainly in a state of flux although from an outside (i.e. API) standpoint it's not nearly as bad as you might think from the changes that have gone on under the hood. There's been only a few breaking changes up til now (I converted a site I'd built on 0.8 to the latest SVN last night and most of the issues I encountered were with my own changes to TurboStan). Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On Thu, 2006-08-31 at 09:04 -0700, Paul Boddie wrote: SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3), CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django (0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid (v0.7.0RC4), Paste (0.4.1), web.py (.138) And ironically, the one with the *lowest* version number (web.py) is used to power some fairly large (and ambitious) public projects: https://www.youos.com/ ( see http://blog.youos.com/?p=49 ) http://reddit.com/ I'd like to claim that in OSS, version numbers mean little, but I still recall Windows NT 1.0 (er, I mean 3.1), so I guess they don't mean much anywhere. Version numbers are *picked* by project leads for varying reasons, so comparing version numbers from different projects is pretty pointless. Is Windows 2000 more stable than Linux 2.6? It ought to be since it's 769 times more mature, right? Even if you called it Windows NT 5.0, I'd have to wonder if it's even twice as stable (I'm being intentionally generous here, so bear with me). Personally I tend to look at what the users (especially former users) say about a project and what's been or being done with that project. If it seems promising, I try it. I can't think of any other reasonable way of making that decision. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: avoiding file corruption
On Sun, 2006-08-27 at 07:51 -0700, Amir Michail wrote: How often do you need to open a file multiple times for writing? How often do you write code that you don't understand well enough to fix? This issue is clearly a problem within *your* application. I'm curious how you could possibly think this could be solved in any case. What if you accidentally open two instances of the application? How would Python know? You are asking Python to perform an OS-level operation (and a questionable one at that). My suggestion is that you use a real database if you need concurrent access. If you don't need concurrent access then fix your application. As a high-level language, Python should prevent people from corrupting data as much as possible. Data is application-specific. Python has no idea how you intend to use your data and therefore should not (even if it could) try to protect you. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Out-dated compiled modules (*.pyc)?
On Sat, 2006-08-26 at 18:54 +, Dennis Lee Bieber wrote: Normally, Python compares the date stamps of the files (and maybe some internal magic values) and only rebuilds the .pyc if the .py is newer. Perhaps the OP should check both the system date on his PC and the timestamp on the pyc files in question. Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On Thu, 2006-08-24 at 04:28 -0700, Paul Boddie wrote: Cliff Wells wrote: On Thu, 2006-08-24 at 04:04 +, Tim Roberts wrote: Cliff Wells [EMAIL PROTECTED] wrote: But there are interesting things in Ruby (and Ruby 2 should take care of lots of warts Ruby 1.8 has) that Python could learn from. All-in-all, Ruby is mostly as good as Python in most ways and better than Python in a couple key ways. The big difference between Ruby and Python is the lifecycle phase that the languages/systems are in: Ruby arguably has room for a lot of basic improvements in the architecture of the virtual machine and presumably has a list of must add features that cover gaping holes with respect to certain audiences [1], whereas Python has been around for ages and has covered most of the critical gaps in the feature list (although we can always suggest things which bother our own part of the community). Whereas the Ruby people merely have to agree on how critical their missing features are and to move in one widely agreed direction, the Python people face a tougher choice as to what should be done next; strategies include a tidying-up exercise to make the language more coherent, a complete reimplementation, deep modifications to the runtime, the introduction of radical new semantics. All true, but there's a more fundamental difference that's going to show more as a larger number of people become used to Ruby's semantics: any Ruby statement can be used as an expression. This is firmly from the Lisp family of languages whereas Python's statement-based syntax is firmly in the Fortran branch. With the exception of Lisp itself, no language has seen the popularity of this style of programming until Ruby. I think this represents a real danger to Python's mindshare. Once people have tried expression-based languages, they tend to be loathe to return to statement-based languages. To date, expression-based languages have been mostly of interest in academia or to a small group of elitists and so weren't practical to use for day-to-day work. Ruby has changed that and I think we're just starting to see the fallout. Rails may have brought them there, but Ruby itself is keeping them there. My fear is that the expression-based family of languages is the Homo Sapiens to our statement-based Neanderthals and we can either evolve or disappear. Python is unique in many ways and I'd hate to see those unique features lost because we're stuck on the wrong evolutionary branch. The fewer obvious issues that a language has, the less energy there is in the community to deal with those issues thoroughly, I think. I guess the Perl community chose a bold new direction in line with the observation that a big vision can inspire much more in people than lots of incremental changes to an existing vision, but the energy required to follow through on such a vision can be immense. In addition to all this, a large existing community is more likely to want larger benefits for smaller levels of disruption because of the amount of existing code. Thus, the available energy for change is less in a mature project than in a growing project because people have to constantly monitor the breakage in their existing investments in the language. ...but you can't READ Ruby code. Yeah, that's one of the big reasons I haven't seriously considered trying it. It's expressive, got interesting features... and appears unreadable to me. I'm usually pretty good at deciphering most languages, even if I haven't used them before, but Ruby is one of the exceptions. My feeling is that I'd rather learn more about Lisp or Scheme than Ruby - the benefits are greater and for me Lisp and Scheme increasingly have the edge on readability. Perhaps I'm just not tuned in to Smalltalk-style syntaxes. I'm in the same camp. As I mentioned earlier, it's been mostly inertia and the wealth of the Python community that's kept me with Python. That's why I was so excited when I found Logix. Lisp-like features with Python's syntax that generates Python bytecode. Actually Logix is perhaps too far the other direction as it supports Lisp-style macros and the creation of arbitrary syntax, which perhaps would justify some of the fears people have of Lisp-like languages. The part I found appealing was having Python-like syntax in an expression-based language, with the capability to integrate completely with Python libraries. Absolutely the best of both worlds. I've been trying to contact the author of Logix to find out what the status of the project is or if he's abandoned it. If you haven't looked at it you really ought to. http://livelogix.net/logix/ This brings us back around to the web framework debates. For many people Ruby fits their brains and for others Python does. I think frameworks are similar. I tried Django and while I thought it was a great product, it simply didn't fit how I think about that problem
Re: Python Syntax Highlighting Module
On Mon, 2006-08-21 at 08:19 -0700, gene tani wrote: [EMAIL PROTECTED] wrote: Hello, I have an idea for a project which involves an editor that supports syntax highlighting. This would be for any language, particularly php, html, css, etc. I would like to write this program using python. It would only make sense to base this upon existing open source code. My question is there a python module or examples on how to write a code editor which supports modulated syntax highlighting? Thank you, Blaine just a *few* examples If I were to start a GUI editor project, I'd undoubtedly start by looking at Scintilla: http://www.scintilla.org/ Also see: http://scintilla.sourceforge.net/ScintillaRelated.html Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On Wed, 2006-08-23 at 02:28 -0700, Paul Boddie wrote: Cliff Wells wrote: No, the reason Rails is successful is due to being a decent, focused product with *great* marketing (screencasts, anyone?). Screencasts? Perhaps, like a great showman, they draw in the punters effectively enough, but I'd rather developers concentrate on writing decent documentation than stuffing the pipes of the Internet up with multi-megabyte proprietary blobs showing some individual developing hello world (and still having to practise slight-of-hand in order to make it slick enough). Well, I think screencasts are pretty great for this type of thing. Think about the primary complaint: Which one do I choose?. It can take a while to wade through the various documentation (or lack of), install, do some basic tests, etc and the whole process can be pretty wearing on a newcomer. A screencast on the other hand lets you lazily sip coffee while you get a small feel for the framework. I think it also shows what someone who *knows* the framework can do (which can be nearly impossible to know when you're testing it yourself). The 20 minute wiki screencast would be the 2 day trial and error for someone new to the framework. [...] Also the fact that Ruby doesn't suck isn't hurting Rails any either. If GvR wants to improve Python's status against Ruby, I suggest looking at what people are *really* raving about in the Ruby world (despite how they got there) and address those issues rather than getting sidetracked with this nonsense. First of all, I'd take the raving from the Ruby scene with a pinch of salt, given the tendency of the blog personalities doing the raving to breathlessly declare some kind of victory at every turn - as Steve Holden once said, these people are good at the don't mention the weaknesses style of marketing, and that's probably something various Python Web framework developers have picked up quite effectively. Oh sure. And you have to also remind yourself that most of these guys are coming from PHP where practically nothing sucks by comparison (and there are *lots* of PHP people to convert). But there are interesting things in Ruby (and Ruby 2 should take care of lots of warts Ruby 1.8 has) that Python could learn from. All-in-all, Ruby is mostly as good as Python in most ways and better than Python in a couple key ways. Add marketing to that (whatever kind it happens to be) and you've got the recipe for success. When I suggest using Python to customers they tend to get nervous as if it's some esoteric language that might disappear off the map next weekend and is only known to 12 people. I shouldn't need to reassure people that it is what it is: one of the most popular languages in use today. That's the other kind of bad marketing that Python should avoid. I'd rather the Python core developers stopped chasing shadows and looked at the Python distribution in its entirety. Hopefully, the Python 3000 exercise will see its focus shift into really removing the artifacts of legacy decisions in both the language and the library rather than shoehorning more wishlist items into the language. My single wishlist item (which will probably never happen) is actually the *removal* of a single feature: the distinction between statements and expressions. Forget list comprehensions, ternary operators, etc. You get them with no additional syntax in expression-based languages. I played with Logix a bit (but sadly the project appears dead) and the expression-based Python syntax it provides gives me goose-bumps. At this point in my life, inertia keeps me with Python (it's good enough and I lack the time and energy to convert to another language), but there's little doubt in my mind that this distinction will eventually force me elsewhere *wipes away tear*. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote: Alex Martelli wrote: Indeed, it has been truthfully observed that Python's the only language with more web frameworks than keywords. I have already suggested to the BDFL that he can remedy this situation in Py3k: all he has to do, of course, is to add a LOT more keywords. Here is another remedy: he adds one of the frameworks to the standard library :) That didn't help Tk maintain a monopoly on Python GUI toolkits. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On Thu, 2006-08-24 at 04:04 +, Tim Roberts wrote: Cliff Wells [EMAIL PROTECTED] wrote: But there are interesting things in Ruby (and Ruby 2 should take care of lots of warts Ruby 1.8 has) that Python could learn from. All-in-all, Ruby is mostly as good as Python in most ways and better than Python in a couple key ways. ...but you can't READ Ruby code. Yeah, that's one of the big reasons I haven't seriously considered trying it. It's expressive, got interesting features... and appears unreadable to me. I'm usually pretty good at deciphering most languages, even if I haven't used them before, but Ruby is one of the exceptions. One of the things I like best about Python is that, like Cobol, you can read Python code like prose (or poetry ;) and, for the most part, know what the code does, even without being a Python guru. I have not had the same experience with Ruby. There are special characters in there that make the program say something I can't immediately discern. There's the line noise aspect, but also some things are just expressed in what appears (to me) to be rather non-idiomatic ways. But I suppose it depends on your background. A rather brilliant friend of mine with a Smalltalk background thinks that the Ruby reads like a novel. Shrug. He also reads Japanese, so maybe that's a factor ;-) To be sure, people whose opinions I trust (one of whom is Cliff Wells) have said that Ruby is great, so I suppose I need to look again. I just haven't had the same aha! experience that I had with Python. Thanks for the vote of confidence. I have lots of opinions, but even I only trust a few of them ;-) I think Ruby has great things and I'm certain it's a great fit for many people. But I'm with you 100% on Python's readability. I just wish we could have the great things from both. This brings us back around to the web framework debates. For many people Ruby fits their brains and for others Python does. I think frameworks are similar. I tried Django and while I thought it was a great product, it simply didn't fit how I think about that problem domain. TurboGears on the other hand did, and really, it helped clarify a few things I had vague notions about. I think we'll do better not trying to shoehorn people into one or the other. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you want in a new web framework?
On Tue, 2006-08-22 at 08:15 +, Tim Roberts wrote: Ordinarily, I think the do it yourself nature of Python is a great thing, and I would never try to dissuade someone from reinventing something themselves. However, in the case of web frameworks, I believe Marc is fundamentally correct: the web framework proliferation in Python is actually doing the language a huge disservice. I disagree. Even if most of the frameworks end up being nothing more than research artifacts, the fact is they embody research. Without research the Python web framework space will be forever relegated to runner-up (and probably has-been at some point). Consider Ruby. If someone asks, I'd like to do a web site with Ruby, what should I use?, the answer comes back loud, clear, and unanimous: Ruby on Rails. Or Wee. Or Nitro. Or Nemo. Or others that are surely to be written as Ruby gains acceptance and experienced users capable of writing them. If someone asks, I'd like to do a web site with Python, what should I use?, she gets 25 different answers. Look at HTMLGen, Cheetah, WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears, etc., etc., none of which are pre-installed in the typical Linux distribution. To the non-programming decision maker, that kind of response makes Python look unprofessional -- a toy. Ruby on Rails doesn't come preinstalled either. I don't think it's appropriate (and apparently most Linux distros currently agree) to install web programming frameworks by default. I will add that at least a few distros offer TurboGears, Django and Pylons as add-ons. Now, please do not send me ugly emails accusing me of running down Python. I've been a Python believer since 1.52. I've done web sites in at least 5 of the frameworks, and I even wrote one of the wiki pages that compares web frameworks. However, it is only the fact that I *AM* a true Python believer that gave me the patience and incentive to try 5 different frameworks. If a corporate decision maker were involved, that would never happen. Python would simply fall off of the list of options, and the job would get done in PHP or Ruby on Rails. Yes, because PHP has only one web framework too ;-) I agree with Marc. PLEASE do not create yet another Python web framework. Let's pick one, and join together to turn it into the One, True, Unquestioned Web Solution. Yes, and for those of us who may not like your choice, we can move to another language or write our own, so nothing will have changed. I think the entire concept that Ruby on Rails is successful because it happens to be the dominant solution on what was previously a practically unknown language is just plain ridiculous. If that's the case then why hasn't Eiffel taken over the world? Or Lua? Or Io? No, the reason Rails is successful is due to being a decent, focused product with *great* marketing (screencasts, anyone?). We've had several good Python web frameworks for some time, but practically zero marketing (except for Zope/Plone, which as it turns out, weren't such great products, at least not for the 80% solution that Rails targets). Also the fact that Ruby doesn't suck isn't hurting Rails any either. If GvR wants to improve Python's status against Ruby, I suggest looking at what people are *really* raving about in the Ruby world (despite how they got there) and address those issues rather than getting sidetracked with this nonsense. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I do this with list comprehension?
On Tue, 2006-08-22 at 21:07 -0700, [EMAIL PROTECTED] wrote: b = [2, 4, 6, 8, 10, 12] a = [0, 1, 0, 1, 1, 0] b = [2, 4, 6, 8, 10, 12] [ j for i, j in zip ( a, b ) if i ] [4, 8, 10] -- -- http://mail.python.org/mailman/listinfo/python-list
ReStructuredText
Started playing with docutils and don't understand why the following doesn't work: from docutils.core import publish_parts t = ''' ... ... 1. this is a test ... #. this is another line ... #. oh, screw it! ... ... ''' publish_parts ( t, writer_name = 'html' ) [ 'body' ] u'p1. this is a test\n#. this is another line\n#. oh, screw it!/p\n' Why doesn't the above turn out an enumerated list? It looks like all the examples I've seen, and I've tried adding and removing blank lines around it to no avail. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: ReStructuredText
On Tue, 2006-08-15 at 09:35 +0200, Sybren Stuvel wrote: Cliff Wells enlightened us with: Why doesn't the above turn out an enumerated list? You have to indent the list: from docutils.core import publish_parts t = ''' ... ...1. this is a test ...#. this is another line ...#. oh, screw it! ... ''' publish_parts(t, writer_name='html')['body'] u'blockquote\nol class=arabic simple\nlithis is a test/li\nlithis is another line/li\nlioh, screw it!/li\n/ol\n/blockquote\n' Thanks for the response. Must be a bug in my version: Python 2.4.2 (#1, Feb 13 2006, 15:24:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type help, copyright, credits or license for more information. from docutils.core import publish_parts t = ''' ... ... 1. this is a test ... #. this is another line ... #. oh, screw it! ... ... ''' publish_parts ( t, writer_name = 'html' ) [ 'body' ] u'blockquote\n1. this is a test\n#. this is another line\n#. oh, screw it!/blockquote\n' Guess I'll stick to HTML. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: ReStructuredText
On Tue, 2006-08-15 at 16:02 +0800, limodou wrote: On 8/15/06, Cliff Wells [EMAIL PROTECTED] wrote: Thanks for the response. Must be a bug in my version: Which version of docutils you are using, in my computer is good. u'ol class=arabic simple\nlithis is a test/li\nlithis is another line/li\nlioh, screw it!/li\n/ol\n' docutils.__version__ '0.3.7' Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: ReStructuredText
On Tue, 2006-08-15 at 00:56 -0700, Cliff Wells wrote: Ah, I got it. From the docs: (Auto-enumerated lists are new in Docutils 0.3.8.) and I've got 0.3.7 Damn. Thanks for the responses. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: ReStructuredText
On Tue, 2006-08-15 at 16:10 +0800, limodou wrote: On 8/15/06, Cliff Wells [EMAIL PROTECTED] wrote: On Tue, 2006-08-15 at 16:02 +0800, limodou wrote: On 8/15/06, Cliff Wells [EMAIL PROTECTED] wrote: Thanks for the response. Must be a bug in my version: Which version of docutils you are using, in my computer is good. u'ol class=arabic simple\nlithis is a test/li\nlithis is another line/li\nlioh, screw it!/li\n/ol\n' docutils.__version__ '0.3.7' Oh, the newest version is 0.4 Yeah, right after you asked, I tried 0.4, but it failed with a traceback. I ended up installing 0.3.9 and it works fine (and didn't require the list to be indented either, FWIW). For anyone who cares, the traceback with 0.4 was: Python 2.4.2 (#1, Feb 13 2006, 15:24:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type help, copyright, credits or license for more information. from docutils.core import publish_parts Traceback (most recent call last): File stdin, line 1, in ? File /usr/lib/python2.4/site-packages/docutils/core.py, line 23, in ? from docutils import frontend, io, utils, readers, writers File /usr/lib/python2.4/site-packages/docutils/readers/__init__.py, line 15, in ? from docutils.transforms import universal File /usr/lib/python2.4/site-packages/docutils/transforms/__init__.py, line 69, in ? class Transformer(TransformSpec): File /usr/lib/python2.4/site-packages/docutils/transforms/__init__.py, line 78, in Transformer default_transforms = (universal.Decorations, AttributeError: 'module' object has no attribute 'FinalChecks' Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Thu, 2006-08-03 at 15:51 +0200, paul kölle wrote: Cliff Wells wrote: For myself, I handle user-installation of TurboGears pretty much like I do all user-installed Python packages: using setuptools. Any user who uses easy_install or 'python setup.py install' gets their packages automatically installed into a subdirectory of their home directory and that takes precedence over the system installed packages. Works like a charm. May I ask how you handle clashes with packages already installed in site-packages? Once I tried something like ~/lib/python and set up distutils accordingly, easy_install wouldn't work if the package was installed system-wide... I followed these instructions: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation So far I've had no issues with package clashes. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Thu, 2006-08-03 at 09:49 +0200, Sybren Stuvel wrote: Cliff Wells enlightened us with: 1) PostgreSQL fans are perhaps a bit paranoid about claims of MySQL being better. There used to be a tiny bit of truth in this claim for certain applications (mostly relating to performance and ease of use). I even find PostgreSQL easier to use than MySQL :) These days certainly, by quite a wide margin. Sounds like the Fox News Network to me. Some people say If that doesn't sound familiar, check out the documentary Outfoxed. My main news source on Fox remains The Simpsons. Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Tue, 2006-08-01 at 23:26 -0300, Gerhard Fiedler wrote: Or is there something in PostgreSQL that makes its users acidic? :) Well, ACID is popular in PostgreSQL circles. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Wed, 2006-08-02 at 10:46 -0300, Gerhard Fiedler wrote: On 2006-08-02 00:51:28, Conrad wrote: Which begins A few years ago Exactly. Isn't this a good start for honesty? It doesn't claim to state anything up to date. It continues I did some research, some being a very clear indicator that I didn't consider this a thorough research. From the stated results of this research it should be clear to any reasonable reader what kind of research that was. Claimed to have, seemed to have are not really expressions that try to claim more than they are. I think the communication breakdown here is two-fold: 1) PostgreSQL fans are perhaps a bit paranoid about claims of MySQL being better. There used to be a tiny bit of truth in this claim for certain applications (mostly relating to performance and ease of use). This makes them tend to read statements such as yours as an attack and so you get defensive responses. Also, comparing MySQL to PostgreSQL is a bit like comparing PHP to Python: not even in the same class. PostgreSQL users probably consider the whole comparison is a bit insulting to begin with, then to suggest that MySQL *might* be better is practically a slap in the face ;-) 2) When you qualify statements with modifiers such as some, seemed, etc, you are almost bound to be misinterpreted, since those modifiers are apparently invisible on the net. I suspect most people scan messages, taking away the main point but discarding all the nice words the writer was so careful to write. For future reference, if you don't know and intend to convey that you don't, it's probably best to end your statement (no matter how carefully qualified) with a clear statement that you are fishing for informative responses. For instance, were I to say (on this list): I've heard that Python is slow compared to PHP, and that many people recommend PHP because it's hard to find hosting for Python apps anyway., I'd probably get a nice mix of both helpful replies and extremely irritable ones, despite the fact I clearly qualified my statements. Both of those statements were at least somewhat true at one point and as such tend to invoke more passionate responses from Python proponents. On the other hand, had I appended So I'd like some other opinions because I don't know. to the end, it would probably cut the irritation down considerably (or at least be in a much more defensible position if it didn't). Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Wed, 2006-08-02 at 23:13 -0300, Gerhard Fiedler wrote: Thanks, that's one of the conclusions to which I also came. That final question was missing, even though I felt it was implied. I really had no clue that this is such a touchy subject. Every opinion in technology seems to be touchy for someone ;-) Another one is that it seems (here I go again :) that there is something like a marriage between Python and PostgreSQL (or in other words, that Python fans that develop web apps have a tendency to favor PostgreSQL). Is there something like this? (Here is the question :) I don't think so. If I had to venture an opinion, my impression has been that the MySQL/PostgreSQL division lies more along the line between web applications and other types of apps. For some reason, web people seem to either prefer MySQL or (more likely) fall back to it as a default. If there's a bias toward PostgreSQL in the Python crowd, I suspect that's due to the fact that Python's presence seems to be more weighted toward non-web programming relative to other languages (this being due to Python's general applicability, not an implication Python isn't suited for the web). Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 22:25 -0700, Luis M. González wrote: I don't have experience with Django or any other python framework, but I have used bare-bones mod_python and it rocks. I wouldn't use PSP though... It is not very polished, and they way it handles the indentation problem in python is a little bit confussing. IMHO the best way of using mod_python is with its publisher handler. It let's you code your applications in a MVC (model view controller) style. While I agree (or at least consider the point moot) that this is possibly the best way to use plain mod_python, I'd disagree that it's a good way to develop modern web applications in Python. By the time you've decided on every bit of framework to use, and made all the little decisions that go into turning a fresh, clean spot on your hard drive into an application, what you've done is reinvent TurboGears rather than develop your application. Worse, you've probably reinvented it poorly. I've done so many times and am well aware of what a time-waster it is. You say that you haven't tried Django or any other Python framework. Perhaps you should. You seem to have at least the start of the right idea about web application organization, so I think you'd be pleasantly surprised with what you'll find already done for you by the major Python frameworks and how much time you'll stop wasting on code that isn't part of your application. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Tue, 2006-08-01 at 10:41 -0300, Gerhard Fiedler wrote: On 2006-08-01 04:11:18, Cliff Wells wrote: You say that you haven't tried Django or any other Python framework. Perhaps you should. You seem to have at least the start of the right idea about web application organization, so I think you'd be pleasantly surprised with what you'll find already done for you by the major Python frameworks and how much time you'll stop wasting on code that isn't part of your application. I've checked it out quickly, and it seems that it is not possible to install e.g. TurboGears on a typical shared host -- as a normal user. You seem to run a shared hosts farm (IIRC). What's your point of view of hosting TurboGears or Django on a shared host? Is that (reasonably) possible? There's quite a few actually: http://www.turbogears.org/preview/docs/deployment/hosting.html That's just a few picks Kevin made, there are many more. As I understand it textdrive also supports TG. For myself, I handle user-installation of TurboGears pretty much like I do all user-installed Python packages: using setuptools. Any user who uses easy_install or 'python setup.py install' gets their packages automatically installed into a subdirectory of their home directory and that takes precedence over the system installed packages. Works like a charm. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Tue, 2006-08-01 at 06:38 -0700, Luis M. González wrote: Well... yes, you're right. I guess that the reason for not having used a framework already is laziness... Trust me, I'm quite familiar with the laziness problem =) I have experience with Karrigell, which rocks too, but it lacks some deployment options (no mod_python, no fastcgi, etc). And as far as I could see in the Django docs, I should learn many new things to do exactly the same, such as yet another templating language or how to map urls with regular expressions (I still couldn't wrap my head around regex... I find them very boring to learn...). But you are absolutely right. I should definetely try Django sometime. I guess I'll do it when I have a real need to do some serious web stuff. As for TurboGears, I'm not very impressed... This is a pile of different components picked by someone according to his liking, very well glued together. Althouh its quality may be good, why should I stick with a number of components chosen according the criteria of some other guy? For example, why kid instead of Cheetah? Why CherryPy? Really, it isn't that hard to install cheetah and, if you want an object relational mapper, sqlobject. Once you have them, using raw mod_python is just a pleasure. Agreed. But on the other hand, it isn't always about having the best of each (why didn't they use Twisted rather than CherryPy would be *my* question), but rather having a complete development stack that's pre-integrated and is *good enough*. And mind you, the integration work is quite substantial. Also, TurboGears has definitely proven the a rising tide lifts all boats maxim, TurboGears has marketing and community and all the projects that comprise TurboGears have benefited from it. Ultimately a framework is about helping you get *your* job done. If your job is assembling frameworks or evaluating which ORM is best, then that's no help ;-) But I suspect those people are in the minority and most people just want to get their sites done without trying to figure out which is best and then trying to figure out how to integrate that with other components. Also, TurboGears supports template plugins (I wrote one to support Nevow's Stan, and there is a Cheetah plugin as well), and work is being done to support alternate ORMs (SQLAlchemy is working now, although not all the TG addons support it yet). The goal is to at least offer people the opportunity to replace certain components in the framework if they object to some part of TG. That's not the *ultimate* goal, but Kevin is a pragmatic guy and recognizes that component bias can hurt TurboGears' adoption and so is trying to address that in some fashion. I feel I'm in front of a white clean canvas and I just start coding. I like the flexibility of being able to choose each part of my own framework. I even created a small script that does the automatic crud stuff for me (not as polished as Django for sure, but it works like a charm). Sure, and if you are doing it as a hobby, or to learn or to perhaps take over the world with a new ORM, then that's great. But if someone is paying you by the hour to develop a website for them and you are writing an ORM when there's already half dozen out there, then someone probably isn't getting their money's worth. This is the problem frameworks were meant to address: putting your focus back on your web application rather than all the details that go into it. Do you lose some flexibility? You bet. Not a lot, but a noticeable amount. Of course the flip side is that you can turn out a pretty sophisticated web app *by yourself* in a few days. I saw DHH of Ruby on Rails fame at FOSCON last year and he really impressed me with is no-nonsense philosophy about web frameworks. His approach is the antithesis of Zope, Joomla, et al. Django and TurboGears are no-nonsense in the same vein: they aren't about providing every feature under the sun or blazing performance or ultimate configurability. They are about eliminating the time-consuming details that you face every time you start a project. Anyway, there's still an issue with using these frameworks: Availability. It's very hard, if not impossible, to find a decent web host at an affordable price. Although I guess many of those who use Django, for example, run their own host. Not true. As I posted elsewhere there are many hosts who will run frameworks (I suspect the pressure of Ruby on Rails really pushed open the door). Here's a short list from the TurboGears site: http://www.turbogears.org/preview/docs/deployment/hosting.html And from the Django site: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts WebFaction (formerly python-hosting) even has a control panel that will install the framework of your choice with a mouse-click. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
RE: Static Variables in Python?
On Tue, 2006-08-01 at 07:37 -0400, Michael Yanowitz wrote: # * class BitsClass * class BitsClass (object): def __init__(self, num_bits): self.bits=[] for i in range(num_bits): self.bits.append(0) def set(self, bit_index, value): self.bits[bit_index] = value return self.bits def get(self, bit_index): if ((bit_index = 0) and (bit_index len(self.bits))): return self.bits[bit_index] else: return scenario_globals.ERROR_ def display(self): i = 0 while (i len(self.bits)): print self.bits[i], i += 1 print '\n', global the_bits the_bits = BitsClass(16) # inside another function I have: global the_bits the_bits.set(index, value) but I get back: Traceback (most recent call last): ... File scenario_sync.py, line 245, in get_discrete_data the_bits.set(index, value) AttributeError: 'DiscreteBits' object has no attribute 'set' There is I was also disappointed, I was hoping I could use BitsClass.print() instead of BitsClass.display(). class BitsClass (object): ... def __init__(self, num_bits): ... self.bits=[] ... for i in range(num_bits): ... self.bits.append(0) ... def set(self, bit_index, value): ... self.bits[bit_index] = value ... return self.bits ... def get(self, bit_index): ... if ((bit_index = 0) and (bit_index len(self.bits))): ... return self.bits[bit_index] ... else: ... return scenario_globals.ERROR_ ... def display(self): ... i = 0 ... while (i len(self.bits)): ... print self.bits[i], ... i += 1 ... print '\n', ... the_bits = BitsClass(16) the_bits.set (4, 1) [0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] Works for me. I'm not sure what 'DiscreteBits' in your error refers to. Also, you don't need to explicitly declare global variables global. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 17:12 -0300, Gerhard Fiedler wrote: On 2006-07-31 15:00:15, Bruno Desthuilliers wrote: In fact, the real question IMHO is: what would MySQL advantage over PostgreSQL be ?-) A few years ago I did some research, and the result was that while PostgreSQL was claimed to have more features and a better design, the reports of database corruption seemed to have been more frequent than with MySQL. The usual reason given was that MySQL was more mature. I assume you don't agree... :) I certainly don't. MySQL provides two different ways to corrupt your data: actual database corruption *and* data integrity corruption. You can escape the second by using InnoDB rather than MyISAM tables, but that increases your chances of the first (InnoDB not being as mature as either MyISAM or PostgreSQL). Also, saying a few years ago I did some research in software terms is pretty much equivalent to saying I don't know. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Static Variables in Python?
On Mon, 2006-07-31 at 15:21 -0400, Michael Yanowitz wrote: Is it possible to have a static variable in Python - a local variable in a function that retains its value. For example, suppose I have: def set_bit (bit_index, bit_value): static bits = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] bits [bit_index] = bit_value print \tBit Array: int i while (i len(bits): print bits[i], print '\n' Many people suggest that using a class for this is the Python idiom (and perhaps it is), but I prefer to use a decorator for adding attributes to functions in this case: def attrs ( **kwds ): ''' taken from PEP 318 ''' def decorate ( f ): for k in kwds: setattr ( f, k, kwds [ k ] ) return f return decorate @attrs ( bits = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ] ) def set_bit ( idx, val ): set_bit.bits [ idx ] = int ( bool ( val ) ) print Bit Array: for i in set_bit.bits: print i, print set_bit ( 4, 1 ) Bit Array: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 set_bit ( 5, 1 ) Bit Array: 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Static Variables in Python?
On Mon, 2006-07-31 at 13:02 -0700, Cliff Wells wrote: @attrs ( bits = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ] ) Also, IMO, it's a bit more readable to write: bits = [ 0 for i in range ( 16 ) ] which avoids the necessity of counting the zeros to know how many there are. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Static Variables in Python?
On Mon, 2006-07-31 at 13:37 -0700, Cliff Wells wrote:
On Mon, 2006-07-31 at 13:02 -0700, Cliff Wells wrote:
@attrs ( bits = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ] )
Also, IMO, it's a bit more readable to write:
bits = [ 0 for i in range ( 16 ) ]
Or even:
bits = [ 0 ] * 16
Just be careful to only use that style when the contents of the array
are non-mutable. The list comp does the right thing in that case (at
risk of going on a tangent):
Right:
bits = [ { } for i in range ( 16 ) ]
bits
[{}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}]
bits [ 0 ][ 'a' ] = 1
bits
[{'a': 1}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}]
Wrong:
bits = [ {} ] * 16
bits [ 0 ][ 'a' ] = 1
bits
[{'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1},
{'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1}, {'a': 1},
{'a': 1}, {'a': 1}]
Regards,
Cliff
--
http://mail.python.org/mailman/listinfo/python-list
Re: Static Variables in Python?
On Mon, 2006-07-31 at 15:21 -0400, Michael Yanowitz wrote: Is it possible to have a static variable in Python - a local variable in a function that retains its value. For example, suppose I have: def set_bit (bit_index, bit_value): static bits = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] bits [bit_index] = bit_value print \tBit Array: int i while (i len(bits): print bits[i], print '\n' I realize this can be implemented by making bits global, but can this be done by making it private only internal to set_bit()? I don't want bits to be reinitialized each time. It must retain the set values for the next time it is called. BTW, I'm assuming this example was contrived. In real life, I wonder why you'd ever want to use anything besides: bits = [ 0 ] * 16 bits [ 4 ] = 1 print Bit Array: print ' '.join ( bits ) Having a set_bit function seems redundant when the language syntax directly supports what you are trying to do. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 17:58 -0300, Gerhard Fiedler wrote: On 2006-07-31 17:28:00, Cliff Wells wrote: I assume you don't agree... :) I certainly don't. [...] Also, saying a few years ago I did some research in software terms is pretty much equivalent to saying I don't know. Exactly. So what's your point with this comment? My point is to stop FUD right at that comment. I don't doubt your research from a few years ago, but ancient research is entirely irrelevant for making a decision *today*. However, had I let it pass, then someone else might not make that distinction and come away with the impression that your research was somehow still relevant and that PostgreSQL is less reliable than MySQL. I stated what was my impression at the time, with the hope that others might want to comment. Thanks for the comment. You're welcome. OTOH, anybody who says I know regarding a comparison in reliability between databases must have pretty good data to back that up. Few have. Most are in the I don't know, but my impression is that ... group. Absolutely. I can only give you anecdotal evidence myself. Further, if someone were to present a whitepaper of some sort demonstrating that one is superior with regard to reliability or performance, I'd probably be highly suspect of their motives. Regardless, since my job as a hoster requires that I assist customers with database issues, I have hands-on experience with dozens of instances of each and my *very recent* experience tells me that MySQL is far more prone to database corruption than PostgreSQL. In the past 6 months, I've repaired or restored at least 4 MySQL databases (and for no apparent reason, to boot), but I've had to do the same for exactly zero PostgreSQL installs since I started hosting over 3 years ago. And just to be clear, the number of PostgreSQL installs far exceeds the number of MySQL installs. Were there equal numbers of each I'd expect even more MySQL problems. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 14:40 -0700, northband wrote: Just spoke with my department and looks like we still want to go with a server scripting method. Although MVC may be better fit, for the sake of the learning curve, we want to use a PSP style method. I'm with the others who suggest using an MVC framework. The learning curve for Django, TurboGears, Pylons, et al, is ridiculously short, and the maintainability of the resulting code is infinitely superior. Why don't you take a look at the 20 minute wiki screencast that TurboGears has and make a decision then. Although the screencast is specifically about TurboGears, a similar screencast could be made for almost any of the other MVC-style frameworks: http://files.turbogears.org/video/20MinuteWiki2nd.mov http://www.turbogears.org/preview/docs/tutorials/wiki20/index.html Developing in a PHP/ASP embedded style is an anachronism these days and for good reason. Spend a couple days learning a modern framework. The time will be well-spent and quickly made up in shortened development time and code maintainablility. So as of now we are looking at using FreeBSD, MySQL, and some form of Python that will allow us to achieve great performance serving 30million page loads / month. If I were you, I'd cease worrying about the performance of the framework itself and research caching proxies and load balancing solutions instead. The payoff in performance will be much higher and you won't have to make architectural compromises. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 15:06 -0700, northband wrote: Makes sense, I will follow your advice. Sounds like more time invest upfront will equal time saved over the long run. I am defitely interested in proxy caching and load balancing. Which do you recommend? I have used #Pound while working for a university. I currently use Pound, mostly for proxying to virtual hosts on my shared hosting systems, but for heavy page hits and dynamic content, Squid is probably of more interest since Pound doesn't do caching. Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Nuther problem with 'dive into Python'
On Mon, 2006-07-31 at 14:03 +0100, Ben Edwards wrote:
Am going through Chapter 9 - HTTP Web Services in dive into Python. It
uses the following:
data = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read()
The page no longer exists, can anyone recommend an alternative page to
use?
Perhaps any one of the approximately 100 million pages with Atom
feeds?
Google is your friend:
http://www.google.com/search?hl=enlr=lang_ensafe=offq=blog
+atombtnG=Search
Results 1 - 10 of about 105,000,000 English pages for blog atom.
Cliff
--
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
On Mon, 2006-07-31 at 21:57 -0300, Gerhard Fiedler wrote: On 2006-07-31 18:23:17, Cliff Wells wrote: My point is to stop FUD right at that comment. I don't doubt your research from a few years ago, but ancient research is entirely irrelevant for making a decision *today*. That's exactly the reason why I added this information. It might not be for you, but it is interesting for me (and might be for someone else) to see that I get a different feedback now than I got a few years ago. It tells something about the dynamic of the process that the mere status of today doesn't tell. Well, perhaps I misunderstood your intent. Sorry if I was short. Besides, claimed to have and seemed to have are not really FUD inducing terms :) Taken in a vacuum, they can certainly add to an overall negative impression. PostgreSQL, in the past, has certainly had some hurdles that made it a suboptimal choice for many people: performance and difficulty in installation and management, among other things (I've personally not had stability issues), lack of a native Win32 version, etc, have made it the runner up in deployment to MySQL. Today, that's all changed. PostgreSQL is comparable in performance to MySQL (although I expect each outperforms the other in certain areas), *easier* to install and maintain than MySQL, and its stability is outstanding. Release 8 also saw a native Windows version. For many reasons, MySQL seems to be on the reverse track, sacrificing performance, stability and ease of use in an attempt to catch up to PostgreSQL in features. Nevertheless, there remains rumors and myths that stem from those old days that cause many people to fear deploying PostgreSQL. This is part of the reason I'm always quick to jump on statements such as yours. I feel it's a disservice to the community to let those myths continue and perhaps dissuade others from discovering what is today *the* premier FOSS relational database. Anyway, I appreciate you sharing your experience (which in that area certainly is more than mine). I'm glad I was able to add to the pool of knowledge (or at least the mud puddle of anecdote). Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: code to retrieve web mail?
On Tue, 2006-08-01 at 01:47 +, John Savage wrote: I have a free web mail address and would like to use python to retrieve files that have been emailed to me. The basic code would accommodate cookies, a login name and password, then download using the full URL I can provide. From postings here I thought mechanize held promise, but I've found it to contain filenames that are invalid for MSDOS (too many characters, and/or too many dots in the name, etc.) so I have little hope that the mechanize module can be used. I'm running python2.4.2 on plain MSDOS (not windows), so would appreciate a pointer to sample code that can do the job. I know that curl has this capability, but I'll learn something by tinkering with python code. PyCurl certainly does have that capability, although the docs were practically non-existent last I looked (and I've not tried it on DOS). Still Google will help get you through it, along with the examples included with the package, and once it's working PyCurl does an outstanding job. You might take a look at Beautiful Soup for parsing the HTML once PyCurl has fetched it for you: http://www.crummy.com/software/BeautifulSoup/ Also, no matter what method you finally end up with, you'll undoubtedly need to mangle long filenames into 8.3 names, at least for attachments and the like. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: HTML library
On Tue, 2006-01-17 at 09:28 -0800, Ron Griswold wrote: Hi Folks, Can someone point me in the direction of an html library that generates html text for you. For example, if I had a tuple of tuples, I’d like a function that would create a table for me. I’ve looked through the standard library and it only seems to have html parsers. I need to go the other way ;) The two best things I know of are Nevow's Stan and XIST. Since I started using Stan, I've vowed to never write another line of XML. http://divmod.org/trac/wiki/DivmodNevow http://www.livinglogic.de/Python/xist/ Regards, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On Sun, 2005-08-07 at 06:55 -0700, Paul Boddie wrote: Eric Pederson wrote: Why is Ruby, and Ruby on Rails, getting such strong play? Relentless hype from blogging celebrities? This is certainly part of it, but I feel it ignores the much deeper reasons which are the root of this hype. I recently went to FOSCON (a free seminar coinciding with OSCON put on by the local Ruby UG here in Portland) and listened to a few presentations on Ruby and Rails by David Hansson (the creator of Rails) and others. By the end it was clear that Ruby is wonderfully suited to writing domain-specific languages (DSL) and that Rails is an excellent example of a DSL geared toward writing database-driven web applications. A friend of mine is writing a book on Rails for a large publisher and admitted to me that he barely knows Ruby (and has used Rails for only around six months). The second presentation (I don't recall the speaker's name) specifically covered metaprogramming (writing DSLs) and one of the things I found interesting was that despite Ruby having far more syntax than Python in general, the resulting Ruby-based DSLs presented had far *less* syntax than had they been written in Python. This is undoubtedly the reason why Rails is apparently completely usable even if one knows very little Ruby. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
On Mon, 2005-08-08 at 10:10 -0700, Paul Rubin wrote: Cliff Wells [EMAIL PROTECTED] writes: The second presentation (I don't recall the speaker's name) specifically covered metaprogramming (writing DSLs) and one of the things I found interesting was that despite Ruby having far more syntax than Python in general, the resulting Ruby-based DSLs presented had far *less* syntax than had they been written in Python. This is undoubtedly the reason why Rails is apparently completely usable even if one knows very little Ruby. Interesting. But if we can generalize from that, then Lisp should be ruling the web. Well, that is perhaps the other key feature: the Ruby/Rails community seems pretty friendly and eager to help people jump to their side of the fence (much like the Python community, btw), whereas Lisp community is an oxymoron. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
On Sat, 2005-08-06 at 03:24 -0700, Kay Schluehr wrote: No good news for scripting-language fans: http://www.phpmag.net/itr/news/psecom,id,23284,nodeid,113.html It didn't say what they left PHP, Perl and Python for (if you are to even believe their findings). PHP has been losing programmers in droves... to Ruby on Rails, but I'm not sure how that is bad news for scripting-language fans. Commercially funded studies are completely untrustworthy. I've seen contradictory studies published within months of each other by the same research firms - it was more indicative of a change in clientelle than anything else. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Thu, 2005-08-04 at 01:04 -0400, Mike Meyer wrote: Right. Let's go back to the original question: What's the app I use on Unix that acts like py2exe on Windows and py2app on Unix? Any archiving system can be coerced into collecting all the parts together. None of them do it automatically. That automatically makes them *not* an answer to the question. Nothing. Since it isn't all written for you it can't be done. Have a nice day. -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Wed, 2005-08-03 at 09:47 -0400, Mike Meyer wrote: Cliff Wells [EMAIL PROTECTED] writes: On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: Cliff, please quit being an ass. You keep assuming that because some tool isn't the answer to my question that I don't know about it. That's simply rude. It would be *much* more polite to ask What's wrong with distutils rather than saying So you don't know about distutils. Since you said please. I'll try to forget about the wonders of X comment you made that I found just as rude. http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. I've very familiar with distutils. It doesn't do what I asked for, in that it only bundles up *my* code. It doesn't bundle the things I depend on the way py2exe does. It's patently *not* the answer to the question I asked. It can. It isn't terrifically easy, but distutils can be used to package up 3rd party libraries, including binary libs. It can, in fact, package up any file you so desire. For those who want .deb's out of distutils, there's a PR on sourceforge that includes a patch to make it generate .debs that works quite well. I wasn't aware of that. Nice. Of course, anyone who built a .deb (or an RPM, or a port, or whatever) that bundled up everything it needed would be doing *the wrong thing*. Those formats are designed for packaging single distributions, not applications. They include dependency information that is used to fetch the dependencies and install them. From my standpoint, the problem here is that you then have to get the dependencies into the repository before you can put your application there and have it work. For instance, my port of bicyclerepairman is stuck at an old version because I haven't gotten a port PyMac accepted yet (it also has to do with bugs in the xemacs port, but that's another story). I'm surprised you haven't mentioned eggs yet. Those work across all the platforms I named. Of course, they aren't the answer to my question either, because, like PRMs et al, they only reference external dependencies, they don't include them. While this describes the general use case of RPM, you can most certainly include external dependencies. You do it by not making them external. If you need wxPython included with your app, you can build wxPython as a subtree of your project and package it that way. While wasteful of space, it is also the only sure way to make sure that your app has the correct version and all needed dependencies. This is how py2exe does it on Windows and py2app does it on Mac (they just make it automatic). People find Linux more difficult to distribute binary apps on because they try to follow the typical Linux pattern for distributing packages versus using the one used elsewhere. For binaries this doesn't work very well. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 09:45 +0200, Torsten Bronger wrote: Yes, this is what I meant with legacy code. C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Unfortunately your assertion is patently false. C and C++ are very much general-purpose languages. It is a logical contradiction to assert that Java, C#, VB and Python are general-purpose languages while C and C++ are not when the former were implemented using the latter. Being implemented in C, Python can do nothing that C cannot. It can certainly make it *easier* to do things, but it conveys no new abilities other than that of meeting deadlines ;) As an aside, I don't disagree with what I think is your main point: higher-level abstractions make more advanced ideas feasible. You simply state it far too strongly. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 20:17 -0400, Mike Meyer wrote: Um - you're not answering the question I asked. I asked What app do I use to bundle my applications for Unix, ala py2exe (or whatever it is) for Windows? You're telling me how to install wxPython on those platforms. I know how to install wxPython. What I want to know is how to build an application bundle for all those Unix systems for a Python app I use that includes wxPython - or any other third party libraries I may be using. Sorry, I assumed you'd know about distutils: http://www.python.org/doc/current/dist/ http://www.python.org/doc/current/dist/built-dist.html distutils can go so far as to build an rpm for you, but you'll need to package things like .debs yourself. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 23:47 -0700, Paul Rubin wrote: snip commentary about how Paul wants to both not install *anything* and if he does have to install something he must compile it from source because he shouldn't have had to do it in the first place therefore he needs to make it as difficult as possible and if something doesn't fit this bizarre pattern then it sucks and we should just use tkinter instead. /snip I think you are one of a kind and that any suggestions you make about what should or shouldn't be standard in Python (i.e what would be of the most use to the largest number of people) are to be taken with an extremely large grain of salt. Nothing wrong with being unique, but you just need to realize that no one else in their right mind wants to do things your way and any attempts you make to get them to do so are doomed to failure at best and ridicule at worst. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 08:53 +0100, phil hunt wrote: I was under the impression -- from reading this ng -- that wx was buggy on some platforms and less portable than Tkinter. Not true? It depends on how you define buggy and portable... also platform is up for grabs too ;) On the serious side, I expect that if you are simply counting bugs, there are probably more in wxPython. But I'd also say that when it comes to ratio of bugs to features, they are probably quite comparable, even if Tk has one bug and wxPython a hundred ;) As far as more portable, Tk probably wins hands-down. OTOH, in practice, very few people care about the platforms wxPython doesn't run on (think: GTK doesn't run there either). wxWidgets is working on a wxUniversal port which takes a similar tack that Tk does in most cases, that is, providing all of its own widgets based on drawing primitives, but I have no idea how far along that is nor how long until wxPython supports it as another target. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: python SMTP server
On Mon, 2005-08-01 at 12:28 +0200, Benjamin Niemann wrote: Cliff Wells wrote: As an aside, I will say that many SMTP servers that service home users (i.e. Comcast, et al) limit the amount of mail that you can send within a defined period. Or completely block outgoing traffic on port 25 except to their own relay... Luckily I haven't encountered this with Comcast Cable (I use my own mailserver [requires smtpauth] directly from home as Comcast seems to have issues with mail and DNS on occasion). If I ever do, I'll immediately switch to one of the local DSL providers who support Linux. Better for MTA's to block dynamic/home IP's using dnsbls than have the ISP limit what you can do with your home computer. By using a local SMTP server to proxy, your app can queue up a large amount of mail in a much shorter period. It won't necessarily go out any faster, but at least your app won't be tied up waiting for the mail to be accepted. So there is perhaps one useful (beyond learning and fun) application for using a local SMTP server. It would be interesting what the intention of the OP is. I just stumpled upon a similar problem. The prog I'm currently working on has a function to report crashes back to me. Originally these reports where sent by mail - no problem on UNIX/Linux hosts where you can assume to have a working MDA on localhost. But what to do on Windows systems?!? Ask for a SMTP server during installation? Confusing as the program itself is totally unrelated to email. In this case you _could_ deliver the mail directly to my MX host... But instead of this I installed a small CGI on my website that sends the mails to me and gets the data via HTTP POST from my app. You can also use port redirection to bypass this sort of thing. Send on port 10025 instead and direct your MTA to listen on both ports. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
On Mon, 2005-08-01 at 14:20 +0200, Marek Kubica wrote: If you already tried GIMP on Windows, better try Inkscape on Windows.. that piece of GTK software is really good. I don't do any actual work under Windows any more. My Windows VMware session is purely for testing Windows apps and websites under Exploder. However my girlfriend, while hating the Gimp (she prefers Photoshop, to put it mildly), loves Inkscape and claims it is better in many ways than Illustrator. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
On Mon, 2005-08-01 at 08:30 -0400, Ed Leafe wrote: On Sunday 31 July 2005 20:09, James Stroud wrote: No problem. But let me ask you what would *not* have disappointed you. As others have pointed out, you didn't compile the wxWidgets part of your wxPython install so as to include the stylized text control (yes, it seems silly that you should have to specify that, but that's another thread...) Should we have defensive code for every possible broken installation? We use a lot of the Python standard library modules, many dbapi-compliant modules, and, of course, wxPython. If someone mis-installs one of the pre-requisites, do you expect Dabo to catch that and present you with a diagnostic message? I'm serious here: I want to know what people consider acceptable for a software package that relies on other packages. Personally, all I expect is an obvious pointer to a mailing list and a helpful community willing to suffer NB questions (fast bugfixes is a big plus too). If that's available, I'm happy. But then I'm willing to actually work a little to get what I want. For other it seems they won't be happy unless you drive to their house and install it for them (which only seems fair, cause if you hadn't volunteered to write such crap then they wouldn't have had to be bothered with it in the first place, damn you). Maybe you wouldn't mind tidying up a bit and washing a few dishes while you're at it? Can't *quite* get this spoon to my mouth'ly yours, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Majordomo results: [UBCCS:VIRUS] Was: Returned mail: Data f
On Mon, 2005-08-01 at 06:04 -0700, [EMAIL PROTECTED] wrote: Command 'nuisance' not recognized. Hm, seemed to work anyway. -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
On Mon, 2005-08-01 at 16:21 +0200, Daniel Dittmar wrote: Cliff Wells wrote: But then I'm willing to actually work a little to get what I want. For other it seems they won't be happy unless you drive to their house and install it for them To be fair to those slothes: some of them want to write software for a commercial setting where they have to install it on other peoples machines. So it isn't just getting it to work one one own's machine. Using a specifc Python library with external dependencies means also installing and *supporting* it on a possible large set of configurations. I can understand this, but from my experience, their concerns are badly misplaced: I recently wrote a fairly sizable Python app (~8K LOC) that utilized several 3rd party python librarys: wxPython, Twisted, FeedParser, DateUtils and SQLite to name a few off the top of my head (plus I had to repackage libxml and libxslt on OS/X because 10.3 ships with broken versions :P). It ran on Windows and OS/X (and Linux, but that was never deployed as the customer wasn't interested). This was for a *very* large customer and made it to nearly 10,000 desktops. Not one complaint had to do with installation of 3rd party packages. Why? Because I *packaged* it for them. Most of the effort I put in had little to do with any 3rd party Python library but rather just the ins and outs of each platform's packaging tools (and this can be no little pain I assure you). I will also note, out of fairness, that the port to OS/X was not as pain-free as I had hoped (wxPython was fairly new to that platform and I found more than a few bugs - most of them are resolved now, because I didn't just give up when I found them, rather I reported them and drum roll they got fixed! Who would have thought?!). In short, these people's complaints reveal only two things: 1) they are hopelessly pessimistic, whether out of pure laziness, lack of experience or what I'm unsure and 2) they've never actually tried very hard or perhaps even at all. Overall that's a recipe for failure in any endeavor. As I mentioned earlier, programming is half brains and half tenacity. If you lack one or the other, your chances of success are pretty slim. The sad thing is that their ability to cling so tenaciously to such an unqualified position leaves me wondering if it isn't truly the first quality that they lack. Given how easy Python makes things, I'd hate to see how they'd fare with a *real* programming language wink. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces
On Tue, 2005-08-02 at 02:37 +1000, Steven D'Aprano wrote: there is a reason why Lisp is a niche language, with very little if any use in the commercial world. Eric Naggum? Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
On Mon, 2005-08-01 at 13:28 -0300, Jorge Godoy wrote: We can find several problems, almost all of them can be solved with the admin's creativity. import creativity Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named creativity Nope. Not included with Python. Can't be used. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
On Mon, 2005-08-01 at 10:57 -0700, Paul McNett wrote: Terry Reedy wrote: Ed Leafe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm serious here: I want to know what people consider acceptable for a software package that relies on other packages. To me, acceptability depends on the audience. Do you want to limit Dabo to professional developers comfortable with sometimes cryptic traceback messages or do you want to include people using Python as part of other activities? My concern with putting another layer on top of Python's excellent traceback mechanism is that we could screw up and hide important exceptions, or otherwise make it harder for the seasoned Pythonista to get to the source of the issue. Nothing beats those tracebacks, ugly though they may seem to a newbie... perhaps we need both methods, and to default to the nice error handler. That sounds great. And fwiw, even seasoned developers like to be pointed directly to the problem if at all possible. For instance, it may be clear from the traceback *what* the error is, but unless you RTFM or are intimately familiar with wx, you may not immediately know how to solve it. Even if the traceback ended with an appropriate link to the FAQ, that would be outstanding. BTW, I'm with Terry: these discussions have definitely convinced me to give Dabo a try. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 15:26 -0400, Mark Roseman wrote: How can I embed a browser in Tk (I mean a real browser, like Mozilla, Safari, or even Exploder)? At all? On any platform? This has always been the tradeoff for Tk. Try this as one example: http://wiki.tcl.tk/4094 Okay, I figured if any, Win32 would be the one that worked, and I even recall seeing this example at one time. However, last time I checked, this bit of code wasn't actually working (although it may have been a temporary situation). Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I'd respectfully disagree (having done large, real-world Tk apps). You're right that Tk has a slow learning curve, which makes it easy to knock out simple interfaces really quickly - and generally ones that are not too impressive looking. You can do more sophisticated ones, and ones that blend properly into the platforms you're working on - however, the amount of effort and learning curve increase substantially. This is because you end up needing to do a lot more fiddling, looking at or using any of a large number of add-on packages, etc.). Yes, this was my finding with Tk. I ended up using Pmw.MegaWidgets and a few other things to make up for deficiencies in the core library, but mostly I found a need to write highly sophisticated controls myself, many of which were simply provided by wxPython. I was spending more time writing controls than writing applications. It was kind of fun and interesting, but not very productive. This is what prompted my move to wxPython several years ago. I still believe wxPython to be a much more rapidly evolving toolkit (although my tracking of Tk has fallen to almost nil since the switch so I'm willing to stand corrected or at least leave the point open to debate). The native look-and-feel across all platforms was another big motivation, but no the primary one. Mostly I found that the steeper learning curve paid off quite well in the long run. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 13:38 -0700, Paul Rubin wrote: Peter Decker [EMAIL PROTECTED] writes: We were discussing your 'enormous pain' installing wxPython. I find it interesting that you selectively quoted part of one line of my post, Yes, the one line I quoted was the one that said most people have wxPython installed, which is a preposterous claim. The reason they don't have it installed is they don't have reason to go through the hassle of installing it, given (among other things) that tkinter is already there. If they don't want to go through that hassle, I don't see why I should want to go through it. I seriously hope you are being intentionally obtuse, otherwise your difficulties with wxPython have acquired a sharply illuminated source. It was quite clear that by saying most people he was not referring to the set of most Python users, but rather the set of most people who have tried wxPython. Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 14:13 -0700, Paul Rubin wrote: Cliff Wells [EMAIL PROTECTED] writes: Still, that leaves Linux and Mac out in the cold. But I'll admit you met my challenge. Most likely you can actually do most of the things with Tk you can with Wx, it's simply a matter of how much effort is going to be (for instance, it's certainly quite possible to embed Gecko in Tk, but I for one am not likely to be up to the task). I actually misunderstood your question about embedding a browser and thought for a while about what it would take to write or port a serious browser to use tkinter as its graphics layer. The resulting picture wasn't pretty. I wonder whether it's feasible in wxpython. wxPython has a toy HTML renderer that allows embedding wxPython widgets directly into it. If you only need simple HTML it works great. It is also possible to embed IE, Safari and Mozilla (via wxMozilla) but you lose the ability to embed the wxPython widgets). I like the idea of a browser-like portable gui toolkit. Instead of merely wrapping some other widget set, you'd write your interface as an XML file using HTML-like interface elements. You'd have callbacks on the form submit buttons and optionally on the other input elements, and you could get at the elements through the XML DOM if you were so inclined (sort of like the HTML DOM that browsers expose through Javascript). Implementations could run on top of Tk, GTK, native Windows widgets, or whatever. Actually wxPython has this today (and has had for some time): you can build your interface code in XML and wxPython will build the interface on the fly. I played with it once as a method of building a dialog editor along the lines of VB, but the project I needed it for died and I didn't have time to finish. My discovery was that it was entirely doable though, had I had time to finish. In fact, with the XRC stuff in wxPython, you can even create custom controls with pure XML. I'm not sure how great this is for hand-built interfaces (but I haven't tried), but it seems ideal for automated generation of GUI's. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 14:16 -0700, Paul Rubin wrote: Cliff Wells [EMAIL PROTECTED] writes: It was quite clear that by saying most people he was not referring to the set of most Python users, but rather the set of most people who have tried wxPython. That wasn't clear to me. If that's what he meant, he should have said so. Paul, Honestly what appears to me to be happening here is that you have found yourself assailed on all sides and are perhaps getting a bit too quick with both your reading of posts and with your replies. The end result is you end up trying to defend your earlier statements, which, due to haste, were either worded incorrectly or based on incorrect interpretations of what others have said. Then because you feel under attack you are compelled to defend those statements further, quite probably against your own better judgement. I know I've contributed plenty to this situation (and I'll also admit to having been in similar situations before, and it's a lot easier to get into this situation than to get out of it), therefore I'll make you a deal: you slow down and put a bit more thought into your replies and I'll lay off the sideways comments and cut you some slack. In fact, enough having been said, I think I'll just try to let this thread die a natural death. Deal? Regards, Cliff P.S. I would have preferred to have made this off-list, but I can't figure out how I should decipher your email address. -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 17:54 -0400, Mark Roseman wrote: I'll point out that this has been done (in fact, many times). For example: http://tkhtml.hwaci.com (Integrating Gecko in has also been done, as a side note). Interesting. Your later point about hard to find is certainly correct as my searches (albeit not as in-depth as they could have been) turned up little in this regard. While I certainly don't begrudge anyone their choice of tools, it's no surprise that someone who's become more familiar with wxPython would have an unduly low opinion of Tk. They've obviously spent more time overcoming the warts in wxPython, and wouldn't have spent comparable effort learning what it would take to overcome the warts in Tk - it just looks hopelessly flawed in comparison. Well, as was mentioned earlier (by Paul I believe), life is too short, in this case, to become expert in more than one GUI toolkit (which as a whole, are a wart on the face of programming in general, IMHO). They are highly complex and require a large investment of time regardless of which you choose. People often cite one kit as being more pythonic than another, but frankly I've yet to see one that even remotely meets that (admittedly vague) criteria. I've made my choices based on my own criteria, and certainly I would not hesitate to recommend my choices to others. Frankly most of my ire in this thread has been over things tertiary to the toolkits themselves: 1) the idea of demanding that one toolkit be the preferred way 2) dismissing without due consideration the hard work of others who have volunteered their code without demand for recompense, and 3) what I've taken (rightly or wrongly) to be deliberate obtuseness on the part of some of the participants. Aside from that, I consider the choice of GUI toolkits to be a pretty benign issue and hardly one qualifying for the level of heat we've had for the last day or so. Switch wxPython and Tk around in the above argument and I think the statements equally hold of course. Agreed. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 23:49 -0400, Mike Meyer wrote: Cliff Wells [EMAIL PROTECTED] writes: On Sun, 2005-07-31 at 14:58 -0400, Mike Meyer wrote: And what do I use to bundle my application for Unix? Most of the things I build get installed on Unix servers. You install GUI apps on Unix *servers*? Yup. Thanks to the wonders of X, I can run GUI apps on servers and have them display on my desktop. Or my OS X laptop. I normally leave a gkrellm running on most of my servers. Yes, yes. The wonders of X have been known to me since around 1992. Personally I avoid running GUI apps on my servers since they are usually unnecessary, waste memory, and if not used properly, open the door for security issues (for that matter, any extra piece of software installed opens the door for potential security issues so I tend to run stripped-down servers that only provide needed services - no fluff. Then again server is a pretty broad term. The bulk of my servers are shared and dedicated hosting environments where paranoia is rewarded. Your situation may be different). Of course, the problem under discussion isn't restricted to GUI apps. Anytime I use a third party library, I have to deal with how end users are going to get it. Absolutely. However GUI libraries tend to stick out a bit more since they tend to have a larger number of dependencies plus sheer code size and complexity makes platform-specific bugs more likely. Regardless, when you say Unix, what do you mean? You may as well say OS as this term has little meaning. Linux (which flavor)? BSD? SCO? HPUX? OS/X? Minix? Whichever way, I suspect that a bit of distutils hacking would solve your problem. I think the post I replied to covered the OS X case - there's an application bundler available for it already. Yes, I've used it to bundle wxPython apps on 10.3. I want distributions that will work on all three major BSD variants and most Linux distrubtions - in particular, anything that uses deb's, rpm's or emerge. If you want to choose one in particular, try ubuntu Linux. OpenBSD: in portage FreeBSD: in portage 386BSD: don't know... does anyone still use this? NetBSD: included AFAICT Fedora: rpms available Debian: debs available Ubuntu: included Gentoo: in portage OS/X: available on wxpython.org FWIW, much of this info I found in less than 5 minutes using Google. I suppose with a little persistence you could have discovered it for yourself. Here's your Ubuntu instructions: http://wiki.wxpython.org/index.cgi/wxPython_20with_20Ubuntu Of course, if you are distributing end-user software by requiring users to install 3rd party packages themselves, then I hope you are distributing open source software. If it's a commercial/closed-source app you'll do far better by simply packaging all the requirements into the installer and installing it within the application's directory tree (this solves a lot of problems with version conflicts and user confusion). In my experience, binary packages work best for Windows and OS/X, and source distributions work best for Linux (mostly because building packages for Linux is a varied and sometimes painful process. Further Linux truly works best as a source-based system: you cannot always depend on ABI compatibility across versions of libraries - *usually* you can but... caveat emptor). Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Mon, 2005-08-01 at 23:56 -0400, Mike Meyer wrote: I think you have me confused with someone else. I was responding to someone who was claiming that the lack of a standard enterprise strength GUI toolkit was a serious problem for Python - I disagree. I won't recap the thread, but other languages have been *very* successful without having a GUI as part of the language, all they had was one development environment distributed with a GUI. I think there's a lot of confusion in this thread. BTW, in answer to your rhetorical question about GUI's for Linux, the answer is plwm. Technically, a toolkit for building a window manager, not a GUI. But funny anyway ;) Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Tue, 2005-08-02 at 00:18 -0400, Mike Meyer wrote: Or maybe you could switch to Jython, and just use swing? Man, c.l.py is getting *mean* ;) -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
On Sat, 2005-07-30 at 20:29 -0700, James Stroud wrote: I am going to go ahead and throw out Dabo with all of the others that claim quick development of an application. You try them and then you get bugs, bugs, bugs. Or they don't compile without 16000 dependencies. Forget it. My advice is to choose something, one thing, that is REAL standard, and in the standard library (e.g. Tkinter). And go for it. Learn it inside and out--it will always be there for you. It is the green, green grass of home, not that greener grass on the other side of the hill. Don't listen to the guys that says this one is crap or that one isn't. Dropping one and learning another is just pain. I think this is a developer trick, to keep you at war with yourself. The more you have internal conflict the more you will be looking for an App framework to solve your inner problems, and that keeps these guys in business--the business of wrecking souls. Then why are you using Python at all? Shouldn't you be in the safe home of Java or Visual Basic, where standards are all you have? -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 00:59 -0400, Mike Meyer wrote: I don't particularly like Tkinter, but it seems to me that it's pretty much won. It seems to be installed on every desktop platform along with Python. That means that if I want to distribute GUI apps, I'm going to cause the least headache for my end users by writing them in Tkinter. By this argument, we should just give up and use Visual* on Windows. The least headache for end users comes from properly packaging your application. End users shouldn't need to worry about installing third party packages (or even Python for that matter). Tools such as py2exe and Inno installer make this pretty simple on Windows, and py2app on OS/X accomplishes the same. It should be irrelevant to end users what libraries or tools you use to develop the app. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
On Sat, 2005-07-30 at 16:52 -0700, Bugs wrote: Cliff Wells wrote: But how stable is GTK on systems such as Windows and OS/X? That has been what has kept me from using it. Most GTK apps I've used on Windows (including the venerable GIMP) are nowhere near as stable as their Linux counterparts (although this may not be entirely the fault of GTK). Also, GTK on OS/X requires Fink, which is a pretty hefty requirement to place on an end user. wxWidgets only uses GTK on Linux. On Windows and OS X it uses native widgets where possible. You missed my point. I'm advocating wxPython over PyGTK for this reason. I'm quite aware of how wxPython functions. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 10:01 +0200, Torsten Bronger wrote: Hallöchen! Cliff Wells [EMAIL PROTECTED] writes: [...] The least headache for end users comes from properly packaging your application. End users shouldn't need to worry about installing third party packages (or even Python for that matter). Tools such as py2exe and Inno installer make this pretty simple on Windows, and py2app on OS/X accomplishes the same. Does py2exe work for all GUI libraries? It'll highly probably work with Tkinter, and I've read that it also works with pyGTK, but does it also work with wxPython or PyQt? py2exe and py2app work for wxPython at least, not sure about the other gui toolkits. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sun, 2005-07-31 at 04:23 -0700, Paul Rubin wrote: Torsten Bronger [EMAIL PROTECTED] writes: Does py2exe work for all GUI libraries? No, it's Windows-only. However, OS'es and GUI libraries are different axes in the space of possibilities. I'm not sure what you mean. Whatever GUI library the Mac uses, py2exe doesn't work with it, since py2exe doesn't work for Macs. py2app is the py2exe equivalent for OS/X. And it works fine with wxPython as well. Regards, Cliff -- [EMAIL PROTECTED] http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists :: -- http://mail.python.org/mailman/listinfo/python-list
