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

[Guido van Rossum]

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?

> 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. :-)

> 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?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)