[ python-Bugs-1594966 ] doctest simple usage recipe is misleading
Bugs item #1594966, was opened at 2006-11-12 10:31 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=1594966&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Rimey (yemir) Assigned to: Nobody/Anonymous (nobody) Summary: doctest simple usage recipe is misleading Initial Comment: "23.2.1 Simple Usage: Checking Examples in Docstrings" sets up a trap for the unsuspecting developer: http://docs.python.org/lib/doctest-simple-testmod.html That page recommends adding the following code to the end of a module using doctest: def _test(): import doctest doctest.testmod() if __name__ == "__main__": _test() The problem is that a reasonable person will figure that _test() has been defined for convenience in executing the tests from other Python code as follows: import M M._test() However, that executes the doctests found in __main__, not M! I think the recommended recipe should instead be as follows: if __name__ == "__main__": import doctest doctest.testmod() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1594809 ] make install fails, various modules do not work
Bugs item #1594809, was opened at 2006-11-11 21:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Evan (erflynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails, various modules do not work
Initial Comment:
I compiled Python 2.5 on a Linux user account on Debian
3.0. configure and make seemed to go okay, but make
install failed at 'zipfile.py' when it was compiling
modules into bytecode. I can still use the python
interpreter. However, some important modules seem to
be missing such as 'time' and 'operator'.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 10:57
Message:
Logged In: YES
user_id=21627
Can you please do
file build/lib.linux-i686-2.5/unicodedata.so
and also, in ./python
print sys.path
According to your make.log, unicodedata.so ought to be present.
--
Comment By: Evan (erflynn)
Date: 2006-11-12 02:12
Message:
Logged In: YES
user_id=1642549
It could be a good start...
[EMAIL PROTECTED] 267>./python -Wi -tt
Python 2.5 (r25:51908, Nov 10 2006, 20:10:11)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import unicodedata
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named unicodedata
>>>
Maybe it's not linking some modules in?
Would it be helpful if I let you SSH to the box?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 01:28
Message:
Logged In: YES
user_id=21627
I think I know what the cause of the problem is (although
not the root cause):
Compiling
/home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py
...
Sorry: UnicodeError: ("\\N escapes not supported (can't load
unicodedata module)",)
So compilation for test_multibytecodec fails, causing
compileall to fail.
In the build directory, can you please run
PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5
./python -Wi -tt
and do
import unicodedata
print unicodedata.ucnhash_CAPI
import test.test_multibytecodec
and report its output?
--
Comment By: Evan (erflynn)
Date: 2006-11-11 22:44
Message:
Logged In: YES
user_id=1642549
No I didn't run over quota. Running python in the directory
it was built does not do anything differently.
The logs indicate that 4 regression tests failed during
'make test'. This is reproducible.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-11-11 21:54
Message:
Logged In: YES
user_id=357491
Looking through the logs it looks like libinstall had an
error. Did you run over quota in your home directory? The
log for 'make' shows that 'time' was built. I bet if you
run the Python executable in the directory where you
compiled you will find you can import 'time' and such fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1316069 ] gzip.GzipFile.seek missing second argument
Bugs item #1316069, was opened at 2005-10-07 21:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.seek missing second argument Initial Comment: It would nice if GzipFile.seek matched file.seek and BZ2File.seek and took a second argument. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 11:42 Message: Logged In: YES user_id=21627 This was fixed with said patch, in r52737. -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-13 11:45 Message: Logged In: YES user_id=21627 Patches can (and should) be attached to the bugs if possible. With SF access control, only the submitter and a patch admin may do so, though. -- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:57 Message: Logged In: YES user_id=38376 I've posted a trivial patch over at www.python.org/sf/1355023 (can patches be attached to bugs, or do we always want them over at the patch tracker?) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 15:14 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=1595045&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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595164 ] texinfo library documentation fails to build
Bugs item #1595164, was opened at 2006-11-12 19:15 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=1595164&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1594809 ] make install fails, various modules do not work
Bugs item #1594809, was opened at 2006-11-11 15:27
Message generated for change (Comment added) made by erflynn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Evan (erflynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails, various modules do not work
Initial Comment:
I compiled Python 2.5 on a Linux user account on Debian
3.0. configure and make seemed to go okay, but make
install failed at 'zipfile.py' when it was compiling
modules into bytecode. I can still use the python
interpreter. However, some important modules seem to
be missing such as 'time' and 'operator'.
--
>Comment By: Evan (erflynn)
Date: 2006-11-12 16:03
Message:
Logged In: YES
user_id=1642549
As I understand it, these modules are actually shared
libraries or 'extensions'.
I unset PYTHONPATH and PYTHONHOME, and the build and install
went just fine. Arrgh.
I wonder why I had to set them in the first place...
Thanks for the help. I'm not sure what the protocol is for
creating source builds, but it might be nice if in the
future the source distribution would (a) run compileall
during make and not make install and (b) try to rely more on
configure options and not environment variables.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 04:57
Message:
Logged In: YES
user_id=21627
Can you please do
file build/lib.linux-i686-2.5/unicodedata.so
and also, in ./python
print sys.path
According to your make.log, unicodedata.so ought to be present.
--
Comment By: Evan (erflynn)
Date: 2006-11-11 20:12
Message:
Logged In: YES
user_id=1642549
It could be a good start...
[EMAIL PROTECTED] 267>./python -Wi -tt
Python 2.5 (r25:51908, Nov 10 2006, 20:10:11)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import unicodedata
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named unicodedata
>>>
Maybe it's not linking some modules in?
Would it be helpful if I let you SSH to the box?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-11 19:28
Message:
Logged In: YES
user_id=21627
I think I know what the cause of the problem is (although
not the root cause):
Compiling
/home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py
...
Sorry: UnicodeError: ("\\N escapes not supported (can't load
unicodedata module)",)
So compilation for test_multibytecodec fails, causing
compileall to fail.
In the build directory, can you please run
PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5
./python -Wi -tt
and do
import unicodedata
print unicodedata.ucnhash_CAPI
import test.test_multibytecodec
and report its output?
--
Comment By: Evan (erflynn)
Date: 2006-11-11 16:44
Message:
Logged In: YES
user_id=1642549
No I didn't run over quota. Running python in the directory
it was built does not do anything differently.
The logs indicate that 4 regression tests failed during
'make test'. This is reproducible.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-11-11 15:54
Message:
Logged In: YES
user_id=357491
Looking through the logs it looks like libinstall had an
error. Did you run over quota in your home directory? The
log for 'make' shows that 'time' was built. I bet if you
run the Python executable in the directory where you
compiled you will find you can import 'time' and such fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1594809 ] make install fails, various modules do not work
Bugs item #1594809, was opened at 2006-11-11 21:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&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: Installation
Group: Python 2.5
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Evan (erflynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails, various modules do not work
Initial Comment:
I compiled Python 2.5 on a Linux user account on Debian
3.0. configure and make seemed to go okay, but make
install failed at 'zipfile.py' when it was compiling
modules into bytecode. I can still use the python
interpreter. However, some important modules seem to
be missing such as 'time' and 'operator'.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 22:33
Message:
Logged In: YES
user_id=21627
Ok, closing this as "works for me" - if you set PYTHON*
while building Python, you are on your own - don't do that,
then.
AFAICT, (a) running compileall during make would not have
helped, it still would not have found the correct
unicodedata module. (b) the installation doesn't rely on
environment variables; as you found, they actually hurt.
--
Comment By: Evan (erflynn)
Date: 2006-11-12 22:03
Message:
Logged In: YES
user_id=1642549
As I understand it, these modules are actually shared
libraries or 'extensions'.
I unset PYTHONPATH and PYTHONHOME, and the build and install
went just fine. Arrgh.
I wonder why I had to set them in the first place...
Thanks for the help. I'm not sure what the protocol is for
creating source builds, but it might be nice if in the
future the source distribution would (a) run compileall
during make and not make install and (b) try to rely more on
configure options and not environment variables.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 10:57
Message:
Logged In: YES
user_id=21627
Can you please do
file build/lib.linux-i686-2.5/unicodedata.so
and also, in ./python
print sys.path
According to your make.log, unicodedata.so ought to be present.
--
Comment By: Evan (erflynn)
Date: 2006-11-12 02:12
Message:
Logged In: YES
user_id=1642549
It could be a good start...
[EMAIL PROTECTED] 267>./python -Wi -tt
Python 2.5 (r25:51908, Nov 10 2006, 20:10:11)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import unicodedata
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named unicodedata
>>>
Maybe it's not linking some modules in?
Would it be helpful if I let you SSH to the box?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 01:28
Message:
Logged In: YES
user_id=21627
I think I know what the cause of the problem is (although
not the root cause):
Compiling
/home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py
...
Sorry: UnicodeError: ("\\N escapes not supported (can't load
unicodedata module)",)
So compilation for test_multibytecodec fails, causing
compileall to fail.
In the build directory, can you please run
PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5
./python -Wi -tt
and do
import unicodedata
print unicodedata.ucnhash_CAPI
import test.test_multibytecodec
and report its output?
--
Comment By: Evan (erflynn)
Date: 2006-11-11 22:44
Message:
Logged In: YES
user_id=1642549
No I didn't run over quota. Running python in the directory
it was built does not do anything differently.
The logs indicate that 4 regression tests failed during
'make test'. This is reproducible.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-11-11 21:54
Message:
Logged In: YES
user_id=357491
Looking through the logs it looks like libinstall had an
error. Did you run over quota in your home directory? The
log for 'make' shows that 'time' was built. I bet if you
run the Python executable in the directory where you
compiled you will find you can import 'time' and such fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/
[ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly
Bugs item #1580563, was opened at 2006-10-19 16:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 22:34 Message: Logged In: YES user_id=21627 ajung: can you please report what environment settings you are using? If you have set PYTHON* in your environment, make sure to unset all these variables. -- Comment By: Evan (erflynn) Date: 2006-11-11 21:29 Message: Logged In: YES user_id=1642549 I created a new bug report so I could attach a file. See #1594809 -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-11 00:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. -- Comment By: Evan (erflynn) Date: 2006-11-10 21:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-20 09:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. -- Comment By: Andreas Jung (ajung) Date: 2006-10-19 20:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 19:26 Message: Logged In: YES user_id=580910 What are t
[ python-Bugs-1595164 ] texinfo library documentation fails to build
Bugs item #1595164, was opened at 2006-11-12 20:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 22:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 14:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 22:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1594809 ] make install fails, various modules do not work
Bugs item #1594809, was opened at 2006-11-11 15:27
Message generated for change (Comment added) made by erflynn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&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: Installation
Group: Python 2.5
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Evan (erflynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails, various modules do not work
Initial Comment:
I compiled Python 2.5 on a Linux user account on Debian
3.0. configure and make seemed to go okay, but make
install failed at 'zipfile.py' when it was compiling
modules into bytecode. I can still use the python
interpreter. However, some important modules seem to
be missing such as 'time' and 'operator'.
--
>Comment By: Evan (erflynn)
Date: 2006-11-12 16:57
Message:
Logged In: YES
user_id=1642549
OK but there should be a note about this in the README:
something like "if you are reinstalling Python or upgrading
to a newer version, make sure to unset PYTHONHOME and
PYTHONPATH." Or have the makefile use "python -E" while
building Python.
It is pretty strange to see a "make" run fine but the "make
install" bombs. If you move compileall to the "make" stage,
then you would know sooner if there was a problem.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 16:33
Message:
Logged In: YES
user_id=21627
Ok, closing this as "works for me" - if you set PYTHON*
while building Python, you are on your own - don't do that,
then.
AFAICT, (a) running compileall during make would not have
helped, it still would not have found the correct
unicodedata module. (b) the installation doesn't rely on
environment variables; as you found, they actually hurt.
--
Comment By: Evan (erflynn)
Date: 2006-11-12 16:03
Message:
Logged In: YES
user_id=1642549
As I understand it, these modules are actually shared
libraries or 'extensions'.
I unset PYTHONPATH and PYTHONHOME, and the build and install
went just fine. Arrgh.
I wonder why I had to set them in the first place...
Thanks for the help. I'm not sure what the protocol is for
creating source builds, but it might be nice if in the
future the source distribution would (a) run compileall
during make and not make install and (b) try to rely more on
configure options and not environment variables.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-12 04:57
Message:
Logged In: YES
user_id=21627
Can you please do
file build/lib.linux-i686-2.5/unicodedata.so
and also, in ./python
print sys.path
According to your make.log, unicodedata.so ought to be present.
--
Comment By: Evan (erflynn)
Date: 2006-11-11 20:12
Message:
Logged In: YES
user_id=1642549
It could be a good start...
[EMAIL PROTECTED] 267>./python -Wi -tt
Python 2.5 (r25:51908, Nov 10 2006, 20:10:11)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import unicodedata
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named unicodedata
>>>
Maybe it's not linking some modules in?
Would it be helpful if I let you SSH to the box?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-11 19:28
Message:
Logged In: YES
user_id=21627
I think I know what the cause of the problem is (although
not the root cause):
Compiling
/home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py
...
Sorry: UnicodeError: ("\\N escapes not supported (can't load
unicodedata module)",)
So compilation for test_multibytecodec fails, causing
compileall to fail.
In the build directory, can you please run
PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5
./python -Wi -tt
and do
import unicodedata
print unicodedata.ucnhash_CAPI
import test.test_multibytecodec
and report its output?
--
Comment By: Evan (erflynn)
Date: 2006-11-11 16:44
Message:
Logged In: YES
user_id=1642549
No I didn't run over quota. Running python in the directory
it was built does not do anything differently.
The logs indicate that 4 regression tests failed during
'make test'. This is reproducible.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-11-11 15:54
Message:
Logged In: YES
user_id=357491
Looking through the logs
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- >Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 13:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-12 22:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. -- Comment By: Avi Kivity (avik) Date: 2006-11-12 22:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 21:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- >Comment By: Avi Kivity (avik) Date: 2006-11-13 01:05 Message: Logged In: YES user_id=539971 Sorry, the report is completely bogus. smtplib already does the necessary quoting. I was getting truncated emails from a subversion commit hook, and jumped to conclusions. Turned out the commit hook was using the sendmail command, NOT smtplib (although it does have that option). Sorry for the noise. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 00:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. -- Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency
Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. -- >Comment By: Avi Kivity (avik) Date: 2006-11-13 01:06 Message: Logged In: YES user_id=539971 deleting. -- Comment By: Avi Kivity (avik) Date: 2006-11-13 01:05 Message: Logged In: YES user_id=539971 Sorry, the report is completely bogus. smtplib already does the necessary quoting. I was getting truncated emails from a subversion commit hook, and jumped to conclusions. Turned out the commit hook was using the sendmail command, NOT smtplib (although it does have that option). Sorry for the noise. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 00:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. -- Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 16:38 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- >Comment By: David Watson (baikie) Date: 2006-11-12 23:52 Message: Logged In: YES user_id=1504904 I'd forgotten about this for a while, but I see the docs didn't actually get changed for 2.5. I was going to submit a patch for them today and suggest using subclasses as described below, but then I realized that subclassing wouldn't work, since the code makes use of the module functions _lock_file() and _unlock_file() outside of the lock()/unlock() methods. A possible solution is attached; the Mailbox class is given methods _acquire_lock() and _release_lock() wrapping _lock_file() and _unlock_file(), and these are used instead (thus, they can be overridden as methods, but if someone had replaced _lock_file() in the module namespace instead, then their code would still work). Also attached is a minimal doc patch to describe the new (shorter) list of locking methods. I've called the system-call locking "fcntl()" since that's the usual term when dealing with mailboxes, and the name fcntl.lockf() is misleading (it calls fcntl() directly, not lockf(), and the Linux man pages say that "In general, the relation between lockf() and fcntl() is unspecified."). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 04:21 Message: Logged In: YES user_id=33168 Is the optional parameter necessary if you use inheritance (assuming there's a class/object in there)? Maybe it would be better to have a subclass? Would that be better for us to provide or just to add something to the docs that a user could make a subclass to work around locking issues? I haven't looked at the issues, but if we really need an API change, I'm probably ok with it since it would seem to be quite small. If an API change is really required (doc isn't sufficient), I'd like it to go in ASAP. We could doc for 2.5 and if there's a problem fix for 2.6. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-27 00:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). -- Comment By: David Watson (baikie) Date: 2006-06-26 23:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 14:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) --
[ python-Bugs-1595365 ] User-agent header added by an opener is "frozen"
Bugs item #1595365, was opened at 2006-11-13 03:27 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=1595365&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: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Steinbrink (der_doener) Assigned to: Nobody/Anonymous (nobody) Summary: User-agent header added by an opener is "frozen" Initial Comment: If a Request object gets an User-agent header added by an opener, that header seems to be "frozen". Although header_items() shows the changed header, the request still uses the old one. This does not happen if the header is set before the request is passed to the opener, i.e. when the header is not set automatically, subsequent changes are respected. I'm using Python 2.4.4 from Debian's sid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595365&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
