Feature Requests item #1190596, was opened at 2005-04-26 18:10
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tres Seaver (tseaver)
>Assigned to: Nobody/Anonymous (nobody)
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: Tim Peters (tim_one)
Date: 2005-04-29 10: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-28 18: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 09: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 08: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 08: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 07: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 07: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 02: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
_______________________________________________
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to