[ python-Bugs-1760423 ] No docs for list comparison
Bugs item #1760423, was opened at 2007-07-25 15:39 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: No docs for list comparison Initial Comment: AFAICT there is no documentation for the behaviour of <, > or == for sequences. == is perhaps obvious but it would be worth noting that < and > for lists and strings does a lexicographical comparison on the list elements or string characters. -- >Comment By: Kent Johnson (kjohnson) Date: 2007-07-27 12:52 Message: Logged In: YES user_id=49695 Originator: YES Yes, that is what I was looking for. It seems a strange place for the information. Could this be cross-referenced from the Library Reference? I never even thought to look for it in the Language Ref. Other list operations are documented in http://docs.python.org/lib/typesseq.html and this page discusses comparison of library types in general: http://docs.python.org/lib/comparisons.html I think it would be worth either repeating or linking to the information from the language ref on either of these pages. Thanks, Kent -- Comment By: Carsten Haese (chaese) Date: 2007-07-27 12:29 Message: Logged In: YES user_id=99003 Originator: NO http://docs.python.org/ref/comparisons.html works for me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1760423 ] No docs for list comparison
Bugs item #1760423, was opened at 2007-07-25 11:39 Message generated for change (Comment added) made by chaese You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: No docs for list comparison Initial Comment: AFAICT there is no documentation for the behaviour of <, > or == for sequences. == is perhaps obvious but it would be worth noting that < and > for lists and strings does a lexicographical comparison on the list elements or string characters. -- Comment By: Carsten Haese (chaese) Date: 2007-07-27 08:29 Message: Logged In: YES user_id=99003 Originator: NO http://docs.python.org/ref/comparisons.html works for me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&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: 8
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Martin v. Löwis (loewis)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-27 20:28
Message:
Logged In: YES
user_id=21627
Originator: NO
This patch is now committed as r56588 for 2.6 only.
--
Comment By: Armin Rigo (arigo)
Date: 2007-03-23 21:37
Message:
Logged In: YES
user_id=4771
Originator: NO
The fakeclose.diff patch looks safe enough.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 14:35
Message:
Logged In: YES
user_id=21627
Originator: NO
Ok, I reverted this patch in r54543 and r54544.
arigo, what do you think about the alternative patch (fakeclose.diff),
which drops the ssl object in FakeSocket.close()? I don't think we can add
an explicit close operation for 2.5.x to SSL objects, so we have to
continue to rely on reference counting.
File Added: fakeclose.diff
--
Comment By: Armin Rigo (arigo)
Date: 2006-11-20 12:33
Message:
Logged In: YES
user_id=4771
Originator: NO
Martin, I think the rev 50844 is wrong. To start with,
it goes clearly against the documentation for makefile()
which states that both the socket and the pseudo-file
can be closed independently. What httplib.py was doing
was correct.
I could write a whole essay about the twisted history
of socket.py. It would boil down to: in r43746, Georg
removed a comment that was partially out-of-date,
but that was essential in explaining why there was no
self._sock.close() in _socketobject.close(): because
the original purpose of _socketobject was to implement
dup(), so that multiple _socketobjects could refer to
the same underlying _sock. The latter would close
automagically when its reference counter dropped to
zero. (This means that your check-in also made dup()
stop working on all platforms.)
The real OP's problem is that the _ssl object keeps
a reference to the underlying _sock as well, as
kxroberto pointed out. We need somewhere code that
closes the _ssl object...
For reference, PyPy - which doesn't have strong
refcounting guarantees - added the equivalent of an
explicit usage counter in
[ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP
Bugs item #1704793, was opened at 2007-04-21 12:52
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: vbr (vlbrom)
Assigned to: Martin v. Löwis (loewis)
Summary: incorrect return value of unicodedata.lookup() - beoynd BMP
Initial Comment:
There seem to be an incorrect handling of unicode characters beyond the BMP
(code point higher than 0x) in the unicodedata module - function lookup()
on narrow unicode python builds (python 2.5.1, Windows XPh)
>>> unicodedata.lookup("GOTHIC LETTER FAIHU")
u'\u0346'
(should be u'\U00010346' - the beginning of the literal is truncated - leading
to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING
BRIDGE ABOVE")
on the contrary, the unicode string literals \N{name} work well.
>>> u"\N{GOTHIC LETTER FAIHU}"
u'\U00010346'
Unfortunately, I haven't been able to find the problematic pieces of
sourcecode, so I'm not able to fix it.
It seems, that initially the correct information on the given codepoint is
used, but finally only the last four digits of the codepoint value are taken
into account using the "narrow" unicode literal \u instead of \U
, while the same task is handled correctly by the unicodeescape codec used for
unicode string literals.
vbr
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-27 20:33
Message:
Logged In: YES
user_id=21627
Originator: NO
I'm skeptical about applying this to 2.5.x: I think it could be surprising
if you suddenly get length-two results. How about raising a ValueError
instead if the resulting character is out of range?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-06-13 08:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Indeed, it is UCS-2, sorry.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-06-13 06:25
Message:
Logged In: YES
user_id=21627
Originator: NO
gbrandl: what precisely can you confirm? In any UCS-4 build, the lookup
should return the correct result, and it does so on my machine.
An alternative solution to the change proposed by perky would be to raise
a ValueError, similar to unichr().
--
Comment By: Hye-Shik Chang (perky)
Date: 2007-06-12 13:12
Message:
Logged In: YES
user_id=55188
Originator: NO
I attached a working fix for the problem. The patch encodes non-BMP
characters as a surrogate pair in the lookup function.
The surrogate pair encoding can be thought as something to be included in
the standard unicode API. How about to provide UTF-32 codecs in the Python
C-API to help this kind of use?
File Added: unicodedata-lookup-ucs2fix.diff
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-06-12 11:35
Message:
Logged In: YES
user_id=38388
Originator: NO
Martin, please have a look. Thanks.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-21 22:29
Message:
Logged In: YES
user_id=849994
Originator: NO
Confirmed with an linux-x86 UCS-4 build here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1759997 ] poll() on cygwin sometimes fails [PATCH]
Bugs item #1759997, was opened at 2007-07-24 17:58 Message generated for change (Comment added) made by warner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759997&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Warner (warner) Assigned to: Nobody/Anonymous (nobody) Summary: poll() on cygwin sometimes fails [PATCH] Initial Comment: While trying to track down a problem with our application (http://allmydata.org) running under cygwin, I discovered that the select.poll() object sometimes returns completely bogus data. poll() returns a list of tuples of (fd, revent), but fds are supposed to be small integers, and revents are a bitmask of POLLIN/POLLOUT flags. In my tests, I saw poll() return a list that started out looking normal, but the last half of the list contained fds and revents values like fd=0x7672a646, revent=0xd819. It turns out that under cygwin-1.5.24 (which I believe is a pretty recent version), the poll() call sometimes violates the POSIX specification, and provides a return value which is different than the number of pollfd structures that have non-zero .revents fields (generally larger). This causes the implementation of poll_poll() (in Modules/selectmodule.c) to read beyond the end of the pollfd array, copying random memory into the python list it is building, causing the bogus values I observed during my tests. These bogus values were mostly ignored, because the Twisted pollreactor that I was using noticed that the fd didn't correspond to any previously-registered file descriptor. It was only when the bogus fd happened to coincide with a real one (and when that indicated that a TCP listening socket became writable, which should never happen) that an exception was raised. The attached patch (against 2.5.1) works around the problem by manually counting the number of non-zero .revents, rather than relying upon the return value from poll(). This version passes test_poll on both linux and cygwin. cheers, -Brian Warner -- >Comment By: Brian Warner (warner) Date: 2007-07-27 16:25 Message: Logged In: YES user_id=24186 Originator: YES We've begun the process: zooko is working on a patch for cygwin and is working with them to figure out how to compile the thing. We've not yet explained the poll() bug to them in detail (wanting to have a patch in hand first). I'll report back once we get some word from them about how likely it is this problem will be fixed on the cygwin side. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-24 22:53 Message: Logged In: YES user_id=33168 Originator: NO Has this problem been reported to cygwin? Have they fixed the problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759997&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP
Bugs item #1704793, was opened at 2007-04-21 19:52
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: vbr (vlbrom)
Assigned to: Martin v. Löwis (loewis)
Summary: incorrect return value of unicodedata.lookup() - beoynd BMP
Initial Comment:
There seem to be an incorrect handling of unicode characters beyond the BMP
(code point higher than 0x) in the unicodedata module - function lookup()
on narrow unicode python builds (python 2.5.1, Windows XPh)
>>> unicodedata.lookup("GOTHIC LETTER FAIHU")
u'\u0346'
(should be u'\U00010346' - the beginning of the literal is truncated - leading
to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING
BRIDGE ABOVE")
on the contrary, the unicode string literals \N{name} work well.
>>> u"\N{GOTHIC LETTER FAIHU}"
u'\U00010346'
Unfortunately, I haven't been able to find the problematic pieces of
sourcecode, so I'm not able to fix it.
It seems, that initially the correct information on the given codepoint is
used, but finally only the last four digits of the codepoint value are taken
into account using the "narrow" unicode literal \u instead of \U
, while the same task is handled correctly by the unicodeescape codec used for
unicode string literals.
vbr
--
>Comment By: Hye-Shik Chang (perky)
Date: 2007-07-28 12:30
Message:
Logged In: YES
user_id=55188
Originator: NO
I'm agree about raising a ValueError for 2.5.x.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-07-28 03:33
Message:
Logged In: YES
user_id=21627
Originator: NO
I'm skeptical about applying this to 2.5.x: I think it could be surprising
if you suddenly get length-two results. How about raising a ValueError
instead if the resulting character is out of range?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-06-13 15:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Indeed, it is UCS-2, sorry.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-06-13 13:25
Message:
Logged In: YES
user_id=21627
Originator: NO
gbrandl: what precisely can you confirm? In any UCS-4 build, the lookup
should return the correct result, and it does so on my machine.
An alternative solution to the change proposed by perky would be to raise
a ValueError, similar to unichr().
--
Comment By: Hye-Shik Chang (perky)
Date: 2007-06-12 20:12
Message:
Logged In: YES
user_id=55188
Originator: NO
I attached a working fix for the problem. The patch encodes non-BMP
characters as a surrogate pair in the lookup function.
The surrogate pair encoding can be thought as something to be included in
the standard unicode API. How about to provide UTF-32 codecs in the Python
C-API to help this kind of use?
File Added: unicodedata-lookup-ucs2fix.diff
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-06-12 18:35
Message:
Logged In: YES
user_id=38388
Originator: NO
Martin, please have a look. Thanks.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-22 05:29
Message:
Logged In: YES
user_id=849994
Originator: NO
Confirmed with an linux-x86 UCS-4 build here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1760556 ] logging.FileHandler may throw exception in flush()
Bugs item #1760556, was opened at 2007-07-25 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: J Livingston (jlivingston) >Assigned to: Vinay Sajip (vsajip) Summary: logging.FileHandler may throw exception in flush() Initial Comment: Python 2.4.2 Windows XP SP2 logging.FileHandler may throw exception when calling flush(). This happens rarely and is due to the file handler already having been closed (probably by an external process). Simply checking within the close() method for an open file handler prior to calling flush() would fix this. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-27 20:35 Message: Logged In: YES user_id=33168 Originator: NO Vinay, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
