duplication of logic

John Roth newsgroups at jhrothjr.com
Tue Nov 4 13:44:36 CET 2003

<P at draigBrady.com> wrote in message news:3FA78E34.4050502 at draigBrady.com...
> John Roth wrote:
> > "George Trojan" <george.trojan at noaa.gov> wrote in message
> > news:bo6oaf$vfq$1 at news.nems.noaa.gov...
> >
> >>Is time.strptime() intrinsically slow and should be avoided whenever
> >>possible? I have the following code in my application:
> >
> >
> > According to the "what's new in Python" for 2.3, the strptime
> > implementation was switched from a lightweight wrapper
> > around the frequently buggy and incompatible C library
> > to a portable pure Python implementation.
> >
> > Yes, it's going to be a lot slower.
> This duplication of logic looks like a trend?

It's only being done where the various implementations are,
as I mentioned in the original post, incomplete, inconsistent
and buggy. Python is, for better or worse, cross-platform,
and attempts to give a reasonable attempt to running the
same everywhere that there is not a clear and obvious
reason to do something different on the various platforms.

Another point to ponder here is that Python implementations
are favored, at least initially, because they are better defined
and more accessible to the entire user base than C implementations.
Also, they're one less thing for the PyPy project to reengineer
into Python. However, once it's demonstrated that it works
properly, I suspect the developers might be open to accepting
a C version, at least if it was supported by sufficient unit tests
to demonstrate it was the same as the pure Python version, and
it ran significantly faster.

> I know python has to be cross platform, but automatically setting
> things up to use the system libraries where appropriate would
> be a benefit to performance and functionality IMHO.

A serious question: How do you know where it's appropriate?
That's as much a political question as a technical one, and neither
the political nor the technical issue is easy to solve.

John Roth
> Pádraig.

More information about the Python-list mailing list