[ python-Bugs-1423972 ] Email tests fail

2006-02-04 Thread SourceForge.net
Bugs item #1423972, was opened at 2006-02-04 11:23
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=1423972&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
Submitted By: Martin v. Löwis (loewis)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Email tests fail

Initial Comment:
With the recent changes, the email tests now fail with

test test_email failed -- Traceback (most recent call
last):
  File
"/net/tb0/home/loewis/buildbot/trunk.1/build/Lib/email/test/test_email.py",
line 2110, in test_parsedate_acceptable_to_time_functions
eq(int(time.mktime(timetup)), 1044470846)
AssertionError: 109246 != 1044470846

See python.org/dev/buildbot/ for examples.

--

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



[ python-Bugs-1421811 ] CVS (not SVN) mentioned in Python FAQ

2006-02-04 Thread SourceForge.net
Bugs item #1421811, was opened at 2006-02-01 21:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421811&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS (not SVN) mentioned in Python FAQ

Initial Comment:
http://python.org/doc/faq/general.html

1.1.11   How do I get a beta test version of Python?

All releases, including alphas, betas and release
candidates, are announced on the comp.lang.python and
comp.lang.python.announce newsgroups. All announcements
also appear on the Python home page, at
http://www.python.org/; an RSS feed of news is available.

You can also access the development version of Python
through CVS. See
http://sourceforge.net/cvs/?group_id=5470 for details.
If you're not familiar with CVS, documents such as
http://linux.oreillynet.com/pub/a/linux/2002/01/03/cvs_intro.html
provide an introduction.




last paragraph should be about SVN, not CVS

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-02-04 11:28

Message:
Logged In: YES 
user_id=21627

Thanks for the report. This is now fixed.

--

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



[ python-Bugs-1421814 ] 2.4.1 mentioned in Python FAQ as most stable version

2006-02-04 Thread SourceForge.net
Bugs item #1421814, was opened at 2006-02-01 21:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421814&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 mentioned in Python FAQ as most stable version

Initial Comment:
http://python.org/doc/faq/general.html

1.2.1   How stable is Python?

Very stable. 

...

The 2.4.1 release is the most stable version at this
point in time.



Is this info outdated?


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-02-04 11:35

Message:
Logged In: YES 
user_id=21627

Thanks; it was outdated, but is now up-to-date.

--

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



[ python-Bugs-1421839 ] Inconsistency in Programming FAQ

2006-02-04 Thread SourceForge.net
Bugs item #1421839, was opened at 2006-02-01 21:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421839&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Inconsistency in Programming FAQ

Initial Comment:
http://python.org/doc/faq/programming.html

1.6.8   How do I create static class data and static
class methods?
...
Static methods are possible when you're using new-style
classes:

class C:
def static(arg1, arg2, arg3):
# No 'self' parameter!
...
static = staticmethod(static)

- Shouldn't it look like class C(object)?
- it would be nice to mention decorators here


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-02-04 11:41

Message:
Logged In: YES 
user_id=21627

Did you try it out? It works. The comment "new-style
classes" is misleading - what it really should say is that
you need a Python version that has staticmethod.

Andrew, this is your text: would you like to correct it?

--

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



[ python-Bugs-1424017 ] Assert failure in signal handling

2006-02-04 Thread SourceForge.net
Bugs item #1424017, was opened at 2006-02-04 12:50
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=1424017&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: doom (doomtr666)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assert failure in signal handling

Initial Comment:
With Visual Studio 2005 while compiling in debug mode.
Assert faillure occurs line 1657 in pythonrun.c.

New 2005 debug runtime raise an assert while using 
unsupported signals.

Proposed patch :

#else
PyOS_sighandler_t handler;

//  handler = signal(sig, SIG_IGN);
handler = SIG_ERR;

if (handler != SIG_ERR)
signal(sig, handler);
return handler;
#endif

if under visual studio 2005 debug runtime




--

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



[ python-Bugs-1422094 ] email.MIME*.as_string removes duplicate spaces

2006-02-04 Thread SourceForge.net
Bugs item #1422094, was opened at 2006-02-02 03:25
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1422094&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: hads (hads)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.MIME*.as_string removes duplicate spaces

Initial Comment:
In the following example all of the multiple spaces  
in the subject will be compressed into one space  
each.   
   
