[Python-3000] setup.py fails in the py3k-struni branch
Guido van Rossum
guido at python.org
Thu Jun 14 04:25:15 CEST 2007
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.
> >> 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
Makes some sense. Could you come up with a patch?
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000