Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#17 Allowing unicode objects with Assert

closed
5
2008-02-22
2008-01-21
Johan Lindberg
No

>>> import clips
>>> clips.Assert(unicode("(duck)"))

Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
clips.Assert(unicode("(duck)"))
File "C:\Python25\lib\site-packages\clips\_clips_wrap.py", line 2676, in Assert
raise TypeError("expected a string or a Fact")
TypeError: expected a string or a Fact
>>>

I don't know how Clips handles Unicode but I think pyClips should support them. At least in the sense that they could be used wherever string objects can be used. Possibly by an explicit conversion (to a string) where needed.

Discussion

1 2 > >> (Page 1 of 2)
  • Logged In: YES
    user_id=328337
    Originator: NO

    Indeed. I didn't think of it in the first place. As far as i can see, Gary is planning Unicode support for 6.4 - yet we're still at 6.3 beta. So CLIPS will not support Unicode for a while... I think that, for now, a brute conversion is the most we can do.

    However I'll release a new version, hopefully soon, that will convert Unicode objects to strings when needed and will sport other enhancements.

     
    • milestone: --> 424076
    • assigned_to: nobody --> franzg
     
  • Logged In: YES
    user_id=328337
    Originator: NO

    Indeed. I didn't think of it in the first place. As far as i can see, Gary is planning Unicode support for 6.4 - yet we're still at 6.3 beta. So CLIPS will not support Unicode for a while... I think that, for now, a brute conversion is the most we can do.

    However I'll release a new version, hopefully soon, that will convert Unicode objects to strings when needed and will sport other enhancements.

     
  • Logged In: YES
    user_id=328337
    Originator: NO

    In fact it's not that easy!

    I'll have to put some effort on this issue, because until now I've always let the low-level module handle all errors. However I found that sometimes I've been *too* lazy in the high-level module: in some case passing None as a parameter would make a good Symbol for an underlying BuildXXX construct...

    Maybe it's time to solve this problem, too. But I've seen that there is no easy way to do it: the simple brute conversion of every string-like argument breaks the test suite, which relies on the genericness of Python functions.

    I'm working on it...

     
  • Johan Lindberg
    Johan Lindberg
    2008-01-22

    Logged In: YES
    user_id=684311
    Originator: YES

    Ok. Let me know if there's anything I can help with. As long as we're talking about the high-level (Python) code I think I might be useful.

     
  • Logged In: YES
    user_id=328337
    Originator: NO

    Sometimes bad things come to mind... What I'm thinking now is quite scary.

    What about doing type checking and/or conversion (enforcement) via decorators? This wouldn't actually impact so much more on performance than directly inserting code to do type checking in each function. But in this case I'd have to drop support for Python 2.3 (I don't like the old "decorator" way, coded as f = deco(f), the new ones are much more clear), or find a way to remove the decorators from _clips_wrap.py upon request...

    Of course when I say that performance would not be affected more with a technique or with another, it does not mean that it would stay the same as without type checking/enforcement.

    Tell me what you think of this solution!

    Of course, as soon as a solution is chosen, I'll appreciate your help a lot in determining what functions should be affected. Thank you for your offering.

     
    • milestone: 424076 --> Scheduled for Next Release
     
  • Logged In: YES
    user_id=328337
    Originator: NO

    The code that implements this via decorators has been submitted to SVN. There is still a bug that I have to deal with before I can release the new version though.

    With this release the support for Python 2.3 will be dropped, as decorators have been implemented in Python 2.4.

     
  • Logged In: YES
    user_id=328337
    Originator: NO

    The fixes for this bug or request have been accepted and
    committed to current CVS tree: next release will include these
    fixes, possibly among other enhancements.

     
  • Logged In: YES
    user_id=328337
    Originator: NO

    The fixes for this bug or request have been accepted and
    committed to current CVS tree: next release will include these
    fixes, possibly among other enhancements.

     
1 2 > >> (Page 1 of 2)