Problem with inspect.getfile
Hello, I am trying to use someone else's module that makes use of inspect.getsourcelines. The code was not working for me, so I have been debugging to see why it is not working. I have reduced my problem to getting the wrong file path in the getfile->return object.co_filename call. Basically the path I get is: "/Users/elventear/Documents/UTMEM/Projects/geotools/parsers/parser.py" When the correct path should be: "/Users/elventear/Documents/UTMEM/Projects/packages/geotools/parsers/ parser.py" Finally my PYTHONPATH contains: "/Users/elventear/Documents/UTMEM/Projects/packages" So basically, I am able to resolve correctly the package from withing Python, I don't know why there is this confusion about the filename that contains my objects and methods. Any ideas on how to correct this would be appreciated. This is under MacOSX 10.4.9, Python 2.5 (Build from Fink). Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with inspect.getfile
Found the offending code. I was importing between files that were at the same level of the hierarchy without using absolute references. Coded worked fine, but inspect didn't. Was this gaffe on my part? Or was inspect supposed to handle it? Thanks! On May 1, 12:48 pm, elventear <[EMAIL PROTECTED]> wrote: > Hello, > > I am trying to use someone else's module that makes use of > inspect.getsourcelines. The code was not working for me, so I have > been debugging to see why it is not working. I have reduced my problem > to getting the wrong file path in the getfile->return > object.co_filename call. > > Basically the path I get is: > > "/Users/elventear/Documents/UTMEM/Projects/geotools/parsers/parser.py" > > When the correct path should be: > > "/Users/elventear/Documents/UTMEM/Projects/packages/geotools/parsers/ > parser.py" > > Finally my PYTHONPATH contains: > > "/Users/elventear/Documents/UTMEM/Projects/packages" > > So basically, I am able to resolve correctly the package from withing > Python, I don't know why there is this confusion about the filename > that contains my objects and methods. > > Any ideas on how to correct this would be appreciated. > > This is under MacOSX 10.4.9, Python 2.5 (Build from Fink). > > Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with inspect.getfile
On May 2, 1:12 am, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Wed, 02 May 2007 02:53:55 -0300, elventear <[EMAIL PROTECTED]> > escribió: > > > Found the offending code. I was importing between files that were at > > the same level of the hierarchy without using absolute references. > > Coded worked fine, but inspect didn't. Was this gaffe on my part? Or > > was inspect supposed to handle it? > > Could you provide an example? Simple example My PYTHONPATH points to /python I have the following: /python/packages __init.py__ /containers __init.py__ module1.py module2.py So basically module2 depends on module1. So within module2.py I was I was doing "import module1" instead of import "packages.containers.module1". My code ran ok, but the functions in the inspect module weren't able to handle it (getfile was the source of the problem). Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Recursion limit problems
Hello everyone, I am runing into recursion limit problems. I have found that the culprit was related to the __hash__ function that I had assigned to the objects that were added to a set. Basically my __hash__ function is the following: def __hash__(self): out_int = 0 for property,value in self: out_int ^= hash( property )^hash( value ) return out_int And the iterator for this object is: def __iter__(self): for property,value in self.__dict__.iteritems(): yield property,value After commenting the __hash__ function and using the default provided by Python (I suppose it is based on the position in memory of the object), the recursion limit problems went away. (This problem was happening even after increasing the recursion limit to the maximum of my platform, MacOSX). I am not that versed in Python, so I don't know exactly I could do to overcome this problem, any ideas are deeply appreciated. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion limit problems
On May 11, 11:54 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > > Without seeing the full code and the exception traceback, my guess is that > your __hash__ somehow calls itself due to a refence loop in your object. A > simple example of a loop: > a = []; a.append(a) > Now, list objects are not hashable, but if they were, and the hash were > value based (like your), then hash(a) would call hash(a) would call > hash(a) You were right, I had forgotten that in some instances I had some data that recursively pointed to the source. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion limit problems
On May 12, 12:25 am, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Fri, 11 May 2007 19:17:57 -0300, elventear <[EMAIL PROTECTED]> > escribió: > "The only required property is that objects which compare equal have the > same hash value; it is advised to somehow mix together (e.g., using > exclusive or) the hash values for the components of the object that also > play a part in comparison of objects. If a class does not define a > __cmp__() method it should not define a __hash__() operation either; if it > defines __cmp__() or __eq__() but not __hash__(), its instances will not > be usable as dictionary keys. If a class defines mutable objects and > implements a __cmp__() or __eq__() method, it should not implement > __hash__(), since the dictionary implementation requires that a key's hash > value is immutable (if the object's hash value changes, it will be in the > wrong hash bucket)." Thanks for the information. I have a doubt regarding the wording in the paragraph on top. Since I am defining a hash for my object, it makes sense that I should be able to define equality. But I am not sure about inequality, in my specific case. The paragraph above mentions that __cmp__ should be defined if I define a __hash__, but in the default behaviour of __cmp__ inequality is included. So what should I do? Also why is equality necessary to be defined? Do dicts only use __hash__ or do they use equality as well? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion limit problems
On May 14, 1:20 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > > Dicts first compare hashes and if they are equal, then check equality. If > two unequal strings have the same hash value, as is possible of course > (given only 2**32 possible hashes and many more possible strings), both can > still be used as different keys. Ditto for unequal numbers. Or for a > number and string with equal hashes. And so on. The first quoted > sentence, about mixing, is directed at minimizing such hash collisions. Now my question is, since the definition mentions __cmp__ explicity. Is that the only function it uses? What if __ne__, __eq__ are defined, but not __cmp__? Finally I am still confused about the inequality. Does dict only care about the __cmp__ ouput being 0 and ignore the rest, or does it make use of -1,1 as well? Could I just say that 0 defines equality in my object and 1 otherwise, without regard of it being less than or greater than? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Recursion limit problems
On May 14, 2:03 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > > Dicts and sets use the key's hash value to determine the "bucket" where > the key will be placed, and == to distingish between different objects > with the same hash value. > That is, you should define __hash__ and one of (__cmp__ or __eq__). > __neq__ (inequality) isn't required nor used by dict/set implementation. > (Anyway, Python will transform a!=b into not(a==b), if __neq__ isn't > defined). Neither <, <=, >, >= are used. > The important thing is that, if two objects compare equal, they must have > the same hash value. That is: (a==b) => (hash(a)==hash(b)) (the reciprocal > is not true). Cool! I think this answers my last question. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Martel Package from Biopython
Hello, I know this is not the best place to ask this but I haven't had luck in the Biopython forums with my questions, so I'll just try here. I want to use the Martel package to do some parsing. I've found it to be very powerful and convenient. Yet the documentation avaialble is less than complete. I have a few questions on how to use it, if you know the answers to my questions: - How does Bio.Std.record affect the parsing of a Martel expression. - How does Bio.RecordReader work? How does it interact with Martel.HeaderFooter? - Many of the matching objects (ie. Martel.Digits) have an attrs argument. How does it work? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Decimal and Exponentiation
Hi, I am the in the need to do some numerical calculations that involve real numbers that are larger than what the native float can handle. I've tried to use Decimal, but I've found one main obstacle that I don't know how to sort. I need to do exponentiation with real exponents, but it seems that Decimal does not support non integer exponents. I would appreciate if anyone could recommend a solution for this problem. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Question about Python on Mac
Hello, I am working with Python 2.4.3 built from source courtesy of Fink. So far so good, until now. I want to use a module called GMPY (http://gmpy.sf.net/). I am able to build correctly the module, but once I try to import it I get the following error: ImportError: Failure linking new module: gmpy.so: Symbol not found: ___gmpn_sub_nc Referenced from: /sw/lib/libgmp.3.dylib Expected in: dynamic lookup The weird thing is that just for kicks I tried building with Python that comes with MacOSX (py2.3) and it works. It builds and it loads fine. Anybody have an idea why this would happen? Any ideas how to solve this? In the worse case scenario, can I use the binary (gmpy.so) built with against Python 2.3 with Python 2.4.3 (It seems to load correctly but I don't know if I should expect any meltdowns later on) I would appreciate any suggestions. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about Python on Mac
On 2006-05-19 16:19:51 -0500, "elventear" <[EMAIL PROTECTED]> said: > The weird thing is that just for kicks I tried building with Python > that comes with MacOSX (py2.3) and it works. It builds and it loads > fine. Anybody have an idea why this would happen? Any ideas how to > solve this? In the worse case scenario, can I use the binary (gmpy.so) > built with against Python 2.3 with Python 2.4.3 (It seems to load > correctly but I don't know if I should expect any meltdowns later on) First of all I have to correct myself and say that the latest version offered in Fink is 2.4.2. I decided to try with binary build of MacPython 2.4.3 available on Python.org and it also works. Weird. Could this be related to some bug in Python 2.4.2? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about Python on Mac
James Stroud wrote: > I think fink is not detecting the gmp (GNU multiple precision arithmetic > library) dependency. > > Try: > > % fink install gmp > > Then try building gmpy with /sw/bin/python. I think I didn't explain myself very well. gmp is already installed in my computer; when building gmpy it links against libgmp without problems. But when doing import gmpy is that Fink's Python complains like I've mentioned before. But if I build gmpy (Using setup.py), using Python 2.4.3 works fine. Pepe -- http://mail.python.org/mailman/listinfo/python-list
