[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
SourceForge.net
noreply at sourceforge.net
Fri Apr 7 18:41:00 CEST 2006
Feature Requests item #1190596, was opened at 2005-04-27 00:10
Message generated for change (Settings changed) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Raymond Hettinger (rhettinger)
Summary: calendar._firstweekday is too hard-wired
Initial Comment:
Long-running applications which need to make use of the
'calendar'
module may need to present calendars to different users
using
the users' preferred settings. Currently, the two
functions which
rely on the locale-specific setting are too inflexible:
they assume
that the module-level global should always govern.
The attached patch adds defaulted arguments to these
functions,
and uses the module-level global only where the caller
does not
pass in a value.
----------------------------------------------------------------------
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-04-07 18:40
Message:
Logged In: YES
user_id=89016
Yes, with the new OO interface the examples from
test_calendar.txt look like this:
>>> import calendar
>>> calendar.monthcalendar(2005, 4)[0]
[0, 0, 0, 0, 1, 2, 3]
>>> calendar.weekheader(1)
'M T W T F S S'
>>> calendar.TextCalendar(0).monthdayscalendar(2005, 4)[0]
[0, 0, 0, 0, 1, 2, 3]
>>> calendar.TextCalendar(6).monthdayscalendar(2005, 4)[0]
[0, 0, 0, 0, 0, 1, 2]
>>> calendar.TextCalendar(0).formatweekheader(1)
'M T W T F S S'
>>> calendar.TextCalendar(6).formatweekheader(1)
'S M T W T F S'
Closing the feature request.
----------------------------------------------------------------------
Comment By: iga Seilnacht (zseil)
Date: 2006-04-07 18:24
Message:
Logged In: YES
user_id=1326842
I think that this request can now be closed,
since an object oriented interface has been
added in revision 43483 (see bug #947906).
You can simply use multiple instances of
Calendar class or its subclasses.
----------------------------------------------------------------------
Comment By: Tres Seaver (tseaver)
Date: 2005-04-29 17:04
Message:
Logged In: YES
user_id=127625
I somehow dropped the test patch on the floor.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 16:44
Message:
Logged In: YES
user_id=80475
Okay, I've got it from here.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2005-04-29 16:32
Message:
Logged In: YES
user_id=31435
+1 from me. It's a very simple change, allowing callers to
break dependence on a one-size-doesn't-fit-all global in a
clear and thread-safe way. Doesn't break any existing code.
Tiny slowdown in functions that aren't speed-critical anyway.
The patch needs doc and test suite changes too, but what's
here is fine by me so far as it goes.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 00:51
Message:
Logged In: YES
user_id=80475
Tim, I'm -0 on this one. Do you have an opinion?
Essentially, the OP wants an alternate, thread-safe
interface to specifying firstweekday on a per-call basis.
It can already be done with a wrapper function and a lock,
so it is just a convenience issue.
----------------------------------------------------------------------
Comment By: Tres Seaver (tseaver)
Date: 2005-04-28 15:02
Message:
Logged In: YES
user_id=127625
WIth the patch, if you pass 'firstweekday' when
calling 'monthcalendar' or 'weekheader', there
is no race, and therefore no need to guard the
global, because the global is ignored.
Nothing else in the module depends on the
value of that global except those two
functions.
I'm attaching a doctest which demonstrates
the use case.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 14:36
Message:
Logged In: YES
user_id=80475
Write a simple wrapper to save and restore the global state:
>>> def mymonthcalendar(year, month, first=None):
if first is None:
return monthcalendar(year, month)
saved = firstweekday()
setfirstweekday(first)
rows = monthcalendar(year, month)
setfirstweekday(saved)
return rows
That is essentially what the existing API is for.
For a multi-threaded environment, you would need to add
locks to th e critical section in the above code (the same
would be true for your proposed patch).
----------------------------------------------------------------------
Comment By: Tres Seaver (tseaver)
Date: 2005-04-28 14:24
Message:
Logged In: YES
user_id=127625
Different users of a long-running Python process may have
different
preferences for the first weekday; if the application tries
to use the
setfirstweekday() API for each of them, then they end up
racing to
set it.
Making the option selectable per-call makes it side-effect
free, and
therefore more robust for multi-user applications.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 13:42
Message:
Logged In: YES
user_id=80475
I do not follow what can be done with your patch that cannot
currently be done with setfirstweekday().
----------------------------------------------------------------------
Comment By: Tres Seaver (tseaver)
Date: 2005-04-28 13:06
Message:
Logged In: YES
user_id=127625
Aarrgh, what is the point of that silly checkbox, anyway?
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 08:59
Message:
Logged In: YES
user_id=80475
The attachment didn't make it. Please try again and make
sure to check-off the upload box.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470
More information about the Python-bugs-list
mailing list