[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired

SourceForge.net noreply at sourceforge.net
Fri Apr 7 18:24:01 CEST 2006


Feature Requests item #1190596, was opened at 2005-04-27 00:10
Message generated for change (Comment added) made by zseil
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: Open
Resolution: None
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: Ž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