from email.MIMEMultipart import MIMEMultipart   
   
outer = MIMEMultipart()   
outer['Subject'] = "Subjects   longer than 68  
characters   withmultiple spaces   
get converted toone space."   
   
print outer.as_string()   
  
  
Will print:  
  
Content-Type: multipart/mixed; 
boundary="===0820565010==" 
MIME-Version: 1.0 
Subject: Subjects longer than 68 characters with 
multiple spaces get converted 
to one space. 
 
--===0820565010== 
 
--===0820565010==-- 
  

--

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



[ python-Bugs-1424041 ] The mmap module does unnecessary dup()

2006-02-04 Thread SourceForge.net
Bugs item #1424041, was opened at 2006-02-04 05:39
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=1424041&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: Keith Dart (kdart)
Assigned to: Nobody/Anonymous (nobody)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

--

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



[ python-Bugs-1424041 ] The mmap module does unnecessary dup()

2006-02-04 Thread SourceForge.net
Bugs item #1424041, was opened at 2006-02-04 05:39
Message generated for change (Settings changed) made by kdart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424041&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: Keith Dart (kdart)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

--

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



[ python-Bugs-1424041 ] The mmap module does unnecessary dup()

2006-02-04 Thread SourceForge.net
Bugs item #1424041, was opened at 2006-02-04 05:39
Message generated for change (Comment added) made by kdart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424041&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: Keith Dart (kdart)
Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

--

>Comment By: Keith Dart (kdart)
Date: 2006-02-04 06:33

Message:
Logged In: YES 
user_id=16527

Here is a patch that fixes the problem for anonymous maps.
It simply makes the fd to be ignored if it is less than
zero. This works, but I still don't think having a duped fd
is needed. Whatever it accomplishes could be done in Python.
As a general rule, I prefer these kinds os system call
wrappers to do as little as possible (just wrap the call). 

--

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



[ python-Bugs-1424065 ] The email package needs an "application" type

2006-02-04 Thread SourceForge.net
Bugs item #1424065, was opened at 2006-02-04 06:39
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=1424065&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Dart (kdart)
Assigned to: Nobody/Anonymous (nobody)
Summary: The email package needs an "application" type

Initial Comment:
The email package lacks a top-level MIME class for
"application/*" MIME types. Attached to this bug is one
that you might want to include.


--

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



[ python-Bugs-1424065 ] The email package needs an "application" type

2006-02-04 Thread SourceForge.net
Bugs item #1424065, was opened at 2006-02-04 06:39
Message generated for change (Settings changed) made by kdart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424065&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Dart (kdart)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: The email package needs an "application" type

Initial Comment:
The email package lacks a top-level MIME class for
"application/*" MIME types. Attached to this bug is one
that you might want to include.


--

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



[ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal looses data on POST!

2006-02-04 Thread SourceForge.net
Bugs item #1424148, was opened at 2006-02-04 18:35
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=1424148&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: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl)


... has to become ...


def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

--

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



[ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal looses data on POST!

2006-02-04 Thread SourceForge.net
Bugs item #1424148, was opened at 2006-02-04 18:35
Message generated for change (Settings changed) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424148&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: 6
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl)


... has to become ...


def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

--

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



[ python-Bugs-1424152 ] urllib: HTTPS over (Squid) Proxy fails

2006-02-04 Thread SourceForge.net
Bugs item #1424152, was opened at 2006-02-04 18:50
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=1424152&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: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib: HTTPS over (Squid) Proxy fails

Initial Comment:
py2.4.2/win32

The proxy mechanism of python fails on https and does
work completely wrong (not using the CONNECT scheme).

