Oops! Well, maybe what I meant was you need it *even more* if you need
to implement pack/unpack in python-source.
> It's extremely simple to add a command line option, environment
> variable or more sophisticated configuration mechanism whereby byte
> order and word size can be specified to such conversion programs.
If I may quote you from another context:
guido> I don't see much use for knowing the CPU type, byte order, word size
guido> and floating point format unless pack/unpack get implemented. Come
guido> on, most C code doesn't know or care about these ...
Oh ! So the *programmers* DON'T know what byte order they are using, but now
you expect the *USERS* to know! :-)
Actually, you have a point. I don't expect them to know what byte order
is, but it is reasonable for them to know that what they are trying to
do is convert IBM-PC files to Sparc/Unix files of some type. So I reject
the idea of an option like 'dd's "conv=swab", but something like
"-from pc" is reasonable. But I still want to keep the "low-level" code
portable.
Also, I WILL admit that *I* don't know the byte order of various machines
off the top of my head. But I *do* know that there is a "network byte
order" and conversions to/from that and native byte order. ( This, again,
is my paradigmatic example of "good portable non-portabilities" ).
And I sometimes remember that two particular machines are different
( even if I can't remember which one is big-endian or how they relate
to a third architecture. ). [ "Oh - this file came from a PC, so I'd
better 'swab' it!" - That's the paradigmatic "bad" example! ]
>
> >*IF* we need a routine to convert to/from a cannonical ( probably
> >posix style ) pathname to/from a local style pathname ( I'm not sure
> >that we do, but I think so, unless everyone remembers to only use
> >the least common denominator path names, or unless that conversion
> >is built into the builtin module's "open" . ) then that module has to
> >have some local information!
>
> I am very much against adopting a standard Python style of pathnames
> (i.e. saying that '/' is the pathname delimiter on all systems and
> translating to the native delimiter on systems where it differs).
> The arguments passed to open(), stat(), listdir() etc. and the return
> values of getcwd(), readlink() etc. must definitely be pathnames in
> the native system's syntax. Since most pathnames will be typed by the
> user (e.g. on the command line) or retrieved from the system somehow,
> this can't be a big problem. Where you hard-code pathnames in a
> program they usually have to be edited when moving the program to a
> different site anyway.
>
I agree. ( I think! :-)
"Native" names should be the norm for interactive usage.
Where pathname need to be written into a program, then it is not
unreasonable to expect the programmer to explicitly use a
"path.to_native" conversion function, to indicate that he doesn't
actually MIND if the pathname get's munged up ( truncated | character
translated | etc. ) as long as there is a determinate mapping.
( for practical purposes one-to-one )
I think we are in agreement on:
(1) There will be ( for example ) a 'path' module for unix|dos|mac|etc.
that will attempt to hide or at least isolate machine differences.
(2) That portable code should only need to import 'path', and not
need to figure out which 'specific' module ( unixpath|macpath|dospath )
it needs to load. [ I don't care what mechanics we choose to do this,
as long as we can hide the machinery! ]
(3) But searching for module dependencies and renameing files is not
the preferred solution to the above. [ The machinery here is
painfully visible, even if only visible to ONE person ( the site
maintainer/installer of Python. ]
The binary read/write issue is a completely different question. The two
are only linked because of using successful import of a "built-in" module
to determine local information. [ Which is why it is a bad method. ]
Gotta go hear a man talk about Wavelet's!
Bye for now,
- Steve
[ BTW: I have managed to get my packet drivers working on my 486 PC,
So I can telnet the python sources onto it. I have the Gnu C compiler
PC port installed, So I hope to start porting Python *REAL SOON* ]