Re: Cheat sheet
Riccardo T. wrote: > > > I wrote a little cheat sheet for this wonderful language, but because of > my still little experience with it, I would like to have a feedback > Could you have a look at it and tell me what do you think about, please? > > http://greyfox.imente.org/index.php?id=73 > > -- > GreyFox Nicely done! I would suggest you put your website address on it and a revision number so that as it gains use on te web, people can find the "latest" version. -- http://mail.python.org/mailman/listinfo/python-list
Information on PyGMT?
Hello - I'm seeking info on the PyGMT python wrapper for the Generic Mapping Tools package. Unfortunately, the only site (forge.nesc.ac.uk) that seems to offer the code (written by Magnus Hagdorn) is not responding. I don't know if that's a temporary condition or if that site is out of commission. Google isn't revealing much recent discussion either which is sad, as I would imagine this to be a valuable tool! Can anyone shed any light?? Better yet, does anyone have the latest tarball, and an FTP site they can offer it on? :) Many thanks! Alaric -- http://mail.python.org/mailman/listinfo/python-list
Re: Information on PyGMT?
In article <[EMAIL PROTECTED]>, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > -On [20080104 04:11], Alaric ([EMAIL PROTECTED]) wrote: > >Unfortunately, the only site (forge.nesc.ac.uk) that seems to offer the code > >(written by Magnus Hagdorn) is not responding. I don't know if that's a > >temporary condition or if that site is out of commission. > > > >Google isn't revealing much recent discussion either which is sad, as I > >would imagine this to be a valuable tool! > > I am not sure how appropriate > http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/gmt/gmt-src/doc/html/ > public/gmt.gmt-module.html > might be? > > I cannot find Magnus' PyGMT-0.2 tarball anywhere, sorry. Many thanks! I was aware of that package, which seemed to be a less complete approach, but the good news is that the NESC site came back up! -- http://mail.python.org/mailman/listinfo/python-list
Re: Pycon disappointment
In article <[EMAIL PROTECTED]>, Bruce Eckel <[EMAIL PROTECTED]> wrote: > If the following seems unnecessarily harsh, it was even more harsh for . As a relative noob to the Python world, (and lurker to the list :) ) I can't speak to differences from previous years. However, my impressions as a first-timer are much in alignment with you Bruce. Many lightening talk seemed to me to be more about recruiting than selling though. Whereas I might have been discovering a vendor for the first time in a lightening talk, it wasn't a particularly good use of my time here. I'll FIND the commercial vendor, because, if they have a good product, word will get around, aided by their web presence, and formidable advertising budget. On the other hand, bleeding edge use of Python in a lab on a distant continent (just for example) is going to be much harder to both discover, much less get the added bonus of face-to-face time with the developer! That said, I thank the organizers, and welcome the new friendships made at this event, and hope like hell I can come next year!! Alaric -- http://mail.python.org/mailman/listinfo/python-list
A "roadmap" for ctypes wrapping?
Hi all, I'm undertaking a pretty significant wrapping project (a linux shared-object lib) early in my Python experience, and thought it might be useful for many more that just myself if this thread were to produce a sort of roadmap for approaching wrapping with ctypes. I've been doing some reading, but want to verify my "big picture view" and have come to make the following presumptions: (so, please correct me where erroneous) - One gathers the ".h" header(s) for the library to determine the data structures (defined in "#define" and "typedef" statements) as well as the prototypes for the library routines. - From these header files, one defines attributes to reproduce the "#define" statements, and also reproduces the typedef "structs" by defining classes and assigning a Python list of tuples for the "_fields_" attribute, to associate a ctype and field name with each field in the "struct". - Use ctypes.CDLL to "connect" to the library, and instantiate an object whose attributes are the library routines. - From that object, instantiate each of the routines, and override the "argtypes" attribute for each of these with a list of "ctypes", and a single ctype for the "restype" attribute. In either case, the "type" might be a newly-defined type (class) that's more complex than just the provided ctypes. Presumably, judicious use of the leading "_" (underscore) is used to hide (make private) the "ugly details" from the wrapper user, revealing only the routines, and possibly, classes that describe data types the original API expects the user to need. == Can anyone with some "wrapping" experience add/modify/enhance the above? Many thanks for all feedback! -- Alaric -- http://mail.python.org/mailman/listinfo/python-list
Re: A "roadmap" for ctypes wrapping?
In article <[EMAIL PROTECTED]>, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Alaric Haag schrieb: > > Hi all, > > > > stuff deleted > > > > == > > Can anyone with some "wrapping" experience add/modify/enhance the above? > > Use gccxml to gather the typedefs. And look at Gary Bishop's site to see > some cool helper classes/functions for dealing with ctypes. > > Diez Thanks for the pointers! I had hoped others might offer opinions as well, but the cross-post on the "ctypes" list is idle. Thanks again! Alaric -- http://mail.python.org/mailman/listinfo/python-list
Odd syntactic NON-error?
Hello, I just noticed that I've been successfully importing a module I wrote which contains a class definition that begins with (docstring removed): class TDF(): def __init__(self, name='', mode=tscan. GP_NOCLOBBER): Note the "space" which shouldn't be here---^ I'm running Python 2.5.2. What does the interpreter "think" I'm doing? It's not flagged by pylint either, so I suspect there's a reasonable explanation. Alaric -- http://mail.python.org/mailman/listinfo/python-list
Re: Odd syntactic NON-error?
In article <[email protected]>, Jean-Paul Calderone wrote: > On Fri, 30 Jan 2009 11:36:45 -0600, Alaric Haag wrote: > >Hello, > > > >I just noticed that I've been successfully importing a module I wrote > >which contains a class definition that begins with (docstring removed): > > > >class TDF(): > >def __init__(self, name='', mode=tscan. GP_NOCLOBBER): > > > >Note the "space" which shouldn't be here---^ > > The space is irrelevant. > > >>> object. __init__ > > >>> object.__init__ is object. __init__ > True > >>> > > Jean-Paul > -- > http://mail.python.org/mailman/listinfo/python-list It strikes me as strange that Python (which I love btw) would be so loose in its syntax when "spaces matter" at the beginning of a line. I now see that a space could precede the period too, as in: x = foo . method() So, is the "secret" that the period is syntactically an "operator" like + or * ? -- http://mail.python.org/mailman/listinfo/python-list
Good or bad use of __repr__?
Hello, Is the use of __repr__ below a "really bad idea"? class Dimension(): def __init__(self, setp, name): ptr = setp.contents.dim while ptr.contents.name != name: ptr = ptr.contents.next self.name = ptr.contents.name self.size = ptr.contents.size self.unlimited = bool(ptr.contents.unlimited) self.coord = ptr.contents.coord def __repr__(self): return '%g' % (self.size) As written, if a program references a Dimension instance without an attribute, it gets the size attrbute "by default". If it wants the other attributes, they have to be spec'd. In the context of the code being developed, the "size" attribute is the "logical" representation of the dimension. I'm just wondering if this sort of design should be avoided. Many thanks! Alaric -- http://mail.python.org/mailman/listinfo/python-list
