[Skip Montanaro]
> I checked in what I thought was a fix for calendar.py and
> test_calendar.py, then realized it didn't handle slices.
Why does that matter? calendar.__all__ doesn't export _localized_name or
any of the gimmicks built from it, so it's purely an internal issue, and the
internals never need slices here (granted that day_name etc are poorly named
for module privates -- or perhaps the __all__ list and the docs are in
error).
> I've never dealt with __getitem__ and slices before. Would someone try
> out this modified version of calendar._localized_name and let me know
> what I'm doing wrong?
>
> class _localized_name:
> def __init__(self, format, len):
> self.data = []
> for i in range(len):
> self.data.append(strftime(format, (i,)*9).capitalize())
> # months are one-based - match 2.1 behavior
> if format == '%b':
> self.data[0] = " "
> elif format == '%B':
> self.data[0] = ""
Now this changes the current semantics in a major way: if you're going to
precompute all the values, construct plain tuples instead and be done with
it. I assume that whoever patched this to begin with deliberately
recomputed localized values on each dynamic reference so that they would
respond appropriately to dynamic locale changes.
> def __getitem__(self, item):
> if type(item) is types.SliceType:
> return self.data[item.start:item.stop]
> return self.data[item]
>
> def __len__(self):
> return len(self.data)
>
> For example, try something like
>
> calendar.month_abbr[-20:]
>
> Also, should I worry about the slice's step attribute?
To both, I don't think you should be changing this code to do static
precomputation at all. But, if we must, toss the class and build plain
tuples instead, e.g.
day_name = tuple([strftime('%A', (i,)*9) for i in range(7)])
In the static case, trying to build a class that emulates a tuple is
pointless.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4