[ python-Bugs-835300 ] socket object method quot; makefilequot; has wrong doc
Bugs item #835300, was opened at 2003-11-03 22:23 Message generated for change (Comment added) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method quot;makefilequot; has wrong doc Initial Comment: The documentation of the method quot;makefilequot; for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux -- Comment By: Max Neunhöffer (neunhoef) Date: 2004-12-20 11:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! -- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 20:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman'
Feature Requests item #843590, was opened at 2003-11-17 10:29
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=843590group_id=5470
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'macintosh' encoding alias for 'mac_roman'
Initial Comment:
OS X's Mail.app can generate Subject lines like:
Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?=
(Which decodes to
'\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb
c')
This appears to be what Python calls the mac_roman
encoding. I suggest adding 'macintosh' as an alias to
'mac_roman' to encodings/aliases.py to allow the email
package to decode these headers.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-20 11:38
Message:
Logged In: YES
user_id=38388
Thanks for the research. Since the macintosh character set
is defined in the RFC 1345 and the mac_roman encoding in
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT
could you compare the two and check whether they are in fact
the same mapping ?
Note: Aliases for mappings are often implemented in a rather
careless way - we want to make sure that things we alias are
indeed correct aliases. Otherwise it's would be better to
add a new codec for 'macintosh'.
Thanks.
--
Comment By: Jens Klein (yenzenz)
Date: 2004-12-19 21:09
Message:
Logged In: YES
user_id=474612
seems its a bit more difficult:
encoding 'macintosh is registered by iana[1] (nice formatted in [2]) and is
covered by RFC1345[3].
Name: macintosh [RFC1345,KXS2]
MIBenum: 2027
Source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991
Alias: mac
Alias: csMacintosh
[1]http://www.iana.org/assignments/character-sets
[2]http://www.cs.tut.fi/~jkorpela/chars/sorted.html
[3]http://www.faqs.org/rfcs/rfc1345.html
so far the hard facts from specification view. in all these specs are
mac_roman etc. not mentioned. So what?
I found at [4] with the popular program 'recode' a hint of the alias. the
aothor
there uses the iana registered macintosh as an alias for mac_roman:
DEFENCODING(( MacRoman, /* JDK 1.1 */
/* This is the best table for MACINTOSH. The ones */
/* in glibc and FreeBSD-iconv are bad quality. */
MACINTOSH, /* IANA */
MAC,/* IANA */
csMacintosh,/* IANA */
),
mac_roman,
{ mac_roman_mbtowc }, { mac_roman_wctomb, NULL })
[4]http://recode.progiciels-bpi.ca/showfile.html?name=fusion/recode-3.6/
libiconv/encodings.def
Because of that (I trust recode somehow) i would propose to add macintosh
as an alias for mac_roman.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-19 00:01
Message:
Logged In: YES
user_id=38388
I have no problem adding aliases to the encodings package,
but please provide some reference that this actually is a
valid alias for the mac_roman encoding. There are quite a
few other mac_* encodings to choose from as well, so the
coice is not obvious to me.
--
Comment By: Jens Klein (yenzenz)
Date: 2004-12-18 23:49
Message:
Logged In: YES
user_id=474612
+1 from me
Archetypes (a Zope framework) runs also in a problem because of the
missing alias.
more infos:
https://sourceforge.net/tracker/index.php?
func=detailaid=1068001group_id=75272atid=543430
--
Comment By: Stuart Bishop (zenzen)
Date: 2003-11-17 11:47
Message:
Logged In: YES
user_id=46639
The test was just a sequence of random high-bit characters:
ºªªº¡£¢?§¶ªº
(lets see if the web interface lets that through).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-11-17 11:12
Message:
Logged In: YES
user_id=38388
Are you sure ? The decoded string you give does not look
like anything readable...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=843590group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086603 ] segfault in readline
Bugs item #1086603, was opened at 2004-12-17 03:02
Message generated for change (Comment added) made by quiver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in readline
Initial Comment:
It's possible to produce segfaults using two functions
from the
readline module by giving them negative values (GNU
readline 4.3-10),
at least in some circumstances.
Python 2.5a0 (#10, Dec 15 2004, 19:53:33)
[GCC 3.3.3 (Debian 20040401)] on linux2
Type help, copyright, credits or license for
more information.
import readline
[25290 refs]
readline.remove_history_item(-1)
Segmentation fault
readline.replace_history_item(-1,'abc')
Segmentation fault
gdb reveals it happens because the (external)
remove_history and replace_history_entry don't return
NULL in these cases. I'm not sure whether we're
responsible for checking the sanity of inputs or the
GNU code should be returning NULL and isn't, but at
least sometimes it doesn't.
--
Comment By: George Yoshida (quiver)
Date: 2004-12-20 19:57
Message:
Logged In: YES
user_id=671362
I'm +1 for sanity checking rather than waiting for the GNU
readline to return NULL in these functions.
It's just adding a few lines of code right after
PyArg_ParseTuple :
if (entry_number 0) {
PyErr_SetString(PyExc_ValueError,
index cannot be a negative value);
return NULL;
}
Then you can work around the problem without worrying
about the return value of remove_history nor
replace_history_entry.
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-20 01:41
Message:
Logged In: YES
user_id=6656
Do you want to fix it then? :) I can't imagine it's that hard, but it would
be easier for someone who can test that their fix helps...
--
Comment By: George Yoshida (quiver)
Date: 2004-12-18 19:45
Message:
Logged In: YES
user_id=671362
FYI, I can reproduce this with :
- Python 2.4 readline 4.3 under SuSE 9.1
- Python 2.5(snapshot as of 2004-12-17) readline 4.3 under
SuSE 9.1
- Python 2.4 readline 4.3.5(?) under Cygwin
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-17 23:18
Message:
Logged In: YES
user_id=6656
Hmm. I can't reproduce this (also with readline 4.3). Odd.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076819 ] test_shelve failures
Bugs item #1076819, was opened at 2004-12-01 16:22 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1076819group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Michal #268;iha#345; (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: == FAIL: test_read (__main__.TestAsciiFileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError == FAIL: test_read (__main__.TestBinaryFileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError == FAIL: test_read (__main__.TestProto2FileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError -- Comment By: Michal #268;iha#345; (nijel) Date: 2004-12-20 13:49 Message: Logged In: YES user_id=192186 It was probably problem somewhere else in the system, I can not reproduce it right now, so some upgrade has probably fixed this issue. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:38 Message: Logged In: YES user_id=80475 Works for me on WinME and WinXP. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 09:53 Message: Logged In: YES user_id=250749 Test works for me on FreeBSD 4.8. Make sure that you can use anydbm - more details on what db module is actually invoked by anydbm might help shed some more light on the matter (use the file utility on a database created with anydbm.open()). -- Comment By: Michal #268;iha#345; (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1076819group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off
Bugs item #1074333, was opened at 2004-11-27 22:37 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 13:59 Message: Logged In: YES user_id=469548 OP = opening poster. So yes, the ball is in your court. :) -- Comment By: Rick Graves (netvigator) Date: 2004-12-20 07:14 Message: Logged In: YES user_id=1167414 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-20 00:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. -- Comment By: Rick Graves (netvigator) Date: 2004-11-27 22:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1087551 ] inspect.py module
Bugs item #1087551, was opened at 2004-12-18 16:33 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087551group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: sprasanna199 (sprasanna199) Assigned to: Samuele Pedroni (pedronis) Summary: inspect.py module Initial Comment: I tried to compile python 2.4 inspect.py module in Jython but it throwed an exception. The line 749 in the inspect.py module caused the exception which is start = lineno - 1 - context//2 The code corresponding to it was also shown. But when I modified that line to start = lineno - 1 - context/2 it worked. Regards, S.Prasanna Code: if context 0: start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: start = max(start, 1) start = min(start, len(lines) - context) lines = lines[start:start+context] index = lineno - 1 - start else: lines = index = None -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 14:07 Message: Logged In: YES user_id=469548 This is not a bug in Python. The '//' operator was introduced in Python 2.2, while Jython is still tracking Python 2.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087551group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-835300 ] socket object method quot; makefilequot; has wrong doc
Bugs item #835300, was opened at 2003-11-03 16:23 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 1 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method quot;makefilequot; has wrong doc Initial Comment: The documentation of the method quot;makefilequot; for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux -- Comment By: Max Neunhöffer (neunhoef) Date: 2004-12-20 05:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! -- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 14:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-835300 ] socket object method quot; makefilequot; has wrong doc
Bugs item #835300, was opened at 2003-11-03 15:23 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 1 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method quot;makefilequot; has wrong doc Initial Comment: The documentation of the method quot;makefilequot; for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux -- Comment By: Skip Montanaro (montanaro) Date: 2004-12-20 09:04 Message: Logged In: YES user_id=44345 I'm pretty sure I know why you filed this item. socket.py contains code to work around shortcomings on Windows and BeOS (neither were able to dup() sockets). At some point we incorporated that same code for other platforms for consistency reasons, thus underlying sockets are not really dup'd: import socket s = socket.socket() s socket._socketobject object at 0x81d9dec t = s.dup() t socket._socketobject object at 0x81df02c t._sock socket object, fd=3, family=2, type=2, protocol=0 s._sock socket object, fd=3, family=2, type=2, protocol=0 id(s._sock) 136563280 id(t._sock) 136563280 Most of the time this doesn't affect anything, but I believe it does in certain cases. -- Comment By: Max Neunhöffer (neunhoef) Date: 2004-12-20 04:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! -- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 13:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=835300group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088563 ] calculation wrong rounding
Bugs item #1088563, was opened at 2004-12-20 19:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088563group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Rockel (buzz42) Assigned to: Jack Jansen (jackjansen) Summary: calculation wrong rounding Initial Comment: I am using python 2.4 on MAC OS 10.3.7 with gcc V3.3 20030304 (Apple Computer, Inc. build 1666) It is a simple calculation. There seems to be a little rounding problem: 4053020.7+10*324241.6 7295436.72 It shoult be of course 7295436.7 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088563group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088563 ] calculation wrong rounding
Bugs item #1088563, was opened at 2004-12-20 13:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088563group_id=5470 Category: Macintosh Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Sebastian Rockel (buzz42) Assigned to: Jack Jansen (jackjansen) Summary: calculation wrong rounding Initial Comment: I am using python 2.4 on MAC OS 10.3.7 with gcc V3.3 20030304 (Apple Computer, Inc. build 1666) It is a simple calculation. There seems to be a little rounding problem: 4053020.7+10*324241.6 7295436.72 It shoult be of course 7295436.7 -- Comment By: Tim Peters (tim_one) Date: 2004-12-20 14:09 Message: Logged In: YES user_id=31435 Please read the Appendix about floating-point issues in the Python Tutorial -- what you're seeing is an unavoidable consquence of using binary floating-point hardware. If you require exact decimal representations, use the new ``decimal`` module intead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088563group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