(after urlopen some minute(s) freeze then EOF error)

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import urllib
>>> urllib.getproxies()
{'ftp': 'ftp://vserver:3128', 'http':
'http://vserver:3128', 'gopher': 'gopher:/
/vserver:3128', 'https': 'https://vserver:3128'}
>>> urllib.urlopen('https://www.elster.de')
Traceback (most recent call last):
  File "", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 185, in open
return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 386, in open_https
h.endheaders()
  File "C:\Python24\lib\httplib.py", line 795, in
endheaders
self._send_output()
  File "C:\Python24\lib\httplib.py", line 676, in
_send_output
self.send(msg)
  File "C:\Python24\lib\httplib.py", line 643, in send
self.connect()
  File "C:\Python24\lib\httplib.py", line 1071, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (8, 'EOF occurred in
violation of protocol')
>>>



no CONNECT even appears in the squid proxy access log.

Robert
 

--

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



[ python-Bugs-1424171 ] patch for etree cdata and attr quoting

2006-02-04 Thread SourceForge.net
Bugs item #1424171, was opened at 2006-02-04 13:23
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=1424171&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example ""e;" with 
""e;" or "&" with "&", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

--

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



[ python-Bugs-1424171 ] patch for etree cdata and attr quoting

2006-02-04 Thread SourceForge.net
Bugs item #1424171, was opened at 2006-02-04 13:23
Message generated for change (Comment added) made by chrism
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424171&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example ""e;" with 
""e;" or "&" with "&", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

--

>Comment By: Chris McDonough (chrism)
Date: 2006-02-04 13:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

--

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



[ python-Bugs-1424171 ] patch for etree cdata and attr quoting

2006-02-04 Thread SourceForge.net
Bugs item #1424171, was opened at 2006-02-04 19:23
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424171&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
>Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example ""e;" with 
""e;" or "&" with "&", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 19:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

--

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 19:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

--

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



[ python-Bugs-1424148 ] urllib.FancyURLopener.redirect_internal looses data on POST!

2006-02-04 Thread SourceForge.net
Bugs item #1424148, was opened at 2006-02-04 18:35
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424148&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: 6
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.FancyURLopener.redirect_internal looses data on POST!

Initial Comment:
def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl)


... has to become ...


def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl,data)



... i guess?   (  ",data"  added )

Robert

--

>Comment By: Robert Kiendl (kxroberto)
Date: 2006-02-04 21:10

Message:
Logged In: YES 
user_id=972995

Found http://www.faqs.org/rfcs/rfc2616.html (below).
But the behaviour is still strange, and the bug even more
serious: a silent redirection of a POST as GET without data
is obscure for a Python language. Leads to unpredictable
results. The cut half execution is not stopable and all is
left to a good reaction of the server, and complex
reinterpreation of the client. Python urllibX should by
default yield the 30X code for a POST redirection and
provide the first HTML: usually a redirection HTML stub with
< a href=...
That would be consistent with the RFC: the User
(=Application! not Python!) can redirect under full control
without generating a wrong call! In my application, a bug
was long unseen because of this wrong behaviour. with
30X-stub it would have been easy to discover and understand ...

urllib2 has the same bug with POST redirection.

===
10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent
URI and any
   future references to this resource SHOULD use one of the
returned
   URIs.  Clients with link editing capabilities ought to
automatically
   re-link references to the Request-URI to one or more of
the new
   references returned by the server, where possible. This
response is
   cacheable unless indicated otherwise.

   The new permanent URI SHOULD be given by the Location
field in the
   response. Unless the request method was HEAD, the entity
of the
   response SHOULD contain a short hypertext note with a
hyperlink to
   the new URI(s).

   If the 301 status code is received in response to a
request other
   than GET or HEAD, the user agent MUST NOT automatically
redirect the
   request unless it can be confirmed by the user, since
this might
   change the conditions under which the request was issued.

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0
user agents
  will erroneously change it into a GET request.

--

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



[ python-Bugs-1424171 ] patch for etree cdata and attr quoting

2006-02-04 Thread SourceForge.net
Bugs item #1424171, was opened at 2006-02-04 13:23
Message generated for change (Comment added) made by chrism
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424171&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Fredrik Lundh (effbot)
Summary: patch for etree cdata and attr quoting

