Re: llvm vs. parrot
On Fri, Apr 10, 2009 at 20:16, Paul Watson wrote: > Is Parrot out of favor these days? It appears that Google is going to > use llvm. > As far as I can recall, Parrot was supposed to be an April Fools Day joke (literally) that was taken way too seriously. Parrot may had made a lot of sense years ago, but given today's compiler + language support + virtual machine technology, it seems that it has fallen behind. But that's just my $0.02 worth. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribe...@gmail.com mail: carribe...@yahoo.com -- http://mail.python.org/mailman/listinfo/python-list
Re: *.python.org broken?
I experienced the same problem here in Brazil. Tweeks ago I could not access any *.python.org site. Today I tried and it worked. The problem seemed to be limited to Python's domain because I could access every other site that I tried the same day. More info: - At least for me I didn't seem to be IPv6 related. - It failed in the same day in more than one PC, using different providers. - The domain name was resolving ok. My guess is that it was some kind of BGP failure. Perhaps the AS that hosts Python's servers injected a wrong route or someone else did, effectively stealing all the traffic for that prefix. That's more common than people realize (specially nowadays when countries such as Pakistan try to block domains by messing with BGP). Carlos Ribeiro On Sun, Jan 25, 2009 at 11:44, Cousin Stanley wrote: > > > Is anybody else having trouble accessing sites (including www, docs, > > wiki) in the python.org tree, or is it just me? (Or just .au?) > > Yes, connecting to python.org sites has been problematic > for me as well > > I don't remember when the trouble started, but it's been > problematic for at least a week or longer here > > > -- > Stanley C. Kitching > Human Being > Phoenix, Arizona > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribe...@gmail.com mail: carribe...@yahoo.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Web framework
On Mon, 14 Mar 2005 21:36:36 GMT, Lee Harr <[EMAIL PROTECTED]> wrote: > That said, how about a ZODB storage class that sits > on top of an svn store? That might be killer! I don't know very much about the ZODB, having using it very little. What you say seems to be possible -- implement the ZODB 'protocol' over a SVN backend... not sure about how things such as the authentication system would be mapped though. But it's an intriguing idea. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Web framework
On 10 Mar 2005 03:30:28 -0800, Gianluca Sartori <[EMAIL PROTECTED]> wrote: > Hi Christian, thanks for your replay. I gave a quick look at cherryPy > too, but I had the impression it wasn't enought to be used in a real > world contest. What about performances? Can I safely consider it to > develop an Intranet/Extranet? My main concern is with scalability. What > will happend if my user-base will grow? What if I had to add web > services interface (say XML-RPC or SOAP) to my application? Can I do it > in a second time without spending too much time/money? Far from true :-) A few data points (taken from http://www.cherrypy.org/wiki/CherryPySpeed): - In 99% of the cases, the answer is "this depends on your actual application code, not on CherryPy itself". - CherryPy averages 429 requests/second, in threaded mode (which includes the penalty for thread-switching), in a Pentium 1.6 Ghz, 1GB RAM, under Windows XP 2. The test was run using ab, the load testing tool from the apache project. - In practice, we found it easier to exceed available bandwidth than to exceed CherryPy's limits. With something as low as 200 requests/s one can get a few MB/s of throughput (that's measurable, but I don't have the numbers for this test; but to the math yourself, for a 10Kb page...). Of course, Intranet sites do not suffer from this problem, but the userbase is usually limited. - The worst case scenario is when one have lots of small objects to serve. This usually means static content (icons & small gif files), and can be greatly accelerated by running CherryPy under a caching frontend - either Apache, or even squid in web acceleration mode work just fine. While you are at it, check also this page: http://www.cherrypy.org/wiki/CherryPyProductionSetup -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Tue, 8 Feb 2005 11:44:10 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote: > Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > > > hassle to code, but if your application could dynamically select from > > whatever toolkit is available on the machine, you (and I should emphasis > > that this is an impersonal/generic "you" I reference) might be able to > > argue an exemption from the QT license. > > So maybe it's time to resurrect anygui, maybe in a simplified version > which can only interface to, say, PyQt or Tkinter -- 'eithergui' maybe. 'onegui' to rule them all... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Wed, 09 Feb 2005 21:56:54 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > One thing I'd like to see in namespaces is _chaining_ -- keeping each > > namespace separate but having lookups proceed along the chain. (The > > best semantics for _bindings_ as opposed to lookups isn't clear though). > > Hmm, so if it doesn't find it in the current namespace, it looks in the > parent? > > For bindings, you could just go with standard Python semantics - normal name > binding always happens in the innermost scope, so binding a name in a > namespace > should happen in the directly referenced namespace. Then you can shadow names > from outer scopes, and later regain access to them using 'del'. What does PyPy do in this case? It seems that a 'namespace' class, or at least part of its behavior, is needed there anyway... It seems to be worth checking. > Rough concept: >Have a '__fallback__'** attribute that is initialised to None >Have a custom __getattr__ that falls back to the containing namespace if > the > result is not found in the current namespace. >Have a class method which allows a namespace to be 'put inside' another > namespace. > > ** Blech. Trying to add *any* state to namespace instances is going to suck. > Maybe it would be better to just have a single __impl__ attribute and have any > implementation related variables hang off it. This could make life easier when > subclassing. I'm tempted to say update() should just ignore any field with a > leading underscore by default (then we can just use normal private attributes, > which are altered at the user's risk), but that may be too draconian. > > On a complete tangent, I thought it might be worthwhile summarising the ideas > that have come up in this thread > > - using type(self).method(self,...) as a polymorphism friendly way to > access a > class method. > > - a 'view' alternate constructor to allow manipulation of an existing > dictionary such as globals() > > - a 'record' data type that allows the use of class definition syntax for > simple data structures > > - lookup chaining, allowing fallback to an 'outer scope'. > > Even though we'll probably end up dropping the last couple as overengineering > things for the first pass, they're still interesting ideas to kick around. Another idea, maybe even more distantly related but still worthy keeping in mind: the 'named tuples' that we talked about a few months ago. It is in some sense a variation on some of the ideas presented here; it is an alternative way to build simple records or bunch-like structures. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Tue, 8 Feb 2005 12:01:23 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote: > Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > > We could use __add__, instead for combining namespaces > > > > Update already let's us combine namespaces. To create a new object that > > merges > > two namespaces do: > >namespace.update(namespace(ns_1), ns_2) > > One thing I'd like to see in namespaces is _chaining_ -- keeping each > namespace separate but having lookups proceed along the chain. (The > best semantics for _bindings_ as opposed to lookups isn't clear though). Good point. The name 'namespace' kind of imples chaining, in the usual Pythonic sense... But I feel that by splitting this into two types (namespace & bunch) we may be making things overly complicated, and losing some of the power of the argument. Again, just my $0.02 worth. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Mon, 07 Feb 2005 13:31:20 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: > Carlos Ribeiro wrote: > > On Mon, 07 Feb 2005 11:50:53 -0700, Steven Bethard > > <[EMAIL PROTECTED]> wrote: > > > >>Michael Spencer wrote: > >> > >>>We could use __add__, instead for combining namespaces > >> > >>I don't think this is a good idea. For the same reasons that dicts > >>don't have an __add__ (how should attributes with different values be > >>combined?), I don't think Bunch/Namespace should have an __add__. > > > > For entirely unrelated reasons I did it for a bunch-like class of > > mine, and called it 'merge'. For this particular application it was a > > better name than update and append, but that's IMHO. > > Did 'merge' have the same semantics as the 'update' being discussed? > That is, did it modify the first 'bunch'? Or did it create a new > 'bunch'? To me, 'merge' sounds more like the second... In my particular example it was more like the second, but it doesn't apply exactly because the goal was a little bit different; I implemented it to merge two configuration dictionaries, one being the 'base' (with default values) and the other one with values to overrride the base values. Anyway, it was just a suggestion; and while I don't think that merge really implies one behavior over the other, having it as a constructor does make sense... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Mon, 07 Feb 2005 11:50:53 -0700, Steven Bethard <[EMAIL PROTECTED]> wrote: > Michael Spencer wrote: > > We could use __add__, instead for combining namespaces > > I don't think this is a good idea. For the same reasons that dicts > don't have an __add__ (how should attributes with different values be > combined?), I don't think Bunch/Namespace should have an __add__. For entirely unrelated reasons I did it for a bunch-like class of mine, and called it 'merge'. For this particular application it was a better name than update and append, but that's IMHO. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Sat, 05 Feb 2005 15:59:00 -0500, Brian van den Broek <[EMAIL PROTECTED]> wrote: > (I'm just a hobbyist, so if this suggestion clashes with some well > established use of 'Bag' in CS terminology, well, never mind.) There's already a well know know use for the 'bag' name, including a recipe in Python. A bag is an arbitrary collection of objects. It's similar to a set. The cookbook code is at: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/259174 -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Sat, 05 Feb 2005 12:05:13 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> The type suggested in this PEP also allows a simple means of
> representing hierarchical data that allows attribute-style access::
>
> >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom')
> >>> x.spam.badger
> [2, 3, 4]
> >>> x.ham
> 'neewom'
Static nested data structures are particularly tricky to declare in
Python. Your example works, but IMHO it's rather a workaround than a
real solution. Other languages (such as Delphi) have a record type
that can be nested naturally. Nested classes in Python don't work the
same as Delphi records; on instantiaton, only the outer (parent) class
is instantiated, and the nested (children) classes stay as classes.
This can lead to subtle bugs as class attribute acesses are mixed with
instance attribute accesses with unpredictable results. I have tried
to deal with these problems on MetaTemplate, a library for
declarative-style code in Python. You can see some ideas on this page:
http://metatemplate.python-hosting.com/wiki/MetaTemplate
One of my goals was to model nested data structures as nested classes
in Python. My solution to the nesting problem involves some
autoinstantiation magic which breaks traditional semantics, but works
for the particular application ('practicality beats purity').
I'm interested to see where this will lead us. Other related problems
are named tuples, and ordered attribute access. I deal with the later
in MetaTemplate, but the former is out of scope for the library. In
the long term, I wish Python grows a true record type. The semantic
differences between records and classes are enough to justify it in my
opinion.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
On Sat, 05 Feb 2005 02:38:13 -0500, Leif K-Brooks <[EMAIL PROTECTED]> wrote: > Actually, in Python, class definitions are runtime executable statements > just like any other. You can do this: > > >>> def make_class(with_spam=True): > ... if with_spam: > ... class TheClass(object): > ...def dostuff(self): > ... print 'Spam, spam, spam, spam!' > ... else: > ... class TheClass(object): > ...def dostuff(self): > ... print "I don't like spam!" > ... return TheClass The real power of the class statement is that you can code it this way: class TheClass(object): if with_spam: def dostuff(self): print 'Spam, spam, spam, spam!' else: def dostuff(self): print "I don't like spam!" Instead of creating two classes in separate branches of the if statement, you can as well use the if inside the class statement. It's perfectly valid. Of course, one still has to feed it with the 'with_spam' argument - but if 'with_spam' is a global, or if the class statement wrapped inside a function that defines 'with_spam', it will work just as fine. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Persistence design [was: RE: OT: why are LAMP sites slow?]
On Fri, 4 Feb 2005 17:46:44 -0500, Jack Diederich <[EMAIL PROTECTED]> wrote: > On Fri, Feb 04, 2005 at 10:31:19AM -0800, Robert Brewer wrote: > > Jack Diederich wrote: > > > If there is interest I'll follow up with some details on my own LAMP > > > software which does live reports on gigs of data and - you > > > guessed it - > > > I regret it is database backed. That story also involves why > > > I started > > > using Python (the prototype was in PHP). > > > > I'd be interested, if only selfishly to hear more potential use cases > > for *my* projects. ;) > > It would be long so I'll spin it into a blog piece. They seem to be > all the rage these days *0.5 wink* A blog piece of yours truly :-) (call it a blatant plug if you want) http://pythonnotes.blogspot.com/2004/11/alternative-database-systems.html """ There was a time when a database meant a flat file, fixed record repository. Indexes were added later, bringing better performance for several tasks. During the sixties, hierarchical database systems were developed, allowing to model complex real-life structures better. Even today, old-style mainframe systems (such as IBM's IMS) are still in production, managing huge databases. SQL was only invented in the seventies, based on a mathematical formalization of high-level data manipulation algorithms. Batch processing systems read and process data in a sequential fashion, and normally do not need such abstractions. But the new generation interactive systems really needed them. And when PC-based client-server computing exploded in the 90's, SQL kingdom was started. """ ... """ In the middle of this, there is a unforeseen trend in the use of the file system as a storage medium. Yes, the file system. Guess what? Forget the FAT, please. Current file systems are much more stable and efficient than older ones. Modern filesystems are hierarchical, and can store arbitrary objects. Support for journaling, and better metadata management means that the filesystem is now a better choice for many situations. Several web publishing engines (blogs, wikis, and even full-fledged content management systems) support filesystem-based storage for text notes and documents, which were previously stored (in a hackish and haphazardous way) into DB blobs. The full filename is now a primary key, and flexible relationships between entities can be expressed as hiperlinks. """ I'm (slowly) designing a personal CMS that is intended to use Subversion as its backend, for both blog & wiki style entries. It's filesystem based, fast (the website can use the working copy for nearly everything) and allows for versioning - something that its difficult to implement properly with low-end RDBMSs. It looks promising :-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pylibpcap and multiple threads
On Mon, 24 Jan 2005 15:18:39 +0100, Örjan Gustavsson <[EMAIL PROTECTED]> wrote: > Hi All! > > Sorry if this is not the correct forum for this kind of question (I did > not find any pylibpcap related lists). > > I am trying to use pylibpcap to capture network traffic from several > ethernet devices at the same time, each nic having a separate thread > assigned to it. > > My problem is that when one thread is blocking inside pcap.loop() for > instance, it seems to have acquired the GIL, so that no other threads > can run. > > Does anyone know a way to do this with threads, or is the only way to > have separate processes for each NIC? >From the top of my head, and without any test. I did use libpcap for some stuff recently. loop() is the primitive that keeps reading and calls the callback, right? I believe that it should release the GIL in the C wrapper code, right before calling the libpcap loop implementation, and re-acquire it before calling the callback. There is a standard way to do it, that is used before blocking calls are issued (file writing, for example). If it fails to release the GIL it will block. I'm also not sure if the libpcap itself is supposed to be used this way - with multiple instances - but I assume that it should work (I never tried to open several instances of tcpdump at the same time). Also, check these links also, as they may be helpful to you: http://libdnet.sourceforge.net/ http://oss.coresecurity.com/projects/pcapy.html -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: The best way to do web apps with Python?
On Sat, 8 Jan 2005 21:11:49 +0800, worzel <[EMAIL PROTECTED]> wrote: > > What is the best way to web developemnt with Python? Is there anything close > to PHP style in-page script placement that can create and use other Python > objects? I am not really interested in Zope (I believe that is more a CMS > than anything else?) I am also looking for something a little more > structured than a series of CGI Scripts. > > While on the topic - what is the expectataion of Python for this kind of > stuff? Would one use Python for certain other things but turn to PHP for web > apps - or would one use their Python skills in place of PHP? Check CherryPy - www.cherrypy.org. It's clean, light, and best of all, includes its own webserver. You can publish a small site with almost *no* configuration effort, and you have to write *very little code*. It's also natively multi-threaded, and supports advanced stuff such as gzip compression on the fly and XMLRPC. Disclaimer: I'm a contributor to CherryPy, so I'm biased. But I had evaluated both Karirgel and Quixote before settling up on CherryPy, and I see no reason to change. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
On Sun, 09 Jan 2005 15:54:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Here's another nice one if 'where' is added to compound statements as well: > > @dbc(pre, post) > def foo(): >pass > where: >def pre(): > pass >def post(): > pass Interesting. It solves some of the issues with chosing a clear syntax for "design by contract" and other similar features that were being debated lately. I also thought about his one: ! def foo(x=calculate_default_value()): ! pass ! where: ! def calculate_default_value(): ! ... ! return -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: "A Fundamental Turn Toward Concurrency in Software"
On Sat, 08 Jan 2005 11:52:03 -0800, aurora <[EMAIL PROTECTED]> wrote: > One of the author's idea is many of today's main stream technology (like > OO) did not come about suddenly but has cumulated years of research before > becoming widely used. A lot of these ideas may not work or does not seems > to matter much today. But in 10 years we might be really glad that we have > tried. One thing that I would love to see included in Python is a native library for fast inter-process communication, including support for message passing primitives and remote object calls. I know that there are a number of offerings in this arena: third party libraries such as Pyro, message passing libraries such as the ones from ScyPy, and standard libraries such as the XMLRPC ones. The key requirements are: "fast", and "native". By fast, I mean, highly optimized, and at least as fast (in the same order of magnitude, let's say) as any other competitive environment available. By native, it means that it has to be included in the standard distribution, and has to be as transparent and convenient as possible. In other words, it has to feel like a native part of the language. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: python3: 'where' keyword
On Sat, 08 Jan 2005 12:53:05 -0500, Peter Hansen <[EMAIL PROTECTED]> wrote: > Andrey Tatarinov wrote: > > >>> print words[3], words[5] where: > > >>> words = input.split() > > > > - defining variables in "where" block would restrict their visibility to > > one expression > > Then your example above doesn't work... print takes a > sequence of expressions, not a tuple as you seem to think. I found it strange that he had chosen to make the example with "print", that is a statement. I'm not sure how could it be made to work with both expressions and statements, it just seems strange... Overall, I found the idea interesting. It seems like a obvious counterpart to "with", in the sense that both act as modifiers to the scoping rules. I think it can be made to work, and that it would lead to elegant & readable code, but there are still lots of things to consider: exception handling, fast name lookup in the "where" block, access to symbols outside the "where" block, just to name a few. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Recent infoworld column
On Sat, 08 Jan 2005 13:14:17 -0500, Peter Hansen <[EMAIL PROTECTED]> wrote: > Dwarf Electrician wrote: > > from a long time listener... > > > > http://www.infoworld.com/article/04/12/30/01OPstrategic_1.html > > Kudos for Roger Binns! >From Mr. Udell himself: """ When people talk about the heroes of open source, you tend to hear such familiar names as Linus Torvalds, Larry Wall, Brendan Eich, Guido van Rossum, Monty Widenius, Miguel de Icaza, and Rasmus Lerdorf. No question about it: These people are my heroes. But so is Roger Binns, and so are the countless other unsung heroes of open source. For solving a host of vexing problems with quiet competence, and for doing it in ways that invite others to stand on their shoulders, I salute them all. """ That's recognition. Wow. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Thu, 06 Jan 2005 22:11:22 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Carlos Ribeiro wrote: > > Couldn't a better document-writing interface be implemented? > > Such as: > http://www.python.org/moin/Documentation > > Or AMK's annotatable docs: > http://pydoc.amk.ca/frame.html Sorry, I wasn't clear. Both are clear steps in the right direction. I was thinking more along the lines of an automated document processing service, to avoid the need to install all the tools to generate the "official" Python docs (latex, sgml, etc.). One could simply "upload" a revised doc and get the processed result back. Of course, such a service can't be open to the public, but it would still be useful. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On 5 Jan 2005 19:31:53 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > John Roth: > > The bottom line is that I'm not going to be writing any > > extensive pieces of Python documentation. My time > > is better spent elsewhere. > > Well, a couple of years ago I realized that some documentation on the > MRO > was missing. I wrote a document in reST, posted here, and Guido put it > on > python.org. It was as easy as it sounds. So I don't see your problem. > > Dave Kulhman wrote some utility to convert reST in latex using the same > style of the standard library docs; I haven't used it myself, but you > may check > with him: http://www.rexx.com/~dkuhlman/ Couldn't a better document-writing interface be implemented? This is the kind of stuff Zope & Plone are used for on a daily basis; not to mention other countless web frameworks & CMS available in Python. Even a simple automated service to process & publish reST or SGML files would be better than requiring aspiring Python doc writers to install the full toolchain, as pointed out. But, whatever it is (and that's a difficult choice, politically speaking), it should be hosted on the main Python site... because that's the place where people look for info first place. > P.S. since you cite descriptors, what's wrong with Raimond Hetting > documentation? > http://users.rcn.com/python/download/Descriptor.htm > > The only problem I see is that it is not integrated with the official > docs, but this is a > minor issue, I think. The docs are great, but it took me some time to find them out after searching inside Python docs. This is not a minor issue IMHO. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Wed, 5 Jan 2005 19:25:37 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote: > Carlos Ribeiro <[EMAIL PROTECTED]> wrote: >... > > > - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than > > > Pythonwin? > > > > I would like to seee Eric3, with some polish & opensourced on Win > > (which means solving the Qt licensing problem). Perhaps someone could > > convince Trolltech to release a special Qt Win version just for it > > (Eric3). Eclipse is also an interesting approach. > > I love eric3, but if you're an eclipse fan, look at enthought's > "envisage" IDE -- it seems to me that it has superb promise. Hint noted. > > wish I could simply plug & play DBAPI modules in a totally seamlessly > > way. Anyone who tried know how far are we of this dream. > > If you manage to get there, you'll start fighting against the different > dialects of SQL supported by the various back-ends, as is well known by > anybody who tried, say, ODBC or ADO, which do manage good plug&play of > their components but still can't solve the real hard one:-( Ian Bicking's SQLObject goes a long way to solve this problem. It's a ORM, not a complete relational solution, mind you. However, while it's architecturally oriented towards solving the high-level SQL-to-object mapping issues, a good deal of time is spent solving things that a common plug & play API could solve. IOW: the hard problem really does exist. However, we never come to face it because we're still stuck in the "easy" one. :-( -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005 19:19:32 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: > > Terry> Numarray has a record array type. If there is not one publicly > Terry> available, perhaps you could write a CSV file to record-array > Terry> slurper and contribute it to the Recipes site or maybe even the > Terry> CSV module. > > -1 on putting such a beast into the CSV module, especially if, as it seems, > it would rely on something outside the core. Although I see your point, in the long term it will be required. Assuming that Numarray will, at some point in the future, be included in the stdlib... why not give these people some help, easing the integration? A recipe, or some code that can be provisionally included in Numarray itself (as a submodule), and then later migrated to the CSV module... it does make sense in the long run. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
On Tue, 04 Jan 2005 15:52:03 +, Mark Carter <[EMAIL PROTECTED]> wrote: > I'm thinking that the I-Ching is a vast untapped resource for > programming wisdom, plus it makes it funny. LOL! +1 QOTW! -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005 10:39:10 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: > #- need: a better standard ide, an integrated db interface with > #- a proper > #- set of db drivers (!!), a better debugger, a standard widget/windows > #- toolkit, something akin to a standard for web programming, better > #- documentation, a standard lib which is better organized, a > #- formalized > #- set of protocols and patterns for program construction. And an > #- interpreter which is fast enough to avoid using C or Pyrex in most > #- obvious cases. > > Let's take one by one: I'll take only a few ;-) > - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin? I would like to seee Eric3, with some polish & opensourced on Win (which means solving the Qt licensing problem). Perhaps someone could convince Trolltech to release a special Qt Win version just for it (Eric3). Eclipse is also an interesting approach. > - Integrated DB interface with a proper set of db drivers (what means the > "!!"?): What do you mean with an integrated db interface? An standard API to > access different DB engines? Something like the Database API specification > (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG > on DB at http://www.python.org/sigs/db-sig/ you may want to look at. > Regarding drivers, to what DB do you miss one? At the risk of starting a huge flamewar, let's state my opinion on this. The DBAPI itself is not a problem, despite several debates about improvements and talks about a future version 3. On the other hand, I wish I could simply plug & play DBAPI modules in a totally seamlessly way. Anyone who tried know how far are we of this dream. At the risk of sounding pessimistic, I don't see plug & play interoperability between DBAPI drivers happening anytime soon. The work is simply way too fragmented. There's no real incentive for compatibility, besides the good will of individual developers, who are always busy and also, that have to keep their own code running. The only way it will work, IMHO, is: if a single entity implements a common API, be it the DBAPI2.0 or whatever, for a sufficiently large number of existing database systems. You may call it a "imposed standard". I don't mind. But it would solve the problem. > - Standard widget/windows toolkit: More standard than Tk? I may be wrong, but I think that most business developers expect more than Tk is able to offer... Canvas is great, but anyone who used more advanced toolkits (such as the ones available on Delphi, Java, or C#) surely require a lot more. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Boo who? (was Re: newbie question)
On Mon, 20 Dec 2004 18:53:01 -0600, Doug Holton <[EMAIL PROTECTED]> wrote: > Let me say it again then, although I do not know why it threatens people > so much: the syntax of boo is indeed virtually identical to python's. > That is what I said and what is clear from the website. Doug, Boo seems to be interesting, and that's despite your insistence. If it is "virtually identical" or not is largely besides the point. Of course, you have to right the say it, as your personal opinion, whenever you wish. > I already stated that I will not mention boo again, to comply with > Fredrik's wishes and yours. I will refer to CPython, and CPython only. > But I will not be intimidated by the likes of Fredrik Lundh. Trollers > will be held accountable. If it continues at this pace, then I suggest > a weekly troll alert, to educate and prepare the so-called newbies for > the behavior that occurs on this list. At this point you crossed the line, and it was not even a fine one. It is largely off the mark. First, because having "trollers" (sic) to be accountable is not possible - unfortunately. But also, because nobody is intimidating you. More than once people have tried to call you to reason, and you keep bashing people here quite gratuitously. Doug: If anyone is fearing debate here, is you. Disagreement is natural. Be prepared for it, specially if you want to spend time evangelizing people on how great Boo is. And, as Aahz has pointed out before, please don't be afraid of spam and insert a real email address so we can at least direct our responses to you. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: MIDI library recommendations, please?
On Mon, 20 Dec 2004 19:56:30 GMT, Andrew Koenig <[EMAIL PROTECTED]> wrote: > Are there widely used and recommended Python libraries that will let me > > 1) Interpret and generate MIDI messages easily? > > 2) Allow me to select and communicate with MIDI devices attached to my > computer? I can share the results of my research on the same topic, done August this year; a little bit old but not terribly outdated. (Sorry, it's not in depth, but it may be helpful): My own notes on the topic: http://pythonnotes.blogspot.com/2004/08/implementing-real-time-midi-playback.html http://pythonnotes.blogspot.com/2004/08/guitar-midi-simulator.html Some libraries that I have evaluated: midipy http://www.josos.org/midipy/ Real time midi playback module. Not actively maintaned, but works. MIDI Stream API http://www.borg.com/~jglatt/tech/stream.htm That's the best site for MIDI information that I could found. It explains the WinAPI, and talks a lot about details of the API, and to use it. Good reading. I don't have the pointers here with me, but you can find more info on the c.l.py archives: someone posted recently (at least twice this semester) an annoucement for a Python MIDI library that could read and write standard MIDI files. Also, there is a Python program that simulates a band (a la "Band in a Box", you select the rythym & harmony sequence and it generates drums, bass line, and accompaniment). It's a cmd line tool, which means that it's probably easier to integrate or reuse the code for other purposes. BTW I followed another thread where you talk about the TI99, so I think I know what are you want to do :-). I had a similar motivation, but in my case, I started to write a guitar player simulator; it would simulate the timing of a rythym guitar as the right hand strum the strings. I would like to avoid the weird "piano with guitar sound" that happens when you simply play a chord, with all strings being strum at the same time. It's stopped now, but I keep promising that I'll finish it as soon as I can. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
On 20 Dec 2004 07:47:53 -0800, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > Bulba! <[EMAIL PROTECTED]> writes: > > "Your CherryPy powered web applications are in fact stand-alone Python > > applications embedding their own web server. You can deploy them > > anywhere you can run Python applications." - cool!! > > You might not really want a separate socket listener for each application. You don't need a separate socket listener... CherryPy is fairly easy to work with, and very pythonic IMHO. For a multi application scenario, I would recommend installing each application as a subtree of the main site: http://myserver:8000/app1, http://myserver:8000/app2, and so on. It is possible to build it in such a way that you can update a part of the site without the need to bring it down, just by reloading the module and rebinding the value stored at the cpg.root. variable. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
On Mon, 20 Dec 2004 14:20:43 +0100, Bulba! <[EMAIL PROTECTED]> wrote: > On 20 Dec 2004 04:43:06 -0800, Paul Rubin > >I'd try to make it web based unless > >there's a good reason not to. > > Reason 1: It would be somewhat complex to develop it using > PHP (I have done some recon in that area) and using GUI > on Windows is actually faster way of entering and editing data > than via the Web browser I think. > > Reason 2: I don't want to learn yet another language > just for this app and want to avoid integration problems > as we plan to develop yet another application for other workers > that would connect to the common DB and sent the data directly > for that accounting app. Two good reasons indeed. There are some types of data entry tasks that don't map well to the browser. Rich grid style data entry just comes to mind, it requires a ton of Javascript code, not to mention XMLRPC, if you want it to be dynamic and responsive. But if the data entry forms are simple, I recommend you to check some lightweight approaches for Web development in Python. I personally used CherryPy (www.cherrypy.org); you can also check Quixote or Snakelets. All three are much lighter than Zope. CherryPy in particular is extremely light and easy to work with, and includes a reasonably powerful embedded Python-based webserver; it's not Apache, but it's much easier to set up. And all three options are free. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python mascot proposal
On Thu, 16 Dec 2004 11:51:18 -0500, Peter Hansen <[EMAIL PROTECTED]> wrote: > EP wrote: > >>It's a great marketing idea. There was a thread recently on Python-dev > >>that started with a message from Guido, where he talks about a > >>seemingly persistent perception that exists in the specialized press > >>regarding Python as a flexible, nice, but generally slow (or slower > >>than the alternatives) language. > > > > Perception of the press: Python is "flexible, nice, but generally slow" > > Which press? I know lots of programmers who have religious issues > about (against) Python believe this, or claim to, or want to, but > I haven't seen a lot of "press" coverage of Python's supposed slowness... > > Or was this just a guess on your part? Check Guido's original message on the topic, you can find it on python-dev articles. It`s recenet -- possibly less than one week old. He seemed to be sincerely concerned about it, having read an article published at some prestigious academic journal (something from ACM or IEEE, I think). If the BDFL wrote it, what more can I say? ;-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python mascot proposal
On Thu, 16 Dec 2004 07:42:38 GMT, Dimitri Tcaciuc <[EMAIL PROTECTED]> wrote: > Hm, interesting. So I'm hearing lots of different opinions here, but it > seems like there's not too many radical thoughts about not using snake > at all and it can be pretty much summed up to 2 things > 1) use a snake > 2) combine snake with -some- monty python's symbolic +1 on both counts. > I personally totally like the thought of calling the snake Monty, I > couldn't even think of any other alternatives. +1 too. > But before pushing forward any particular design, maybe it will make > sense to make some sort of official logo contest on Python's main > website and post it on /. ? It's a great marketing idea. There was a thread recently on Python-dev that started with a message from Guido, where he talks about a seemingly persistent perception that exists in the specialized press regarding Python as a flexible, nice, but generally slow (or slower than the alternatives) language. The thread ended up as a discussion about Python marketing & advocacy in general. So I think that the timing is good. But on the other hand, making this into a open contest takes more than a simple announcement on Slashdot. Some things need to be arranged first: 1) Our vote may count, but Guido's opinion not only count, it's decisive. So I believe that's better for we to hear his opinion before we even start talking about it seriously. 2) The folks are python-dev are much more involved with Python than most people that gather around comp.lang.python. Their opinion is also important. However, to announce it on the python-dev list out of the blue is not a good idea; the list is highly focused on Python development issues, and is not the place for this discussion. I would prefer that some senior member (Guido himself, or some of the other old-timers) did the announcement on Ptyhon-dev, if only to make people know about it. 3) Finally, if there's a competition, there must be a decision process. It may be democratic voting, it may be a comitee, it may be Guido's opinion, I don't know. But the conditions need to be clear from the start. > That should be a better option, since there obviously are waaay more > great artists out there than the ones that somehow got on these > newsgroups :) > > So the question is, how can this be arranged? I am pretty new to Python > in general, so I don't know how this community's clockwork is arranged > and who to contact about that. I don't know... posting it on Python-dev would raise the attention of some folks, but may bother others, as this is really off-topic there. As far as I know, Python does not have a official contact for marketing issues. Maybe if just need to keep going with the discussion here, until someone who really knows the Python Ways "buys" the idea. And finally, Dimitri - congratulations for the design, but most important, for the attitude. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Flow based programming & python coding style
On Wed, 15 Dec 2004 15:16:44 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: > > > On Wed, 15 Dec 2004 12:30:07 -0200, Carlos Ribeiro <[EMAIL PROTECTED]> wrote: > >Hi, > > > > A friend of mine passed me some links about a great concept (not new > > in fact, only new to me): > > > > -- http://www.jpaulmorrison.com/fbp/ > > -- http://c2.com/cgi/wiki?FlowBasedProgramming > > > > I found many of the explanations and examples strangely familiar. The > > C2 Wiki contains a good discussion that draws parallels between FBP > > and functional programming, although Paul Morrison is quick to point > > ou the differences. It also strikes me how much of this "paradigm > > shift" can be readily embodied in Python by using generators. > > Continuations provide a better conceptual fit. Generators > are extremely inconvenient to nest (not to mention the numerous > difficulties with them, such as poor toolchain support). While > they are certainly handy here and there, their limitations become > apparent in almost any non-trivial application. Other languages > (and other implementations of Python) go a lot further towards > making "flow based programming" natural. I think that generators are just one more step in the process towards a not-so-far in the future "Stackless-like" Python. I sincerely believe that Stackless (with support for continuations & related features) is one of the great driving factors behind many of the improvements in this arena (the other being functional programming in general). In this regard, Python comes up surprisingly well armed. It already supports several styles: imperative, functional, procedural, object-oriented, and now, some idioms for data-centric programming. The language managed to cover it all in a surprisingly clear & concise environment. I believe that the native support of flow-based friendly techniques is a good step; and more than this, I believe that it will change the way Python code is written. But that's really just my opinion, and everyone is entitled one, right? -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Flow based programming & python coding style
Hi, A friend of mine passed me some links about a great concept (not new in fact, only new to me): -- http://www.jpaulmorrison.com/fbp/ -- http://c2.com/cgi/wiki?FlowBasedProgramming I found many of the explanations and examples strangely familiar. The C2 Wiki contains a good discussion that draws parallels between FBP and functional programming, although Paul Morrison is quick to point ou the differences. It also strikes me how much of this "paradigm shift" can be readily embodied in Python by using generators. Since being introduced in the language, generators have been slowly but surely making it into applications. To properly use generators involve a big paradigm shift. Generator-based applications are async in nature; they read & consume data in small chunks (iow, are data-centric), are more responsive (because they tend to have a quicker "setup time" to retrieve initial results), and have a big potential to greatly minimize the memory requirements of an application. If properly written, I'm sure they can also show a performance improvement. I think that, as generators get more and more accepted as "standard" practice for Python programming, we will see a shift towards a "Flow Based Programming" style; or at least, to a more data-centric view of applications. I wonder how much of an impact this will have in the "marketing" perception of Python. I personally believe that this may represent a big opportunity for Python, specially with a good business framework to support its application. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Help beautify ugly heuristic code
On 8 Dec 2004 15:39:15 -0800, Lonnie Princehouse <[EMAIL PROTECTED]> wrote: > Regular expressions. > > It takes a while to craft the expressions, but this will be more > elegant, more extensible, and considerably faster to compute (matching > compiled re's is fast). I think that this problem is probably a little bit harder. As the OP noted, each ISP uses a different notation. I think that a better solution is to use a statistical approach, possibly using a custom Bayesian filter that could "learn" a little bit about some patters. The basic idea is as follows: -- break the URL in pieces, using not only the dots, but also hyphens and underscores in the name. -- classify each part, using REs to identify common patterns: frequent strings (com, gov, net, org); normal words (sequences of letters); normal numbers; combinations of numbers & letters; common substrings can also be identified (such as isp, in the middle of one of the strings). -- check these pieces against the Bayesian filter, pretty much as it's done for spam. I think that this approach is promising. It relies on the fact that real servers usually do not have numbers in their names; however, exact identification either by a match or a regular expression is very difficult. I'm willing to try it, but first, more data is needed. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
On 06 Dec 2004 10:09:25 +0100, Jacek Generowicz <[EMAIL PROTECTED]> wrote: [great explanation about function descriptors] Thanks. Now I know more about function descriptors than I ever wanted to :-) With a little polish, this post would make a great addition to the descriptors documentation, don't you think? -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Quixote+Nevow+LivePage
On 6 Dec 2004 01:15:35 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I m still without any helpful answers. I'm sorry to hear that. There were some answers (including mine) that may have not solved your problem, but at least we did try. That's the best one can ask far while posting on a public forum. My last attempt at answering your question is: LivePage was designed to work with Nevow+Twisted. I never tried to used it myself. There are some indications that it uses non-http transport for the "live" stream. If this is true, then it will only work with Twisted. I know that a similar trick can be implemented in other systems but that it requires a lot of clever Javascript & XMLRPC code. I'm studying this problem because I want to implement a solution for CherryPy, but there's not any guarantee about it, because it's something that I'm doing on my "copius" free time. Please don't hold your breath for it. If that's not helpful to you, I'm sorry. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: string slicing
On Sun, 5 Dec 2004 17:07:47 +0100, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > a suggestion: if you really want to be productive in python, forget about > "is" for a while. good code doesn't copy stuff much, either, by the way. > python's all about objects, and things that hold references to objects. I believe that the "is-obsession" has its roots on the old C-ish confusion about comparing pointers vs. actual contents pointed by them. That's about the same here, except that Python isn't C, and that object references in Python behave in a sane way :-) making "is" unnecessary most of the time. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Quixote+Nevow+LivePage
On Sat, 04 Dec 2004 16:17:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: > I haven't used LivePage myself, but someone in the know tells me > that LivePage requires an extra, non-HTTP connection to operate, so > will pretty much only work with Twisted. The basic technique is to use a "persistent" & hidden client-side frame that holds the JavaScript glue code. This code is not reloaded; it talks to the server using XMLRPC, which is an extension that is supported by many HTTP servers, and then uses the data to update the view (that is in another frame). A clever hack -- a "client-pull" model at its best. IOW: as far as the server is concerned, if it supports XMLRPC, then it's possible to implement something similar to LivePage. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Quixote+Nevow+LivePage
On Sat, 04 Dec 2004 17:46:02 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: > On Sat, 4 Dec 2004 15:40:44 -0200, Carlos Ribeiro <[EMAIL PROTECTED]> wrote: > > > >On Sat, 04 Dec 2004 16:17:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: > > > I haven't used LivePage myself, but someone in the know tells me > > > that LivePage requires an extra, non-HTTP connection to operate, so > > > will pretty much only work with Twisted. > > > > The basic technique is to use a "persistent" & hidden client-side > > frame that holds the JavaScript glue code. This code is not reloaded; > > it talks to the server using XMLRPC, which is an extension that is > > supported by many HTTP servers, and then uses the data to update the > > view (that is in another frame). A clever hack -- a "client-pull" > > model at its best. IOW: as far as the server is concerned, if it > > supports XMLRPC, then it's possible to implement something similar to > > LivePage. > > LivePage is more about server-push than client-pull. Strange, but when I was writing my own message, i *did* use "server-push", at first, but then stopped -- it's really client-pull, only that the client does it automatically. Client-pull is simple: the JavaScript code simply fetches data from time to time, or when some other kind of event happen. Said that, a disclaimer: I'm just starting to study these tricks, so my knowledege about it is far from definitive. For example: I'm not sure if you can leave an open socket in the JavaScript code and wait for the server to send more data to you in a server-push manner. Perhaps you can do it using an persistent HTTP connection... but I'm not sure if this will work with XMLRPC. I guess no, but I may be wrong. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: HTTP response code
On Fri, 3 Dec 2004 17:28:43 -0200, Jonas Galvez <[EMAIL PROTECTED]> wrote: > Hi list, here's a question about urllib. Is it possible to simply > retrieve the HTTP responde code for a given URL? I don't want to > download the body of the HTTP message. I simply want to check the > response code, like, if it is 200, 301 etc. Something like: > > if urllib.urlopen(the_url).response_code == 200: > # ... > > Is there an easy way to do this? > Should I be using urllib2 instead? Jonas, check this link: http://mail.python.org/pipermail/web-sig/2004-September/000814.html There was a discussion on the WebSig about adding support for HEAD requests on urllib2 (they were still not implemented at that time, three months ago). Perhaps there is a patch somewhere for it... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Audio interviews of Guido or other Python advocates?
On Sat, 4 Dec 2004 18:04:36 +0100, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Dave Benjamin wrote: > > > I looked around for recordings of Guido, but couldn't find any. Does anyone > > know of any streamable audio (or video) interviews or speeches featuring > > Guido, the bots > > a bot-owned horse is featured on this DVD: > > http://www.discshop.se/LIVE/shop/ds_produkt.php?lang=&id=39726 > > Nice to see that you didn't lose your sense of humour. BTW, do bots have a sense of humour? :-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
On Fri, 03 Dec 2004 08:58:48 -0500, Istvan Albert <[EMAIL PROTECTED]> wrote: > On the other hand, it would be nice to have a module that > implements various design patterns. The Bunch, the Borg, the Null, > the Proxy all nicely documented tucked away in their separate > module. That would feel a lot less like littering the standard name space > with an class that just "seems" to be useful. Great idea. I have explored some ideas relating generic objects with "standard" patterns, namely "observer" & "proxy". One of the applications of generic objects is to allow for data sharing between objects of different classes that happen to share a few attributes; sometimes it's not possible to pass the entire object around for the other one to copy the data, either because of safety reasons, or because there is some slightly mismatch between the interfaces. The generic, in this case, can be implemented either as an intermediate storage structure (as a data-only records) or as an "proxy" that exposes only the desired attributes. In this case, data is passed around and copied manually, using the generic (or the "proxy" object). Another use case is when one wants to implement the "observer" pattern (which would allow for a "live" data sharing). One alternative is to use a "generic" as the base "observable' object; other objects can register with the generic and simply receive notifications, or even share the references to its internal attributes (btw, Python descriptors & properties are incredibly useful in this case). Extending it even further -- the observed object could accept modifications from its observers, although in this case we're already talking a about more complex pattern than the standard "observer" (btw, how is it called?). -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
On Fri, 03 Dec 2004 07:41:59 -0500, Steve Holden <[EMAIL PROTECTED]> wrote: > Next question: bunch is a cute name, but not very suggestive of purpose. > Who can think of a better one? "Better"is highly subjective in this context. There are several alternatives: Bunch Generic Record DataRecord I use "DataRecord" in my own code, because it's readable and makes it clear that it's not a full fledged class, but a data-only structure. Given my Pascal roots, I'm also fond of "Record". But given that many people actually loathe Pascal (probably for reasons deeply rooted in a bad academic experience :-), that may be a big "turn off". -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: module imports and memory usage
On Tue, 30 Nov 2004 16:46:43 -0500, Brad Tilley <[EMAIL PROTECTED]> wrote: > I discovered that when I wrap my code up in a function def and call it > that it uses around 4.6 MB of RAM all the time... even while sleeping. > However, when I don't put it in a function def it uses around 2.6MB of > data when it executes and only 100KB while sleeping. Why is this? Totally unchecked, popped up from somewhere between my ears. Is it possible that (in some situations) the function object keeps a reference to its locals() somewhere, in such a way that it never gets collected? Just wondering... -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP generic objects
On Tue, 30 Nov 2004 22:30:21 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The proposed use cases sound more appropriate for a "named tuple" than any > sort > of dictionary. (This may have been mentioned in previous discussions. I wasn't > keeping track of those, though) I agree with it. I was involved in that discussion, and got the the point of listing a few desired features. As I am currently involved into other project, I left it as it was, but I'll resume working as soon as I can. I really think that both (generic objects and named tuples) are slighly different but still very similar approaches to the same problem, so some sort of "unification" of the efforts may be interesting. But there's something more important: while reading this document, and some of the replies, it became clear that the main point is to understand whether this proposed feature (in any possible implementation) is in fact useful enough to deserve a place in the standard library, and also if it represents a good coding style. With some risk of being way too simplistic, it's something like this: -- The people that is favorable to this implementation argue that one should not be required to create a new class just to return a bunch of results. -- The people that is against it point out that, as soon as you start returning multiple values, it's probable that you'll need to implement a class anyway, so it's better off to do it sooner and forget generics (or named tuples) entirely. I see some parallels between this discussion and another one about polymorphism. It's considered good Python practice to rely on interfaces, or protocols, when designing the call signature of a function or method. So if you receive an arbitrary object, you should not check if it's a descendand of some abstract parent type; that's just too rigid, and forces people to deal with complex multiple inheritance stuff, and that's really not needed in Python. There is a better way: just check if it exposes the desired interface, or protocol. The adaptation framework (as described by PEP 246, and extended by the PyProtocols package) is a nice implementation of this concept. A "generic" return object is just like this, but for a different scenario: an adaptable return value, that doesn't enforce a class signature when assigning the return value of a function or method. It's perfectly symmetrical to the usage of interfaces on call. I think that's a better, and much more powerful argument for the implementation of a generic class, and also, for some supporting machinery for it. Extending this reasoning, generic return objects (implemented either as dictionary based, or as named tuples) could be seen as "adaptable" return values. Upon return, one could get such a temporary structure and assign its members into another, more complex class, that would accept fields of the same name, but possibly include other fields and extra functionality. For example: a function that returns a complex time structure does not need to return a "time class". It may return a generic, or named tuple, which is in turn can be assigned to an object that exposes a 'compatible' assignment interface. This assignment can be done by a method of the generic clas itself, according either to the names of the member of the generics, or the order of the tuple, depending on the scenario. For now, that's all that I have to contribute into this discussion. There's also a lot of stuff in the c.l.py archives regarding named tuples and also generics that is surely worth checking. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
