Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #104026 > unrolled thread

Any comment on using ctypesgen package?

Started byjfong@ms4.hinet.net
First post2016-03-04 03:08 -0800
Last post2016-03-06 16:57 -0800
Articles 8 — 4 participants

Back to article view | Back to comp.lang.python


Contents

  Any comment on using ctypesgen package? jfong@ms4.hinet.net - 2016-03-04 03:08 -0800
    Re: Any comment on using ctypesgen package? Chris Angelico <rosuav@gmail.com> - 2016-03-04 23:00 +1100
    Re: Any comment on using ctypesgen package? Peter Otten <__peter__@web.de> - 2016-03-04 13:35 +0100
      Re: Any comment on using ctypesgen package? jfong@ms4.hinet.net - 2016-03-04 21:35 -0800
        Re: Any comment on using ctypesgen package? Chris Angelico <rosuav@gmail.com> - 2016-03-05 16:49 +1100
          Re: Any comment on using ctypesgen package? jfong@ms4.hinet.net - 2016-03-05 00:14 -0800
            Re: Any comment on using ctypesgen package? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-05 11:59 +0000
              Re: Any comment on using ctypesgen package? jfong@ms4.hinet.net - 2016-03-06 16:57 -0800

#104026 — Any comment on using ctypesgen package?

Fromjfong@ms4.hinet.net
Date2016-03-04 03:08 -0800
SubjectAny comment on using ctypesgen package?
Message-ID<3f342ec1-c6cd-49a8-aca2-2eac21fbbd79@googlegroups.com>
I try to test this package but with no luck. This module was written for Python 2.x but mine is 3.4 so I use the 2To3 to "upgrade" it first (it seems OK). Then I run "python setup.py install" and get the following error:
   ...
   ...
   File "D:\Patch\ctypesgen-master\ctypesgencore\parser\lex.py", line 41, in <module>
    _INSTANCETYPE = types.InstanceType
   AttributeError: 'module' object has no attribute 'InstanceType'

Below is the troubled codes in file lex.py:
Note: In original codes (before 2To3 modify), there is "types.ObjectType" instead of "object".
---------
# Available instance types.  This is used when lexers are defined by a class.
# It's a little funky because I want to preserve backwards compatibility
# with Python 2.0 where types.ObjectType is undefined.
try:
    _INSTANCETYPE = (types.InstanceType, object)
except AttributeError:
    _INSTANCETYPE = types.InstanceType
    class object: pass   # Note: needed if no new-style classes present 
-----------
The author had put some comments above these codes but I have no idea what he is talking about.

There is someone who had encountered the same problem last year and raise a question at its home page, but the author seems has no interest on doing anything on it anymore.
https://github.com/davidjamesca/ctypesgen/issues/53

Does anyone know how to fix it? or the whole job will be a mission impossible if no help from its author?

--Jach

[toc] | [next] | [standalone]


#104028

FromChris Angelico <rosuav@gmail.com>
Date2016-03-04 23:00 +1100
Message-ID<mailman.184.1457092816.20602.python-list@python.org>
In reply to#104026
On Fri, Mar 4, 2016 at 10:08 PM,  <jfong@ms4.hinet.net> wrote:
> Below is the troubled codes in file lex.py:
> Note: In original codes (before 2To3 modify), there is "types.ObjectType" instead of "object".
> ---------
> # Available instance types.  This is used when lexers are defined by a class.
> # It's a little funky because I want to preserve backwards compatibility
> # with Python 2.0 where types.ObjectType is undefined.
> try:
>     _INSTANCETYPE = (types.InstanceType, object)
> except AttributeError:
>     _INSTANCETYPE = types.InstanceType
>     class object: pass   # Note: needed if no new-style classes present
> -----------
> The author had put some comments above these codes but I have no idea what he is talking about.

I'm not sure exactly what this is trying to do, but if it's just for
isinstance testing, you can save yourself a lot of trouble. In Python
3, *every* type inherits from 'object'. So _INSTANCETYPE can be set to
just object - and anything that's trying to query that can simply
assume it's true.

ChrisA

[toc] | [prev] | [next] | [standalone]


#104030

FromPeter Otten <__peter__@web.de>
Date2016-03-04 13:35 +0100
Message-ID<mailman.186.1457094947.20602.python-list@python.org>
In reply to#104026
jfong@ms4.hinet.net wrote:

