[ python-Feature Requests-1283110 ] Give __len__() advice for "don't know"

2005-09-06 Thread SourceForge.net 
Feature Requests item #1283110, was opened at 2005-09-06 11:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give __len__() advice for "don't know"

Initial Comment:
A class may wish to define __len__() despite that it 
doesn't know how many objects iterating an instance 
may produce.  The docs should give advice for this 
case.  They should also explicitly point out that the 
result of __len__() is generally taken to be a _hint_ 
(functions like map(), tuple(), etc., may preallocate 
space based on __len__()'s result, but adjust to the 
actual number of objects produced).

Tail end of a related thread:



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale

2005-09-06 Thread SourceForge.net 
Bugs item #1280061, was opened at 2005-09-01 13:06
Message generated for change (Comment added) made by meonkeys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&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: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Adam Monsen (meonkeys)
Assigned to: Brett Cannon (bcannon)
Summary: time.strptime() fails with unicode date string, de_DE locale

Initial Comment:
Trying to parse a German date string fails in Python
2.4.1. Test case attached.

Since there's no indenting, I suppose the test case can
also be pasted here:

import locale, time
locale.setlocale(locale.LC_TIME, 'de_DE')
date = u'10. September 2005 um 17:26'
format = '%d. %B %Y um %H:%M'
time.strptime(date, format)

--
Adam Monsen
http://adammonsen.com/

--

>Comment By: Adam Monsen (meonkeys)
Date: 2005-09-06 11:04

Message:
Logged In: YES 
user_id=259388

Ok, sounds good.

For anyone trying to work around this, unicode date strings
should be encoded to simple Python strings (type of str)
before passing into strptime. Here's an updated version of
the aforementioned test case demonstrating an acceptable
workaround:

import locale, time
locale.setlocale(locale.LC_TIME, 'de_DE')
date = u'September'.encode()
format = '%B'
time.strptime(date, format)

--
Adam Monsen <[EMAIL PROTECTED]>
http://adammonsen.com/

--

Comment By: Brett Cannon (bcannon)
Date: 2005-09-02 14:05

Message:
Logged In: YES 
user_id=357491

OK, then that settles it.  If time.strftime() ever returned
unicode, I would say this needs fixing.  But since
time.strptime() is meant to be the mirror opposite of
time.strftime(), I am going to close this as "Won't Fix". 
If time.strftime() ever gets changed to return unicode, then
I will fix it.

--

Comment By: Adam Monsen (meonkeys)
Date: 2005-09-02 13:57

Message:
Logged In: YES 
user_id=259388

I get a str from time.strftime().

>>> import time
>>> time.strftime('%B')
'September'
>>> time.strftime('%B').__class__


--

Comment By: Brett Cannon (bcannon)
Date: 2005-09-02 13:37

Message:
Logged In: YES 
user_id=357491

Can you let me know what time.strftime() outputs for your
test case, specifically what type of basestring (str or
unicode)?

--

Comment By: Adam Monsen (meonkeys)
Date: 2005-09-02 09:43

Message:
Logged In: YES 
user_id=259388

Here's a simpler, more precise test case (also attached):

import locale, time
locale.setlocale(locale.LC_TIME, 'de_DE')
date = u'September'; format = '%B'
time.strptime(date, format)

Here's the error I see:

Traceback (most recent call last):
  File "de_strptime_fail_simple.py", line 4, in ?
time.strptime(date, format)
  File "/usr/lib/python2.4/_strptime.py", line 329, in strptime
month = locale_time.f_month.index(found_dict['B'].lower())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in
position 1: ordinal not in range(128)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message

2005-09-06 Thread SourceForge.net 
Bugs item #1283289, was opened at 2005-09-06 15:12
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=1283289&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: japierro (japierro)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords gives misleading error message

Initial Comment:
Python 2.3.3 on Windows XP

If the user supplies one valid and one invalid keyword to 
a function that defines two required keyword arguments, 
PyArg_ParseTupleAndKeywords will raise this 
exception:

