Re: Re: porting unittest.py to Prothon.

Mark Hahn wrote:
> Serge Orlov wrote:

>> I'm trying to port unittest.py to Prothon, here are my
>> impressions:
>>
>> 1. I realized that I don't know how to translate some
>> Python builtins. I mean either I haven't gained the knowledge
>> or the functionality is lacking. I decided to write a full
>> translation quick reference. See below.

> Thanks.  This will be very useful.

Feel free to comment on prFuture and "Prothon replacement" columns.
There are also ??? in the "Prothon replacement" column.

> I missed your private message.  I have been missing private messages because
> I think they are copies of mailing list messages.  I will find it.

I just didn't want to clog the list up, but since I'm going
to send this letter to the list anyway, I'm inserting that
message here:

==========================================================
I'm trying to port unittest.py to Prothon and I've encountered
bug #37. I've tested it on the stable release too, it's present
there. I can work around it but it's blocking a lot of fun.
If you fix it, please make a Windows binary interim release.

I'm also not getting any notifications from bugzilla, is it OK?
==========================================================


>> 4. What is the status of "from Module import xxx"?

> It used to work.  Did you try it?

Yes:

===========================================================
O>> from os import *

Parse Error: expecting `LABEL'
--- col: 17

Uncaught exception:
Parse Error, O>>
O>>
O>>
O>>
O>> from os import system

Uncaught exception:
--- File: fromosimportsystem-src.txt, line: 2, char: 1
Program Error, No main module set for importing.

O>>
===========================================================

I've come up with a hack:
import pyCompat
pyCompat.exportNames("*")

I called it a hack because messing with stack is considered
a quick hack in Python. But after I used it for a while I
realized:
1. I doesn't feel like like hack using caller :)
2. It provides more functionality then "from X import *"
  a. I don't want to override existing objects like range(),
     "from X import *" doesn't let me control it.
  b. I can implement .exportFewerNames() because I'm going
     to play with the idea of incremental removing of
     Python functionality from the ported module.



  -- Serge