[ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail()
Bugs item #1217513, was opened at 2005-06-09 12:32 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=1217513&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Omission in docs for smtplib.SMTP.sendmail() Initial Comment: In Library Reference 11.12.1 SMTP Objects, the description of the to_addrs parameter to SMTP.sendmail() is, "a list of RFC 822 to-address strings". In fact sendmail() also allows a single string to be passed as to_addrs. The comment in smtplib.py says, "to_addrs: A list of addresses to send this mail to. A barestring will be treated as a list with 1 address." I suggest the Library Reference be changed to say, "a list of RFC 822 to-address strings or a single to-address string" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074261 ] gzip dies on gz files with many appended headers
Bugs item #1074261, was opened at 2004-11-27 12:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&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: Fixed Priority: 5 Submitted By: Mark Eichin (eichin) Assigned to: A.M. Kuchling (akuchling) Summary: gzip dies on gz files with many appended headers Initial Comment: One of the values of the gzip format is that one can reopen for append and the file is, as a whole, still valid. This is accomplished by adding new headers on reopen. gzip.py (as tested on 2.1, 2.3, and 2.4rc1 freshly built) doesn't deal well with more than a certain number of appended headers. The included test case generates (using gzip.py) such a file, runs gzip -tv on it to show that it is valid, and then tries to read it with gzip.py -- and it blows out, with OverflowError: long int too large to convert to int in earlier releases, MemoryError in 2.4rc1 - what's going on is that gzip.GzipFile.read keeps doubling readsize and calling _read again; _read does call _read_gzip_header, and consumes *one* header. So, readsize doubling means that older pythons blow out by not autopromoting past 2**32, and 2.4 blows out trying to call file.read on a huge value - but basically, more than 30 or so headers and it fails. The test case below is based on a real-world queueing case that generates over 200 appended headers - and isn't bounded in any useful way. I'll think about ways to make GzipFile more clever, but I don't have a patch yet. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 10:23 Message: Logged In: YES user_id=11375 Patch applied to both HEAD and 2.4-maint branches; thanks! -- Comment By: Mark Eichin (eichin) Date: 2004-11-27 18:28 Message: Logged In: YES user_id=79734 Patch sent to patch-tracker as 1074381. -- Comment By: Mark Eichin (eichin) Date: 2004-11-27 12:48 Message: Logged In: YES user_id=79734 Oh, this is actually easy to fix: just clamp readsize. After all, you don't *actually* want to try to read gigabyte chunks most of the time. (The supplied patch allows one to override gzip.GzipFile.max_read_chunk if one really does.) Tested on 2.4rc1, and a version backported to 2.1 works there too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1217591 ] make frameworkinstall fails for non-default location
Bugs item #1217591, was opened at 2005-06-09 08:54
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=1217591&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: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitch Chapman (mitchchapman)
Assigned to: Jack Jansen (jackjansen)
Summary: make frameworkinstall fails for non-default location
Initial Comment:
Mac OS X 10.3.8, Python 2.4.1. Attempts to 'make
frameworkinstall' to a non-default prefix and framework location fail:
$ ./configure --prefix=
--enable-framework=/Frameworks
$ make
$ make frameworkinstall
The last step always attempts to create /usr/local/bin/python,
instead of /bin/python.
The immediate cause appears to be line 20 of
Mac/OSX/Makefile:
bindir=/usr/local/bin
The problem is easier to spot if the 'make frameworkinstall' step is
performed without root permissions:
$ ./configure --prefix=${HOME}/tmp/py241 --enable-
framework=${HOME}/tmp/py241/Frameworks
...
$ make
...
$ make frameworkinstall
...
make -f ./Mac/OSX/Makefile installunixtools DIRMODE=755 FILEMODE=644
srcdir=. builddir=. DESTDIR= prefix=/Users/myself/tmp/py241/
Frameworks/Python.framework/Versions/2.4
/usr/bin/install -c -d /usr/local/bin
install: chmod 755 /usr/local/bin: Operation not permitted
ln -fsn /Users/myself/tmp/py241/Frameworks/Python.framework/
Versions/2.4/bin/python /usr/local/bin/python2.4
ln: /usr/local/bin/python2.4: Permission denied
make[1]: *** [installunixtools] Error 1
make: *** [frameworkinstallunixtools] Error 2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Tony Meyer (anadelonbrin) Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? -- Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you have
[ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4"
Bugs item #1079134, was opened at 2004-12-04 18:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: A.M. Kuchling (akuchling) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:57 Message: Logged In: YES user_id=11375 Change made to the CVS HEAD version of the document; it'll be backported to the 2.4 maintenance branch before any 2.4.2 release. Thanks for reporting this! -- Comment By: Tim Peters (tim_one) Date: 2004-12-04 21:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095328 ] Add 'update FAQ' to release checklist
Bugs item #1095328, was opened at 2005-01-03 18:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Anthony Baxter (anthonybaxter) >Summary: Add 'update FAQ' to release checklist Initial Comment: http://www.python.org/doc/faq/general.html#how- stable-is-python States that the most stable version is 2.3.3. This should be 2.4.0. Modifying (or checking) this FAQ entry should probably be added to the list of things to be done when a new version is released. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 12:01 Message: Logged In: YES user_id=11375 FAQ updated. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-03 18:07 Message: Logged In: YES user_id=80475 Andrew, can you fix this and then assign to Anthony for inclusion on his checklist. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&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: Tony Meyer (anadelonbrin) Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Tim Peters (tim_one) Date: 2005-06-09 12:11 Message: Logged In: YES user_id=31435 My guess is rev 1.57. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? -- Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more usef
[ python-Bugs-1215928 ] Large tarfiles cause overflow
Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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: Tom Emerson (tree) >Assigned to: Raymond Hettinger (rhettinger) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently
Bugs item #1119418, was opened at 2005-02-09 17:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: 6 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '' foo(10, 100, 10) foo(10, 100, step=10) print '' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py 10 100 10 10 100 10 xrange(10, 100, 10) xrange(10, 100) [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 23:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1217881 ] pydoc includes unnecessary files for a package.
Bugs item #1217881, was opened at 2005-06-09 19:38 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=1217881&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc includes unnecessary files for a package. Initial Comment: PyDoc lists all files present in a package directory in a "Package Contents" table instead of only the ones listed in __all__ variable in __init__.py file. This is very inconvenient for packages which are wrappers for some C library since the shared library and a Wrapper get the reference on the package page but then they do not have any comments and their pages are not generated. As a result package page has those annoying dead links. One can probably fix this by creating a special dummy pages for those unused files but it's an agly solution. I do believe that using __all__ variable from __init__.py file when it is defined is more appropriate way to know what files represent the contents of the package. Cheers, Igor -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1217881 ] pydoc includes unnecessary files for a package.
Bugs item #1217881, was opened at 2005-06-09 19:38 Message generated for change (Comment added) made by belyi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc includes unnecessary files for a package. Initial Comment: PyDoc lists all files present in a package directory in a "Package Contents" table instead of only the ones listed in __all__ variable in __init__.py file. This is very inconvenient for packages which are wrappers for some C library since the shared library and a Wrapper get the reference on the package page but then they do not have any comments and their pages are not generated. As a result package page has those annoying dead links. One can probably fix this by creating a special dummy pages for those unused files but it's an agly solution. I do believe that using __all__ variable from __init__.py file when it is defined is more appropriate way to know what files represent the contents of the package. Cheers, Igor -- >Comment By: Igor Belyi (belyi) Date: 2005-06-09 22:18 Message: Logged In: YES user_id=995711 Interestingly, the patch to do this is very small since __all__ variable is already heavy used for other items. Hope it will help, Igor -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