TypeError: function takes exactly 2 arguments (1 given)

If, in getargs.c, vgetargskeywords, the check 
for "extraneous keywords" were done near the top of the 
function, a more meaningful exception would be thrown:

TypeError: 'bad' is an invalid keyword argument for this 
function


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1283491 ] nit for builtin sum doc

2005-09-06 Thread SourceForge.net 
Bugs item #1283491, was opened at 2005-09-07 00:18
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=1283491&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: daishi harada (daishiharada)
Assigned to: Nobody/Anonymous (nobody)
Summary: nit for builtin sum doc

Initial Comment:
the docstring signature for sum in bltinmodule.c
should be changed from:
sum(sequence, start=0)
to:
sum(sequence[, start])
to reflect the current implementation in builtin_sum.

(or else the implementation should be changed
to accept kwargs.)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1283491 ] nit for builtin sum doc

2005-09-06 Thread SourceForge.net 
Bugs item #1283491, was opened at 2005-09-06 19:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&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: None
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: daishi harada (daishiharada)
Assigned to: Nobody/Anonymous (nobody)
Summary: nit for builtin sum doc

Initial Comment:
the docstring signature for sum in bltinmodule.c
should be changed from:
sum(sequence, start=0)
to:
sum(sequence[, start])
to reflect the current implementation in builtin_sum.

(or else the implementation should be changed
to accept kwargs.)

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-06 22:11

Message:
Logged In: YES 
user_id=80475

While the proposed change is technically correct, I find the
original to be more informative.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers

2005-09-06 Thread SourceForge.net 
Bugs item #1282539, was opened at 2005-09-05 16:12
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fons Dijkstra (fdij)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.shutdown() not correct for chained handlers

Initial Comment:
Consider the following code:

import logging
import logging.handlers

if __name__ == "__main__":
fh = logging.handlers.RotatingFileHandler("log.txt")
mh = logging.handlers.MemoryHandler(1024, 
logging.ERROR, fh)
logging.getLogger().addHandler(mh)
logging.getLogger().warning("next statement crashes")
logging.shutdown()

which results in a crash due to operating on a closed 
file. The reason is that the shutdown flushes and closes 
all handlers in undefined order. In above case, first 
the 'fh' handlers is flushes and closed then the 'mh' 
handler.

The solution is to first flush all handlers times the 
number of handlers before closing them. Thus (omitting 
error handling):

def shutdown():
for i in range(len(_handlers)):
for h in _handlers.keys():
h.flush()
for h in _handlers.keys():
h.close()


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&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-1283110 ] Give __len__() advice for "don't know"

2005-09-06 Thread SourceForge.net 
Feature Requests item #1283110, was opened at 2005-09-06 10:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give __len__() advice for "don't know"

Initial Comment:
A class may wish to define __len__() despite that it 
doesn't know how many objects iterating an instance 
may produce.  The docs should give advice for this 
case.  They should also explicitly point out that the 
result of __len__() is generally taken to be a _hint_ 
(functions like map(), tuple(), etc., may preallocate 
space based on __len__()'s result, but adjust to the 
actual number of objects produced).

Tail end of a related thread:



--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-07 00:24

Message:
Logged In: YES 
user_id=80475

FWIW, I had explored this topic at some length with Guido's
input and arrived at somewhat similar guidance. At any given
time, a dynamic object with a __len__() method should report
accurately or not at all (raising a TypeError).  Accurate
means that at that moment, len(d) == len(list(d)).  
Subsequent mutations may affect the length and the __len__()
method is expected to adjust accordingly.  For more notes on
the subject, see the module docstring for
Lib/test/test_iterlen.py

In the face of dynamic inputs, consumer functions like map()
must regard the reported lengths as estimates. However, that
should not lower the standards for objects reporting their
length.  That number should continue to have some meaning
such as the point-in-time invariant described above.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com