[ python-Bugs-1191104 ] Warning ``error`` filter action is ignored.
Bugs item #1191104, was opened at 2005-04-27 15:55
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: Vinay Sajip (vsajip)
Summary: Warning ``error`` filter action is ignored.
Initial Comment:
Hi all. It seems that setting the ``error`` action on
a warning message once it has already been triggered
does not allow it to be triggered again. As usual, the
code is clearer than the explanation::
import warnings
def do_warn():
warnings.warn("A warning.", DeprecationWarning)
do_warn()
warnings.filterwarnings('error',
category=DeprecationWarning)
do_warn()
warnings.filterwarnings('always',
category=DeprecationWarning)
do_warn()
The output of this program is::
nowarn.py:4: DeprecationWarning: A warning.
warnings.warn("A warning.", DeprecationWarning)
There is no exception raised, though the filter was
instructed to turn the warning into an error. Take
note that using ``always`` has similar results.
Does it work in that way on purpose? I find it quite
counterintuitive, IMHO. If this behaviour is intended,
what would be the way to turn the second warning into
an exception?
Thanks!
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-04-29 08:17
Message:
Logged In: YES
user_id=308438
This does not appear to be a bug. For example, the following
script (indentation may get messed up):
#--
import sys, warnings
def do_warn():
fn = sys.modules["__main__"].__file__
warnings.warn_explicit("A warning.", DeprecationWarning,
fn, 0)
def main():
do_warn()
warnings.filterwarnings('error',
category=DeprecationWarning)
try:
do_warn()
except Exception, e:
print "exception handled: %s" % e
warnings.filterwarnings('always',
category=DeprecationWarning)
do_warn()
if __name__ == "__main__":
main()
#--
prints
C:\temp\nowarn.py:0: DeprecationWarning: A warning.
exception handled: A warning.
C:\temp\nowarn.py:0: DeprecationWarning: A warning.
So the problem is that if you want explicit warnings, you
need to use warn_explicit() rather than warn().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1191697 ] slice indices different than integers
Feature Requests item #1191697, was opened at 2005-04-28 14:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191697&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Sebastien de Menten (sdementen) >Assigned to: Michael Hudson (mwh) Summary: slice indices different than integers Initial Comment: Hi, Slice notation is quite convenient while addressing some item in a collection. It would be nice to extend this notation by enabling any object instead of integer in slices. Example 1: let time_serie be an object representing a time serie and date and days object that manages dates and concept of days interval, one could indexed time_serie with: time_serie[date(2004,3,4):date(2004,5,3)] or time_serie[date(2004,3,4):date(2004,5,3):days(5)] Example 2: Let f be a numerical function with multiple arguments, one could get an array of results by using f[3:10:2, 1:5:3] or naturally :-) f[3.2:10.1:0.4, 1:5:3] Well, I think it is a matter of removing the check on argument of slices to enable the syntactic sugar start:end:step in __getitem__ calls as well as adding integer checks on slice attributes when using it in old way. -- >Comment By: Michael Hudson (mwh) Date: 2005-04-29 10:53 Message: Logged In: YES user_id=6656 Closing, because you can do this already: >>> class D(object): ... def __getitem__(self, item): ... print item.start, item.stop, item.step ... >>> import datetime >>> D()[datetime.datetime.now():1.3:D] 2005-04-29 10:56:17.368061 1.3 -- Comment By: Christopher Dunn (cxdunn) Date: 2005-04-29 03:31 Message: Logged In: YES user_id=1267419 This already works. See page 95 of Python in a Nutshell, or check the docs. Slice objects are created when you specify a slice. They can contain anything. Special methods (like __getitem__ and __delitem__) are passed that object, so your own class could define those methonds and do anything you want with the arbitrary slice object. For example: class Ruler(object): def __getitem__(self, s): return s.stop - s.start x = Ruler() print x[5:7] print x[4.2:5.1] produces 2 0.9 -cxdunn -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191697&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1192315 ] 'clear -1' in pdb
Bugs item #1192315, was opened at 2005-04-29 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pechkinzzz (mpech) Assigned to: Nobody/Anonymous (nobody) Summary: 'clear -1' in pdb Initial Comment: Delete breakpoints like in %subj% is great feature, but wrong. Add additional check like in do_enable() if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191104 ] Warning ``error`` filter action is ignored.
Bugs item #1191104, was opened at 2005-04-27 17:55
Message generated for change (Comment added) made by ivilata
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
Category: Python Library
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: Vinay Sajip (vsajip)
Summary: Warning ``error`` filter action is ignored.
Initial Comment:
Hi all. It seems that setting the ``error`` action on
a warning message once it has already been triggered
does not allow it to be triggered again. As usual, the
code is clearer than the explanation::
import warnings
def do_warn():
warnings.warn("A warning.", DeprecationWarning)
do_warn()
warnings.filterwarnings('error',
category=DeprecationWarning)
do_warn()
warnings.filterwarnings('always',
category=DeprecationWarning)
do_warn()
The output of this program is::
nowarn.py:4: DeprecationWarning: A warning.
warnings.warn("A warning.", DeprecationWarning)
There is no exception raised, though the filter was
instructed to turn the warning into an error. Take
note that using ``always`` has similar results.
Does it work in that way on purpose? I find it quite
counterintuitive, IMHO. If this behaviour is intended,
what would be the way to turn the second warning into
an exception?
Thanks!
--
>Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2005-04-29 12:54
Message:
Logged In: YES
user_id=1064183
OK, I see. Then the documentation for ``warnings.warn()``
may be more precise. Where it says This function raises an
exception if the particular warning issued is changed into
an error by the warnings filter see above. it may append
and that warning has not already been filtered.
Anyway, I still think that one should expect to *always* get
an exception once the warnings filter has been instructed to
turn a warning into an exception, instead of maybe filtering
it. The later could lead to some errors to pass
unadvertised and get delayed. It also disables the
possibility of turning every warning into an error in the
middle of a session (à la gcc's ``-pedantic-errors`` option).
My proposal is not to filter a warning once it has been
instructed to cause an exception. The existing code should
not need to worry about using ``warn()`` or
``warn_explicit()`` (since in the usual situation, duplicate
warnings --not exceptions-- should still be filtered).
Thanks for your attention,
Ivan
--
Comment By: Vinay Sajip (vsajip)
Date: 2005-04-29 10:17
Message:
Logged In: YES
user_id=308438
This does not appear to be a bug. For example, the following
script (indentation may get messed up):
#--
import sys, warnings
def do_warn():
fn = sys.modules["__main__"].__file__
warnings.warn_explicit("A warning.", DeprecationWarning,
fn, 0)
def main():
do_warn()
warnings.filterwarnings('error',
category=DeprecationWarning)
try:
do_warn()
except Exception, e:
print "exception handled: %s" % e
warnings.filterwarnings('always',
category=DeprecationWarning)
do_warn()
if __name__ == "__main__":
main()
#--
prints
C:\temp\nowarn.py:0: DeprecationWarning: A warning.
exception handled: A warning.
C:\temp\nowarn.py:0: DeprecationWarning: A warning.
So the problem is that if you want explicit warnings, you
need to use warn_explicit() rather than warn().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191104&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1184678 ] "replace" function should accept lists.
Feature Requests item #1184678, was opened at 2005-04-17 19:05
Message generated for change (Comment added) made by poromenos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470
Category: None
Group: None
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Poromenos (poromenos)
Assigned to: Nobody/Anonymous (nobody)
Summary: "replace" function should accept lists.
Initial Comment:
It would be nice if the "replace" function accepted lists/
tuples and replaced each item in the "old" list with the
corresponding item in the "new" list.
--
>Comment By: Poromenos (poromenos)
Date: 2005-04-29 16:03
Message:
Logged In: YES
user_id=267121
There was an oversight on my part... Translate can only be
used to change individual characters, what I am proposing
could replace strings of multiple characters, essentially
concatenating multiple replace()s in one:
>>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"])
'Hello, World!'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-19 01:23
Message:
Logged In: YES
user_id=267121
Ah, I did not know that... The docs are a bit complicated on .
translate, but since it can do that, yes, it would be unwise to
implement my suggestion.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-19 01:20
Message:
Logged In: YES
user_id=80475
I'm -1 on complicating str.replace()'s API for functionality
that substantially duplicates that offered by str.translate():
>>> "Hello world".translate(string.maketrans('ed', 'ae'))
'Hallo worle'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-19 00:15
Message:
Logged In: YES
user_id=267121
Hmm, actually I was requesting that string.replace() accepted
lists of substitutions, like so:
>>> "Hello world".replace(["e", "d"], ["a", "e"])
'Hallo worle'
But your suggestion would also be very useful.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-19 00:11
Message:
Logged In: YES
user_id=80475
Are you requesting that lists be given a replace() method
that parallels the replace() method for strings?
def replace(self, old, new):
result = []
for elem in self:
if elem == old:
result.append(new)
else:
result.append(elem)
self[:] = result
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189811 ] pydoc may hide non-private doc strings.
Bugs item #1189811, was opened at 2005-04-25 16:00
Message generated for change (Comment added) made by jlivingston
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189811&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: J Livingston (jlivingston)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc may hide non-private doc strings.
Initial Comment:
I am using Python version 2.3.4, pydoc version 1.86.8.1
on WinXP SP2.
pydoc's visiblename() method indicates "Private names
are hidden, but special names are displayed". However,
visiblename's private name qualifier seems to be
(name.startswith('_')) while Python's private name
qualifier is something more along the lines of
((name.startswith('__') and ((name[-1] != '_') or ((name[-1]
== '_') and (name[-2] != '_'.
Having said that, it would be useful if a command line
switch enabled documentation for private names. This
would be helpful in a development environment...
--
>Comment By: J Livingston (jlivingston)
Date: 2005-04-29 08:38
Message:
Logged In: YES
user_id=1160595
An amendment is need for this enhancement request...
The focus at the time of submitting the request was that of
classes and their private data. It seems the comment in the
code and the code itself may have been written with the focus
of modules and the rule that prohibits importing names that
begin with '_' when an 'import *' is used for a module.
This may open another can of worms altogether. To
distinguish the 'private' names of modules and classes
visiblenames() would have to employ different logic for each.
Also, one would wonder if the elements of an __all__ list
would have to be considered the non-private names of a
module or package... From this point, a discussion of what is
considered private could become quite lengthy and also
subjective.
Although discussion regarding this level of complexity may be
relevant at some point, the intent of the enhancement request
was primarily to allow 'private' doc strings to be visible if
explicitly requested.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189811&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1184678 ] "replace" function should accept lists.
Feature Requests item #1184678, was opened at 2005-04-17 11:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470
Category: None
Group: None
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Poromenos (poromenos)
Assigned to: Nobody/Anonymous (nobody)
Summary: "replace" function should accept lists.
Initial Comment:
It would be nice if the "replace" function accepted lists/
tuples and replaced each item in the "old" list with the
corresponding item in the "new" list.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 09:10
Message:
Logged In: YES
user_id=80475
Given the multiple alternative input matches, this is a job
for regular expressions. See the string.substitute() source
code for an approach to making the transformation you outlined.
I do not think multi-replace is sufficiently common to
warrant a change to the API. If needed and if the regexp
solution is too hard, then a regular for-loop is a
reasonable alternative:
for old, new in zip(oldlist, newlist):
s = s.replace(old, new)
--
Comment By: Poromenos (poromenos)
Date: 2005-04-29 08:03
Message:
Logged In: YES
user_id=267121
There was an oversight on my part... Translate can only be
used to change individual characters, what I am proposing
could replace strings of multiple characters, essentially
concatenating multiple replace()s in one:
>>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"])
'Hello, World!'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-18 17:23
Message:
Logged In: YES
user_id=267121
Ah, I did not know that... The docs are a bit complicated on .
translate, but since it can do that, yes, it would be unwise to
implement my suggestion.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-18 17:20
Message:
Logged In: YES
user_id=80475
I'm -1 on complicating str.replace()'s API for functionality
that substantially duplicates that offered by str.translate():
>>> "Hello world".translate(string.maketrans('ed', 'ae'))
'Hallo worle'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-18 16:15
Message:
Logged In: YES
user_id=267121
Hmm, actually I was requesting that string.replace() accepted
lists of substitutions, like so:
>>> "Hello world".replace(["e", "d"], ["a", "e"])
'Hallo worle'
But your suggestion would also be very useful.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-18 16:11
Message:
Logged In: YES
user_id=80475
Are you requesting that lists be given a replace() method
that parallels the replace() method for strings?
def replace(self, old, new):
result = []
for elem in self:
if elem == old:
result.append(new)
else:
result.append(elem)
self[:] = result
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
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
[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
Feature Requests item #1190596, was opened at 2005-04-26 17:10 Message generated for change (Comment added) made by rhettinger 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: 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: Raymond Hettinger (rhettinger) Date: 2005-04-29 09: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 09: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 17: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 08: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 07: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 07: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 06: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 06: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 01: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
[ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired
Feature Requests item #1190596, was opened at 2005-04-26 18:10 Message generated for change (Comment added) made by tseaver 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: 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: Tres Seaver (tseaver) Date: 2005-04-29 11: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 10: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 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=1
[ python-Bugs-1192554 ] doctest's ELLIPSIS and multiline statements
Bugs item #1192554, was opened at 2005-04-29 19:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sébastien Boisgérault (boisgerault)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest's ELLIPSIS and multiline statements
Initial Comment:
The doctest ELLPSIS marker (default: "...") may be
confused by the doctest parser with the multiline
statement marker ("...").
Example: in the following code, the intent was to accept
any result after "print 42". This is NOT a multiline
statement,
but however the test fails (Expected: nothing, Got: 42).
#!/usr/bin/env python
import doctest
def test():
"""
>>> print 42 #doctest: +ELLIPSIS
...
"""
def run():
"Run the test."
doctest.testmod()
if __name__ == '__main__':
run()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1192554 ] doctest's ELLIPSIS and multiline statements
Bugs item #1192554, was opened at 2005-04-29 13:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sébastien Boisgérault (boisgerault)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest's ELLIPSIS and multiline statements
Initial Comment:
The doctest ELLPSIS marker (default: "...") may be
confused by the doctest parser with the multiline
statement marker ("...").
Example: in the following code, the intent was to accept
any result after "print 42". This is NOT a multiline
statement,
but however the test fails (Expected: nothing, Got: 42).
#!/usr/bin/env python
import doctest
def test():
"""
>>> print 42 #doctest: +ELLIPSIS
...
"""
def run():
"Run the test."
doctest.testmod()
if __name__ == '__main__':
run()
--
>Comment By: Tim Peters (tim_one)
Date: 2005-04-29 13:52
Message:
Logged In: YES
user_id=31435
That's true. doctest has few syntax requirements, but the
inability to start an expected output block with "..." has
always been one of them, and is independent of the
ELLIPSIS gimmick. I doubt this will change, in part because
the complications needed to "do something about it" are
probably pig ugly, in part because it's so rare a desire, and in
part because there are easy ways to work around it (like
arranging for the expected output to start with something
other than '...').
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-999042 ] Compiler module doesn't handle global statement correctly
Bugs item #999042, was opened at 2004-07-27 22:15
Message generated for change (Comment added) made by dsuch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler module doesn't handle global statement correctly
Initial Comment:
If we don't use the compiler module:
>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})
with the compiler module:
>>> code = compiler.compile('global x\nx=1', 'd', 'exec')
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})
global is ignored
--
Comment By: Darek Suchojad (dsuch)
Date: 2005-04-29 22:04
Message:
Logged In: YES
user_id=954779
Hi, I have submitted a simple fix some time ago
python.org/sf/1090482, do you think it is correct?
--
Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 14:01
Message:
Logged In: YES
user_id=73023
Also in 2.3
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1192777 ] docstring error
Bugs item #1192777, was opened at 2005-04-29 17:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192777&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Smith (smichr) Assigned to: Nobody/Anonymous (nobody) Summary: docstring error Initial Comment: In 2.4/Lib/test/test_binop.py, two double quotes are missing at the beginning of the following function's docstring: def __rdivmod__(self, other): "Divide two Rats, returning quotient and remainder (reversed args).""" (I know it's minor, but you said "keep it under your pillow" ;-) Actually. I found it while testing out a comment stripping program that uses the tokenize module. /c -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192777&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1192777 ] docstring error
Bugs item #1192777, was opened at 2005-04-29 15:51 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192777&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Smith (smichr) Assigned to: Nobody/Anonymous (nobody) Summary: docstring error Initial Comment: In 2.4/Lib/test/test_binop.py, two double quotes are missing at the beginning of the following function's docstring: def __rdivmod__(self, other): "Divide two Rats, returning quotient and remainder (reversed args).""" (I know it's minor, but you said "keep it under your pillow" ;-) Actually. I found it while testing out a comment stripping program that uses the tokenize module. /c -- >Comment By: Brett Cannon (bcannon) Date: 2005-04-29 22:53 Message: Logged In: YES user_id=357491 Fixed in rev. 1.8 for 2.5 and rev. 1.7.20.1 for 2.4 . Thanks, Christopher. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192777&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
