[Python-3000] setup.py fails in the py3k-struni branch

[Ron Adam]

Guido van Rossum wrote:
> On 6/13/07, Ron Adam <rrr at ronadam.com> wrote:
>>
>>
>> Guido van Rossum wrote:
>> > I couldn't get this exact patch to apply, but I implemented something
>> > equivalent in the py3kstruni branch. See revisions 55964 and 55965.
>> > Thanks for the suggestion!
>>
>> This is actually closer to how I started to do it, but I wasn't sure 
>> if it
>> would catch everything.  Looking at it again, it looks good with the
>> exception of riscos.  (The added test should catch that if it's a problem
>> so it can be fixed later.)
> 
> If riscos is even still supported. ;-(

I have no idea.

Looking at the overall structure of os.py makes me think the platform 
specific code could be abstracted out a bit further.  Possibly have one 
public "platform" module (or package) that is an alias or built from 
private _platform package files.

So instead of having "import mac" or "from mac import ..." in if-else 
structures, just do "from platform import ...".  That moves all the 
platform testing to either the build process or as part of site.py so it 
can set 'platform' to the correct platform module or package.  After that 
everything else is platform independent (or mostly).


>> The reason I made a new test case for added tests is that the existing 
>> test
>> case based on mapping_tests.BasicTestMappingProtocol doesn't run the 
>> added
>> test methods.  So I put those under a new test case based on 
>> unittest.TestCase.
> 
> I don't understand this. The test_keyvalue_types() test *does* run,
> regardless if whether I use regrtest.py test_os or test_os.py.

Just tested it again and you are right.  I did test it earlier and it did 
not run those tests when I wrote the test exactly as you did. (So if it was 
broke, it got fixed someplace else.)


>> I can't re-verify this currently because the latest merge broke something
>> in my build process.  I'm getting a "lost stderr" message.  I've seen it
>> before so it's probably something on my end.  I think the last time this
>> happened to me I was able to clear it up by deleting the branch and
>> re-updating it.
> 
> Your best bet is to remove all .pyc files under Lib: rm `find Lib -name 
> \*.pyc`
> (make clean also works)

You fixed this when you added the missing abc.py file.


>> Another suggestion is to make a change in stringobject.c to represent 8
>> bits strings as "str8('somes_tring')"  or just s"some_string" so they can
>> more easily be found from unicode strings.  Particularly in the tests.
>> This will force a few more tests to fail, but they are things that 
>> need to
>> be fixed.  Only about 3 or 4 additional modules fail when I tried it.
> 
> I've considered this, but then we should also support that notation on
> input. I've also thought of using different string quote conventions,
> e.g. "..." to mean Unicode and '...' to mean 8-bit.

Are str8 types going to be part of the final distribution?  I thought the 
goal was to eventually remove all of those where ever possible.

I think "" vs '' is too subtle.


>> I was getting failed expect/got test cases that looked exactly the same.
>> But after changing the str8 representation those became obvious st8 vs
>> unicode comparisons.
> 
> Right.
> 
>> Using the shorter 's"string"' form will cause places, where eval or exec
>> are using str8, to cause syntax errors.  Which may also be helpful.
> 
> Why would this help?

This would be only a temporary debugging aid to be removed later.  Often 
eval and exec get their inputs from temporary files or other file like 
sources. So this moves the point of failure a bit closer to the problem in 
these cases.  I don't think there should be any places where a str8 string 
is created by a python program will be used this way,  those will be 
unicode strings.

Think of it as just another test, but it's more general in scope than a 
highly specific unit test with usually very controlled inputs.  And it's 
purpose is to help expose some harder to find problems, not the easy to fix 
ones.


>> BTW,  I will make a new remove_raw_escapes patch so it applies cleanly.
>> I'm trying to track down why my patched version of test_tokenize.py 
>> passes
>> sometimes but not at others.  (I think it's either a tempfile or 
>> string io
>> issue, or both.)  This was what initiated the above suggestion.
> 
> Please send it as a proper attachment; somehow gmail doesn't make it
> easy to extract patches pasted directly into the text (nor "inline"
> attachments).

Ok, will do.  I'll update the patch on the patch tracker since it's already 
started as well.

Cheers,
    Ron