Initial Comment:
Attached is a patch for ElementTree (based on a checkout from the SVN 
trunk's xmlcore.etree) that seems to perform better escaping of cdata and 
attribute values.  Instead of replacing, for example ""e;" with 
""e;" or "&" with "&", it tries to avoid requoting 
ampersands in things that look like entities.

Sorry, I haven't tested this with anything except Python 2.4, I'm not quite 
sure what to do about _encode_entity, and I haven't patched any tests or 
written a new one for this change.  Consider this more of a RFC than a 
patch ready-for-submission as a result.

--

>Comment By: Chris McDonough (chrism)
Date: 2006-02-04 15:23

Message:
Logged In: YES 
user_id=32974

Egads, I did this time.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-04 13:29

Message:
Logged In: YES 
user_id=1188172

OP: You did check the box?

--

Comment By: Chris McDonough (chrism)
Date: 2006-02-04 13:26

Message:
Logged In: YES 
user_id=32974

Sorry, the tracker doesn't seem to want to allow me to upload the file.  See 
http://www.plope.com/static/misc/betterescape.patch for the patch.

--

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



[ python-Bugs-1415455 ] Typo in online documentation - 6.8.3.6 Replacing popen2.*

2006-02-04 Thread SourceForge.net
Bugs item #1415455, was opened at 2006-01-26 06:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1415455&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: Accepted
Priority: 5
Submitted By: Phil Wright (phlipped)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Typo in online documentation - 6.8.3.6 Replacing popen2.*

Initial Comment:
I think a module name is misspelled on the following
page of the Python Library Reference ...

Document:  Python Library Reference
Page Title:6.8.3.6 Replacing popen2.*
Page Address:  http://docs.python.org/lib/node246.html

The page contains the following text ...
"The popen2.Popen3 and popen3.Popen4 basically works as
subprocess.Popen, except that:"

The reference to the class "popen3.Popen4" should be
"popen2.Popen4" (There is no module "popen3")

The correct text would be ...
"The popen2.Popen3 and popen2.Popen4 basically works as
subprocess.Popen, except that:"


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:01

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


--

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



[ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with exceptions

2006-02-04 Thread SourceForge.net
Bugs item #1117670, was opened at 2005-02-07 05:50
Message generated for change (Comment added) made by adsr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&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: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiler: Bad return and Bad call errors with exceptions

Initial Comment:
I ran into a weird error when trying to profile a test
script of mine:
AssertionError: ('Bad call', ('', 0, 'encode'))

I managed to whittle it down to some minimal test
cases, which are attached (although the errors they
generate are slightly different.)  

$ python-cvs -m profile profile_badcall.py
Traceback (most recent call last):
[snipped ...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
  File "", line 1, in ?
  File "profile_badcall.py", line 10, in ?
os.path.join("C",'b')
  File
"/home/donut/usr64/python/lib/python2.5/posixpath.py",
line 56, in join
def join(a, *p):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 285, in trace_dispatch_call
assert (self.cur is None or \
AssertionError: ('Bad call', ('profile_badcall.py', 2,
'trier'))

$ python-cvs -m profile profile_badreturn.py
Traceback (most recent call last):
[snipped...]
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
  File "", line 1, in ?
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
  File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 312, in trace_dispatch_return
assert frame is self.cur[-2].f_back, ("Bad return",
self.cur[-3])
AssertionError: ('Bad return', ('profile_badreturn.py',
1, 'trier'))


The errors occur in python CVS as of 20050206 and
python 2.4, but not in python 2.3.4.  
OS: debian sid (3.1)
Arch: amd64


--

Comment By: Artur de Sousa Rocha (adsr)
Date: 2006-02-05 00:47

Message:
Logged In: YES 
user_id=728207

I've run into this bug too and decided to check the test
cases. Here's what I found:

1) Both test cases fail as mentioned above under Cygwin.

2) Under native Windows Python, profile_badcall.py passes OK
and profile_badreturn.py gives the following traceback:

Traceback (most recent call last):
  File "c:\Python24\lib\profile.py", line 611, in ?
run('execfile(%r)' % (sys.argv[0],), options.outfile,
options.sort)
  File "c:\Python24\lib\profile.py", line 72, in run
prof = prof.run(statement)
  File "c:\Python24\lib\profile.py", line 448, in run
return self.runctx(cmd, dict, dict)
  File "c:\Python24\lib\profile.py", line 454, in runctx
exec cmd in globals, locals
  File "", line 1, in ?
  File "profile_badreturn.py", line 9, in ?
sum(1,0)
TypeError: iteration over non-sequence

Python versions used:

Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32


--

Comment By: Andrew Bennetts (spiv)
Date: 2005-10-08 09:05

Message:
Logged In: YES 
user_id=50945

I still see this in current python 2.4, but not in current
python CVS.

Also, hotshot seems to work ok in 2.4 and CVS.

OS: ubuntu breezy (5.10)
Arch: i386


--

Comment By: Gary Oberbrunner (garyoberbrunner)
Date: 2005-03-09 04:35

Message:
Logged In: YES 
user_id=417980

Is there any news on this bug?  It is possibly preventing
scons (http://scons.org) from being profiled on python 2.4
-- we get the same errors as above.  Test case is too large
to include here, but please email me with any news if
possible!  Would be glad to test a fix.
-- Gary

--

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



[ python-Bugs-1423972 ] Email tests fail

2006-02-04 Thread SourceForge.net
Bugs item #1423972, was opened at 2006-02-04 05:23
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1423972&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Email tests fail

Initial Comment:
With the recent changes, the email tests now fail with

test test_email failed -- Traceback (most recent call
last):
  File
"/net/tb0/home/loewis/buildbot/trunk.1/build/Lib/email/test/test_email.py",
line 2110, in test_parsedate_acceptable_to_time_functions
eq(int(time.mktime(timetup)), 1044470846)
AssertionError: 109246 != 1044470846

See python.org/dev/buildbot/ for examples.

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-04 18:48

Message:
Logged In: YES 
user_id=12800

r42238 in trunk
r42239 in 2.4 branch
r42240 in 2.3 branch


--

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



[ python-Bugs-1415455 ] Typo in online documentation - 6.8.3.6 Replacing popen2.*

2006-02-04 Thread SourceForge.net
Bugs item #1415455, was opened at 2006-01-26 06:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1415455&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: Accepted
Priority: 5
Submitted By: Phil Wright (phlipped)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Typo in online documentation - 6.8.3.6 Replacing popen2.*

Initial Comment:
I think a module name is misspelled on the following
page of the Python Library Reference ...

Document:  Python Library Reference
Page Title:6.8.3.6 Replacing popen2.*
Page Address:  http://docs.python.org/lib/node246.html

The page contains the following text ...
"The popen2.Popen3 and popen3.Popen4 basically works as
subprocess.Popen, except that:"

The reference to the class "popen3.Popen4" should be
"popen2.Popen4" (There is no module "popen3")

The correct text would be ...
"The popen2.Popen3 and popen2.Popen4 basically works as
subprocess.Popen, except that:"


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:54

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 15:01

Message:
Logged In: YES 
user_id=33168

Thanks!

Committed revision 42236. (2.4)
Committed revision 42237.


--

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



[ python-Bugs-1423153 ] mmap module leaks file descriptors on UNIX

2006-02-04 Thread SourceForge.net
Bugs item #1423153, was opened at 2006-02-02 18:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1423153&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fazal Majid (majid)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: mmap module leaks file descriptors on UNIX

Initial Comment:
On UNIX, mmapmodule.c makes a call to dup(2) prior to
mapping the file descriptor into memory (oddly enough,
it doesn't map the new fd resulting from dup(), but the
old one).

The close method does not release this file descriptor,
however, leading to a leak. If mmap is used repeatedly,
the process will eventually run out of file
descriptors, as can easily be shown with this test case:

import sys, os, mmap

for i in xrange(2000):
  f = os.open('/dev/zero', os.O_RDWR)
  m = mmap.mmap(f, 1)
  os.close(f)
  a = m[0:100]
  m[100:200] = 'F' * 100
  m.close()


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 19:25

Message:
Logged In: YES 
user_id=33168

A similar fix was checked in to 41368 (2.4) and 41366 on 01
Nov 2005.  Thanks.  There shouldn't be a problem using 2.4
SVN HEAD or 2.5 HEAD.

--

Comment By: Fazal Majid (majid)
Date: 2006-02-03 09:43

Message:
Logged In: YES 
user_id=110477

>From my reading of the source, the fd is kept around just to
support the mmap.size() and mmap.resize() methods. I tend to
agree, tying down a fd is wasteful.

--

Comment By: Keith Dart (kdart)
Date: 2006-02-03 06:51

Message:
Logged In: YES 
user_id=16527

I would also like to add that the following no longer works
in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But the
fd is ignored in anonymous mmaps and does not need to be
dup-ed. This worked in older Python (2.3). Is the dup() call
really necessary?


--

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:44

Message:
Logged In: YES 
user_id=110477

The following patch closes the file descriptor when the mmap
object's close method is called, and seems to resolve this
problem.

--

Comment By: Fazal Majid (majid)
Date: 2006-02-02 18:27

Message:
Logged In: YES 
user_id=110477

SourceForge munged the formatting of the test case, so I am
attaching a copy as well.

--

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



[ python-Bugs-1424041 ] The mmap module does unnecessary dup()

2006-02-04 Thread SourceForge.net
Bugs item #1424041, was opened at 2006-02-04 05:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424041&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: Keith Dart (kdart)
Assigned to: Neal Norwitz (nnorwitz)
Summary: The mmap module does unnecessary dup()

Initial Comment:
The following no longer works in Python 2.4:

_buf = mmap.mmap(-1, 8192,
flags=mmap.MAP_PRIVATE|mmap.MAP_ANONYMOUS,
prot=mmap.PROT_READ|mmap.PROT_WRITE )

This is because the fd value of -1 raises an exception
because it is being dup-ed inside the mmap module. But
the fd is ignored in anonymous mmaps and does not need
to be dup-ed. This worked in older Python (2.3). Is the
dup() call really necessary? My current workaround is
to open /dev/null. But this causes "invisible"
consumption of file descriptors for the process.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:01

Message:
Logged In: YES 
user_id=33168

I think the dup() was added for resizing and some other
feature.  I'm not really sure about it, but it's safer to
leave in at this point.

There's no file attached.  This problem was fixed by patch
1407135.

Committed revision 42244.
Committed revision 42245. (2.4)


--

Comment By: Keith Dart (kdart)
Date: 2006-02-04 06:33

Message:
Logged In: YES 
user_id=16527

Here is a patch that fixes the problem for anonymous maps.
It simply makes the fd to be ignored if it is less than
zero. This works, but I still don't think having a duped fd
is needed. Whatever it accomplishes could be done in Python.
As a general rule, I prefer these kinds os system call
wrappers to do as little as possible (just wrap the call). 

--

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



[ python-Bugs-1089974 ] mmap missing offset parameter

2006-02-04 Thread SourceForge.net
Bugs item #1089974, was opened at 2004-12-22 11:22
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: A.M. Kuchling (akuchling)
Summary: mmap missing offset parameter

Initial Comment:
For some reason, the author of the MMap module didn't see fit to 
expose the "offset" parameter of the mmap syscall to python. It 
would be really nice if it had that. Currently, it's always set to 0.

m_obj->data = mmap(NULL, map_size,
   prot, flags,
   fd, 0);


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:05

Message:
Logged In: YES 
user_id=33168

The patch just needs some attention (testing and possible
fixes) on Windows.

--

Comment By: George Yoshida (quiver)
Date: 2004-12-28 21:54

Message:
Logged In: YES 
user_id=671362

There's already a patch for this request:

  http://www.python.org/sf/708374
  add offset to mmap

The rationale is same.
It's almost ready to be committed but has been left out for a 
year now. So give it a second chance.


--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-12-28 15:51

Message:
Logged In: YES 
user_id=341410

I would, but I don't know the slightest about the C-level
mmap internals on any platform, and spending the last hour
looking through Python's mmap.c hasn't made me any more
informed.

James (or anyone else who reads this), are you able?

--

Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 12:34

Message:
Logged In: YES 
user_id=11375

Would either of you care to provide a patch adding the
parameter?  I'll review it...


--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-12-23 08:57

Message:
Logged In: YES 
user_id=341410

I agree.  Having access to the offset parameter would be
quite convenient, at least to some who use mmap in a
nontrivial fashion.

--

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



[ python-Bugs-1424017 ] Assert failure in signal handling

2006-02-04 Thread SourceForge.net
Bugs item #1424017, was opened at 2006-02-04 04:50
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424017&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: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: doom (doomtr666)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assert failure in signal handling

Initial Comment:
With Visual Studio 2005 while compiling in debug mode.
Assert faillure occurs line 1657 in pythonrun.c.

New 2005 debug runtime raise an assert while using 
unsupported signals.

Proposed patch :

#else
PyOS_sighandler_t handler;

//  handler = signal(sig, SIG_IGN);
handler = SIG_ERR;

if (handler != SIG_ERR)
signal(sig, handler);
return handler;
#endif

if under visual studio 2005 debug runtime




--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-04 22:31

Message:
Logged In: YES 
user_id=33168

Python 2.5 fixes this problem, however, the fix was not
backported to 2.4.

See patch 1350409 also #1167262 and #1311784.

--

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