> I try to test this package but with no luck. This module was written for
> Python 2.x but mine is 3.4 so I use the 2To3 to "upgrade" it first (it
> seems OK). Then I run "python setup.py install" and get the following
> error:
>    ...
>    ...
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\lex.py", line 41,
>    in <module>
>     _INSTANCETYPE = types.InstanceType
>    AttributeError: 'module' object has no attribute 'InstanceType'
> 
> Below is the troubled codes in file lex.py:
> Note: In original codes (before 2To3 modify), there is "types.ObjectType"
> instead of "object". ---------
> # Available instance types.  This is used when lexers are defined by a
> # class. It's a little funky because I want to preserve backwards
> # compatibility with Python 2.0 where types.ObjectType is undefined.
> try:
>     _INSTANCETYPE = (types.InstanceType, object)
> except AttributeError:
>     _INSTANCETYPE = types.InstanceType
>     class object: pass   # Note: needed if no new-style classes present
> -----------
> The author had put some comments above these codes but I have no idea what
> he is talking about.
> 
> There is someone who had encountered the same problem last year and raise
> a question at its home page, but the author seems has no interest on doing
> anything on it anymore.
> https://github.com/davidjamesca/ctypesgen/issues/53
> 
> Does anyone know how to fix it? or the whole job will be a mission
> impossible if no help from its author?

Nothing is impossible with open source ;)

What's possible for you depends on your knowledge and the amount of effort 
you are willing to spend. The page you link to has the comment

"""
The 2to3 route is not likely to apply since ctypesgen actually writes Python 
code and the 2to3 utility will probably miss a good portion of that logic.
"""

But as someone else seems to have done the work already

https://github.com/davidjamesca/ctypesgen/issues/51

I'd try his version first.

[toc] | [prev] | [next] | [standalone]


#104082

Fromjfong@ms4.hinet.net
Date2016-03-04 21:35 -0800
Message-ID<43488da7-39c7-4291-a219-10e59d4491bd@googlegroups.com>
In reply to#104030
Peter Otten 2016/3/4  UTC+8 8:36:02PM worte:
> """
> The 2to3 route is not likely to apply since ctypesgen actually writes Python 
> code and the 2to3 utility will probably miss a good portion of that logic.
> """
> 
> But as someone else seems to have done the work already
> 
> https://github.com/davidjamesca/ctypesgen/issues/51
> 
> I'd try his version first.

