[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:
>> 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).
> 
> Yeah, but I'm not going to rewrite the standard library -- I'm only
> going to keep the current architecture working. Others will have to
> help with improving the architecture. You have the right idea -- can
> you make it work as a patch?

Yes, I expect it would be part of the library reorganization which is still 
down the road a bit.  I'll try look into a bit more sometime between now 
and then.  Maybe I can get enough of it started and get others motivated to 
contribute to it.  <shrug>


>> You fixed this when you added the missing abc.py file.
> 
> Sorry about that. I think it was a svnmerge glitch; I didn't notice it
> until long after the merge.
> 
>> 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 don't know yet. There's been a cry for an "immutable bytes" type --
> it could be str8 (perhaps renamed). Also, much C code doesn't deal
> with Unicode strings yet and expects char* strings whose lifetime is
> the same as the Unicode string. Having a str8 permanently attached to
> the Unicode string is a convenient solution -- especially since it's
> already implemented. :-)

Well I can see where a str8() type with an __incoded_with__ attribute could 
be useful.  It would use a bit more memory, but it won't be the 
default/primary string type anymore so maybe it's ok.

Then bytes can be bytes, and unicode can be unicode, and str8 can be 
encoded strings for interfacing with the outside non-unicode world.  Or 
something like that. <shrug>


>> I think "" vs '' is too subtle.
> 
> Fair enough.
> 
>> >> 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.
> 
> Makes some sense. Could you come up with a patch?

Done  :-)

Attached both the str8 repr as s"..." and s'...', and the latest 
no_raw_escape patch which I think is complete now and should apply with no 
problems.

I tracked the random fails I am having in test_tokenize.py down to it doing 
a round trip on random test_*.py files.  If one of those files has a 
problem it causes test_tokanize.py to fail also.  So I added a line to the 
test to output the file name it does the round trip on so those can be 
fixed as they are found.

Let me know it needs to be adjusted or something doesn't look right.

Cheers,
    Ron


-------------- next part --------------
A non-text attachment was scrubbed...
Name: norawescape3.diff
Type: text/x-patch
Size: 18923 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20070613/d4f1846d/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stingobject_str8repr.diff
Type: text/x-patch
Size: 758 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20070613/d4f1846d/attachment-0003.bin