[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]
Bugs item #1402308, was opened at 2006-01-11 01:38
Message generated for change (Comment added) made by titty
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&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: Ralf Schmitt (titty)
Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault when using mmap(-1,...) [+PATCH]
Initial Comment:
This is happening on OSX, Python 2.4.2:
[EMAIL PROTECTED]:~/Python-2.4.2$ cat ~/t.py
#! /usr/bin/env python
import sys
print sys.version
import mmap
mmap.mmap(-1, 4096)
[EMAIL PROTECTED]:~/Python-2.4.2$ ./python ~/t.py
2.4.2 (#1, Jan 11 2006, 00:58:35)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)]
Segmentation fault
The following one line diff solves that problem (mmap's data member
is otherwise uninitialized...)
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:13:06.0
+0100
@@ -910,6 +910,7 @@
#endif
m_obj = PyObject_New (mmap_object, &mmap_object_type);
if (m_obj == NULL) {return NULL;}
+ m_obj->data = NULL;
m_obj->size = (size_t) map_size;
m_obj->pos = (size_t) 0;
m_obj->fd = dup(fd);
However, the problem is that passing -1 as filedescriptor to mmap
is perfectly ok when one wants to mmap anonymous memory (at least
on FreeeBSD and OS X). The following patch also solves that problem.
[mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...]
Any chance to get this included? Passing -1 to mmap should not hurt
anybody, as systems which do not support it, should then return an
error from mmap.
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:23:52.0
+0100
@@ -910,10 +910,12 @@
#endif
m_obj = PyObject_New (mmap_object, &mmap_object_type);
if (m_obj == NULL) {return NULL;}
+ m_obj->data = NULL;
m_obj->size = (size_t) map_size;
m_obj->pos = (size_t) 0;
- m_obj->fd = dup(fd);
- if (m_obj->fd == -1) {
+ if (fd == -1) {
+ m_obj->fd = -1;
+ } else if ((m_obj->fd = dup(fd)) == -1) {
Py_DECREF(m_obj);
PyErr_SetFromErrno(mmap_module_error);
return NULL;
--
>Comment By: Ralf Schmitt (titty)
Date: 2006-01-16 09:46
Message:
Logged In: YES
user_id=17929
patch submitted: https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=1402308&group_id=5470
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-14 22:12
Message:
Logged In: YES
user_id=1188172
Note that MAP_ANON isn't mentioned in the docs, so it's not
official.
Otherwise, I agree with Ralf. -1 should be excluded from
dup()ing and this should be documented.
--
Comment By: Ralf Schmitt (titty)
Date: 2006-01-14 13:45
Message:
Logged In: YES
user_id=17929
1.The mmap module exports MAP_ANON/MAP_ANONYMOUS on unix like
systems, so someone who has been using mmap in C most probably would
expect that passing -1 as fileno is possible in order to do anonymous
mmap's.
(Those who have been using prior versions of python and anonymous mmap
would also expect the same).
2. The workaround (if -1 is artificially forbidden as fileno) is to open /dev/
zero and using that as a fileno to mmap (this doesn't work on OS X). However,
since filedescriptors passed to mmap are now dup'ed (starting from version
2.4.2) this leads to excessive abuse of filedescriptors up to the point that
one
might not be able to use anonymous mmap's because of filedescriptor
limitations.
3. On Windows one can currently pass 0 as fileno in order to allocate
anonymous memory (which seems wrong, even on windows 0 might be a
valid filedescriptor? -1 would be a better value here). This is handled as a
special case in the windows code. So, in Python 2.4.2 it's now harder, maybe
even impossible, to use anonymous mmap's on unix, whereas in windows it's
a no brainer. And this module got it's name from a unix system call :).
4. I don't consider this a feature request. 2.4.2 broke existing code.
Guess, I'll have to send a patch.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-14 08:40
Message:
Logged In: YES
user_id=33168
Thanks. I only fixed the bug as the second part is a
feature request.
Committed
[ python-Bugs-1396030 ] TimedRotatingFileHandler at midnight rolls over at 01:00
Bugs item #1396030, was opened at 2006-01-03 14:26 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&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: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler at midnight rolls over at 01:00 Initial Comment: Using TimedRotatingFileHandler with interval set to midnight rolls the log over at 1:00am rather than midnight. (LocalTime = GMT). This is because the calculation of seconds until midnight is incorrect (it behaves as if there are 24 hours, 59 minutes and 59 seconds in the day). It also means that should a program stop between midnight and 1:00am and restart it fails to roll over the log as the log over time is set to 1:00am the next day. Occurs on Linux (FC3), Windows XP (SP2). Bug occurs (2.4.2 and currently exists in most recent 2.5 SVN code). -- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:11 Message: Logged In: YES user_id=308438 Checked into SVN trunk and release24-maint branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases
Bugs item #1396622, was opened at 2006-01-04 08:25 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&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: Pending >Resolution: Accepted Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:18 Message: Logged In: YES user_id=308438 Fixed the rollover time increase problem (checked into SVN trunk and release24-maint branch). However, DST adjustment has not been done yet. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-14 03:46 Message: Logged In: YES user_id=341410 For this handler, one should also be aware of the fact that when DST changes, the time.timezone doesn't change, so calculation of when midnight actually is (if one does that), may be off by an hour until the daemon restarts. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-05 05:46 Message: Logged In: YES user_id=33168 Vinay, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396040 ] TimedRotatingFileHandler does not recover from open error
Bugs item #1396040, was opened at 2006-01-03 14:38 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&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: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler does not recover from open error Initial Comment: When doing a rollover TimedRotatingFileHandler doRollover does not recover if there is an open error. This is because when the rollover function fails at the open (e.g. too many files open) and is called again at the next attempt to write to the log doRollover attempts to rename (the now no longer existing) original file which raises an exception. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:30 Message: Logged In: YES user_id=308438 Change checked into SVN trunk and release24-maint branch which passes exceptions raised during renaming to handleError (except for SystemExit and KeyboardInterrupt, which are re-raised). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&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-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by cconrad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 11:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-14 19:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? -- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-16 22:29 Message: Logged In: YES user_id=21627 That (arguments not passed to the script) was a bug in some versions of the Windows installer. Please verify that the registry, at (HKCU|HKLM)\Software\Classes\Python.File\open\command has the value '[path]python.exe "%1" %*'. The %* part should arrange for arguments being passed. -- Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 11:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-14 19:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? -- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403221 ] 2.3.5 source RPM install fails w/o tk-devel
Bugs item #1403221, was opened at 2006-01-11 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&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: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 source RPM install fails w/o tk-devel Initial Comment: Install fails because _tkinter.so is not found. This library is not built if the tk header files are not found, but the installer treats this as a fatal error. This dependece upon tk-devel is not noted in the .spec file, so the install fails late (and unclearly) instead of early & clearly. -- >Comment By: Sean Reifschneider (jafo) Date: 2006-01-16 21:59 Message: Logged In: YES user_id=81797 The build doesn't really have a way of adaptively adjusting to whether Tk is available or not. Some people in the past have wanted to build without tk, but perhaps we should just always build with tk? Also, newer RPM versions have a nicer way of doing conditional builds which will probably help this. Any ideas? I'll try to get a new release of the spec file out in the next week and build some SRPMs from them so that people can try them. Currently, this is only addressed by being a FAQ on the RPM pages. Sean -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 07:41 Message: Logged In: YES user_id=33168 Note: we don't maintain 2.3 any longer. Sean any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403225 ] 2.3.5 RPM provides incompatibility
Bugs item #1403225, was opened at 2006-01-11 19:27 Message generated for change (Settings changed) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&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: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 RPM provides incompatibility Initial Comment: The 2.3.5 rpm provides list is substantially out of sync with the 2.3.4-14 provides list for CEntOS, making it impossible (for me) to use this rpm to upgrade my installation. Help? -- >Comment By: Sean Reifschneider (jafo) Date: 2006-01-16 22:13 Message: Logged In: YES user_id=81797 The python.org RPM can't really be that specific -- it wouldn't work on other platforms or even likely older or newer versions of CentOS... python.org's RPM needs to be a bit more generic than that I think. I'd recommend either trying to get Red Hat to push up an update to 3.4.5 (which they arguably should have done as errata), or CentOS if they just haven't kept up with the RHES release. However, Red Hat hasn't been very good about updating to new minor versions of Python historicly, even though by their criteria they would seem to be eligible. Alternatively, you could take things into your own hands and get the CentOS RPM and the 2.3.5 Python source, and udpate the CentOS RPM to 2.3.5. That is probably your best option. Sean -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 07:42 Message: Logged In: YES user_id=33168 Note: we do not maintain 2.3 any longer. Sean? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-902075 ] urllib2 should be more robust for sloppy proxy URLs
Bugs item #902075, was opened at 2004-02-22 21:05 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 should be more robust for sloppy proxy URLs Initial Comment: passing an URL like "foo.bar.baz" instead of "http://foo.bar.baz"; results in a stacktrace: File "/usr/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 491, in lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.3/urllib2.py", line 498, in proxy_open if '@' in host: TypeError: iterable argument required This could be fixed by calling urlparse.urlparse on the proxy url, either in the calling code or in the library code, which I would prefer to make it more robust about sloppy URLs passed in the http_proxy environment variable. -- Comment By: Andrew Bennetts (spiv) Date: 2006-01-17 14:04 Message: Logged In: YES user_id=50945 I think test cases would help the patch at http://bugs.debian.org/233305 get applied. -- Comment By: Chris Lawrence (lordsutch) Date: 2004-03-25 08:51 Message: Logged In: YES user_id=6757 I've put together a patch, which can be found at http://bugs.debian.org/233305; it isn't perfect (ideally the entire routine should be rewritten, as it's processing environment data that could be from the "wild"), but it avoids the traceback. -- Comment By: Matthias Klose (doko) Date: 2004-02-22 21:19 Message: Logged In: YES user_id=60903 Ok, I see, PEP42 ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1407902 ] urlparse does not know about sftp: urls
Bugs item #1407902, was opened at 2006-01-17 14:47
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=1407902&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse does not know about sftp: urls
Initial Comment:
>>> from urlparse import urlparse
>>> urlparse('sftp://example.com//absolute/path')
('sftp', '', '//example.com//absolute/path', '', '', '')
>>> urlparse('sftp://example.com/relative/path')
('sftp', '', '//example.com/relative/path', '', '', '')
netloc should be populated in both cases
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename
Bugs item #1403349, was opened at 2006-01-11 16:47
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&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: Michal P. (mpasniew)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: in email can't get attachments' filenames using get_filename
Initial Comment:
in the email package (2.4.1) the get_filename() method
returns the MIME field "filename" but some messages
have 'name' field instead, for example:
USUALLY THE HEADER IS:
Content-Type: application/octet-stream;
name="XX.pdf"
Content-Transfer-Encoding: base64
Content-Description: XX.pdf
Content-Disposition: attachment;
filename="XX.pdf"
BUT SOMETIMES THE HEADER IS:
Content-type: application/octet-stream; name="XX.xls"
Content-transfer-encoding: base64
For this to work properly I had to code a hack along
these lines:
filename = part.get_filename()
if not filename:
ct = part.get("Content-type")
m = re.compile('name=\"(\S+)\"').search(ct, 1)
if m: filename=m.group(1)
But it would be helpful to code this in the get_filename()
Michal
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-16 23:35
Message:
Logged In: YES
user_id=12800
r42075 for Python 2.3 / email 2.5 (will close after porting
to all other branches).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename
Bugs item #1403349, was opened at 2006-01-11 16:47
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&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: Michal P. (mpasniew)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: in email can't get attachments' filenames using get_filename
Initial Comment:
in the email package (2.4.1) the get_filename() method
returns the MIME field "filename" but some messages
have 'name' field instead, for example:
USUALLY THE HEADER IS:
Content-Type: application/octet-stream;
name="XX.pdf"
Content-Transfer-Encoding: base64
Content-Description: XX.pdf
Content-Disposition: attachment;
filename="XX.pdf"
BUT SOMETIMES THE HEADER IS:
Content-type: application/octet-stream; name="XX.xls"
Content-transfer-encoding: base64
For this to work properly I had to code a hack along
these lines:
filename = part.get_filename()
if not filename:
ct = part.get("Content-type")
m = re.compile('name=\"(\S+)\"').search(ct, 1)
if m: filename=m.group(1)
But it would be helpful to code this in the get_filename()
Michal
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-17 00:09
Message:
Logged In: YES
user_id=12800
r42076 for email 3.0 / python 2.5
r42077 for python 2.4
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-16 23:35
Message:
Logged In: YES
user_id=12800
r42075 for Python 2.3 / email 2.5 (will close after porting
to all other branches).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1407069 ] bz2module with no long long type support
Bugs item #1407069, was opened at 2006-01-15 22:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407069&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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Neal Norwitz (nnorwitz) Summary: bz2module with no long long type support Initial Comment: in Modules/bz2module.c #if SIZEOF_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((long)bzs->total_out_hi32 << 32) + bzs- >total_out_lo32) #elif SIZEOF_LONG_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((PY_LONG_LONG)bzs->total_out_hi32 << 32) + bzs->total_out_lo32) #else #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; #endif when #else statmen execute it leads to error, because no semicolon needed in the end of definition: #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; This error found in version 2.3.5 and 2.4.2. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-16 21:29 Message: Logged In: YES user_id=33168 Thanks! Fixed in head and 2.4 (we don't maintain 2.3 any longer). Committed revision 42080. Committed revision 42081. (2.4) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1347874 ] FeedParser does not comply with RFC2822
Bugs item #1347874, was opened at 2005-11-03 21:58
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&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: Julian Phillips (quantumfyre)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: FeedParser does not comply with RFC2822
Initial Comment:
FeedParser (from Lib/email/FeedParser.py) uses
the regular expression:
^(From |[\041-\071\073-\176]{2,}:|[\t ])
to recognise Mail headers. However RFC2822
says:
field-name := 1*ftext
which would give the regular expression:
^(From |[\041-\071\073-\176]{1,}:|[\t ])
This causes mails that use single character
header field names to be parsed incorrectly.
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-17 01:00
Message:
Logged In: YES
user_id=12800
Fixed as suggested.
r42083 in the trunk (Python 2.5)
r42084 in the release24-maint branch (Python 2.4)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
