On 6/13/07, Ron Adam <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