Following this link, it says "Make output python3-compatible". So it still run under 2.x but generate codes for 3.x:-(

After taking Chris's suggestion, the installation is pushing forward a little and then bump into another error:
----------
File "D:\Patch\ctypesgen-master\ctypesgencore\parser\pplexer.py", line 123, in  
punctuator_regex
    punctuator_regexes.sort(lambda a, b: -cmp(len(a), len(b)))
TypeError: must use keyword argument for key function
----------
This error has been mentioned in "Sorting HOW TO" section in 3.4 document,
    "In Py3.0, the cmp parameter was removed entirely"
    "To convert to a key function, just wrap the old comparison function:"
    "In Python 3.2, the functools.cmp_to_key() function was added to the functools module in the standard library."

Oh, goodness! do I have to dive into 2.x?

Based on the assumptions below:
1. It might be not easy to upgrade it to 3.x (at least not just run 2To3), or else its author will not drop it.
2. I have to go back into 2.x jungle to study all these difference.
3. Even "Python setup.py install" passed, it's still not sure if the output will be correct.

I think it's better to drop it too. Thanks for your advice, Chris and Peter.

--Jach

[toc] | [prev] | [next] | [standalone]


#104083

FromChris Angelico <rosuav@gmail.com>
Date2016-03-05 16:49 +1100
Message-ID<mailman.219.1457156993.20602.python-list@python.org>
In reply to#104082
On Sat, Mar 5, 2016 at 4:35 PM,  <jfong@ms4.hinet.net> wrote:
> After taking Chris's suggestion, the installation is pushing forward a little and then bump into another error:
> ----------
> File "D:\Patch\ctypesgen-master\ctypesgencore\parser\pplexer.py", line 123, in
> punctuator_regex
>     punctuator_regexes.sort(lambda a, b: -cmp(len(a), len(b)))
> TypeError: must use keyword argument for key function
> ----------
> This error has been mentioned in "Sorting HOW TO" section in 3.4 document,
>     "In Py3.0, the cmp parameter was removed entirely"
>     "To convert to a key function, just wrap the old comparison function:"
>     "In Python 3.2, the functools.cmp_to_key() function was added to the functools module in the standard library."
>
> Oh, goodness! do I have to dive into 2.x?
>
> Based on the assumptions below:
> 1. It might be not easy to upgrade it to 3.x (at least not just run 2To3), or else its author will not drop it.
> 2. I have to go back into 2.x jungle to study all these difference.
> 3. Even "Python setup.py install" passed, it's still not sure if the output will be correct.
>
> I think it's better to drop it too. Thanks for your advice, Chris and Peter.

Your conclusion may well be correct. However, the exact issue you're
looking at here might be easily enough fixed; it looks like it's
trying to sort things by length, so you can simply use "key=len" (and
maybe "reverse=True").

ChrisA

[toc] | [prev] | [next] | [standalone]


#104087

Fromjfong@ms4.hinet.net
Date2016-03-05 00:14 -0800
Message-ID<366bbd75-21fa-4332-b5dd-49557dc238e1@googlegroups.com>
In reply to#104083
Chris Angelico at 2016/3/5  UTC+8 1:50:05PM wrote:
> Your conclusion may well be correct. However, the exact issue you're
> looking at here might be easily enough fixed; it looks like it's
> trying to sort things by length, so you can simply use "key=len" (and
> maybe "reverse=True").

After Chris gave this suggestion, I can't withstand the temptation of running the setup again. This time, strangely, it reports error on import. Won't the import statement easy enough to be handled by 2To3? Here is the result (where the whole "ctypesgencore" directory had been processed by 2To3 and the "parser" is a sub-directory under it):

----------
D:\Patch\ctypesgen-master>python setup.py install
Traceback (most recent call last):
  File "setup.py", line 13, in <module>
    import ctypesgencore
  File "D:\Patch\ctypesgen-master\ctypesgencore\__init__.py", line 55, in <modul
e>
    from . import parser
  File "D:\Patch\ctypesgen-master\ctypesgencore\parser\__init__.py", line 17, in
 <module>
    from .datacollectingparser import DataCollectingParser
  File "D:\Patch\ctypesgen-master\ctypesgencore\parser\datacollectingparser.py",
 line 10, in <module>
    from . import ctypesparser
  File "D:\Patch\ctypesgen-master\ctypesgencore\parser\ctypesparser.py", line 15
, in <module>
    from .cparser import *
  File "D:\Patch\ctypesgen-master\ctypesgencore\parser\cparser.py", line 21, in
<module>
    from . import cgrammar
  File "D:\Patch\ctypesgen-master\ctypesgencore\parser\cgrammar.py", line 25, in
 <module>
    from . import ctypesparser
ImportError: cannot import name 'ctypesparser'
------------

Just curious, is there a recursive-import happen on handling the "parser" directory?

After checking the files, I had noticed that all the import statements had been changed by 2To3. Mostly the changes are, such as, from "import cgrammar" to "from . import cgrammar", or "from cparser import *" to "from .cparset import *". I can understand the former, but can't figure out the latter:-(

--Jach

[toc] | [prev] | [next] | [standalone]


#104092

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2016-03-05 11:59 +0000
Message-ID<mailman.222.1457179247.20602.python-list@python.org>
In reply to#104087
On 05/03/2016 08:14, jfong@ms4.hinet.net wrote:
> Chris Angelico at 2016/3/5  UTC+8 1:50:05PM wrote:
>> Your conclusion may well be correct. However, the exact issue you're
>> looking at here might be easily enough fixed; it looks like it's
>> trying to sort things by length, so you can simply use "key=len" (and
>> maybe "reverse=True").
>
> After Chris gave this suggestion, I can't withstand the temptation of running the setup again. This time, strangely, it reports error on import. Won't the import statement easy enough to be handled by 2To3? Here is the result (where the whole "ctypesgencore" directory had been processed by 2To3 and the "parser" is a sub-directory under it):
>
> ----------
> D:\Patch\ctypesgen-master>python setup.py install
> Traceback (most recent call last):
>    File "setup.py", line 13, in <module>
>      import ctypesgencore
>    File "D:\Patch\ctypesgen-master\ctypesgencore\__init__.py", line 55, in <modul
> e>
>      from . import parser
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\__init__.py", line 17, in
>   <module>
>      from .datacollectingparser import DataCollectingParser
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\datacollectingparser.py",
>   line 10, in <module>
>      from . import ctypesparser
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\ctypesparser.py", line 15
> , in <module>
>      from .cparser import *
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\cparser.py", line 21, in
> <module>
>      from . import cgrammar
>    File "D:\Patch\ctypesgen-master\ctypesgencore\parser\cgrammar.py", line 25, in
>   <module>
>      from . import ctypesparser
> ImportError: cannot import name 'ctypesparser'
> ------------
>
> Just curious, is there a recursive-import happen on handling the "parser" directory?
>
> After checking the files, I had noticed that all the import statements had been changed by 2To3. Mostly the changes are, such as, from "import cgrammar" to "from . import cgrammar", or "from cparser import *" to "from .cparset import *". I can understand the former, but can't figure out the latter:-(
>
> --Jach
>

HTH http://python3porting.com/problems.html

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]


#104179

Fromjfong@ms4.hinet.net
Date2016-03-06 16:57 -0800
Message-ID<d1390320-d23d-472e-be1d-a0bf27b223a1@googlegroups.com>
In reply to#104092
Mark Lawrence at 2016/3/5  UTC+8 8:01:06PM wrote:
> 
> HTH http://python3porting.com/problems.html

OK, now I understand what "from .cparset import *" means, but it didn't help on solving this import error:-(

Thanks for the link, although it seems not help on this problem either:-)

--Jach

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web