[ python-Feature Requests-1735509 ] Newer reply format for imap commands in imaplib.py
Feature Requests item #1735509, was opened at 2007-06-12 02:48
Message generated for change (Comment added) made by ntai
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1735509&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
Private: No
Submitted By: Naoyuki Tai (ntai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Newer reply format for imap commands in imaplib.py
Initial Comment:
If the fetch command does not contain literal, the result is
[ '1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)',
'2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)']
If the fetch command contains literal, the result is
[ ('1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'),
')',
('2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'),
')']
First off, the number of elements in the reply becomes twice of non-literal
fetch command.
Secondly, to parse the attribute string like "(FLAGS (\\Seen) UID 1 RFC822.SIZE
26435)" , one must check the first and last character to be '(' and ')' for the
correctness of reply.
With the second type of reply / the reply with literal, the reply string needs
to be reconstructed out of the first element of tuple in an element, the
subsequent element by appending them.
If the number of elements in the reply matches with the number of mails
fetched, I can deal with the reply a lot easier.
As the shape of fetch command output is very different depending on literal,
the use of fetch() is too hard for its good.
Therefore, I propose the new response format.
fetch_status, [ entry1, entry2, entry3, ... ]
And each entry is
[entry-reply]
or
[entry-reply, [literals]]
This allows that you can get to the entry reply uniformly regardless of whether
or not the query of fetch with or without literal response.
Since the proposed response format is not compatible with existing format,
additional proposal is to let the user of imaplib.py to designate the response
format, as existing format as 1, and the new format as 2.
I have attached a patch for the proposed change.
--
>Comment By: Naoyuki Tai (ntai)
Date: 2007-06-12 03:06
Message:
Logged In: YES
user_id=1577886
Originator: YES
I overlooked that IMAP4_SSL needs the same enhancement. IMAP4_SSL's
constructor should look like as follows.
def __init__(self, host = '', port = IMAP4_SSL_PORT, keyfile = None,
certfile = None, response_format = 1):
self.keyfile = keyfile
self.certfile = certfile
IMAP4.__init__(self, host, port, response_format)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1735509&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 12:52
Message generated for change (Comment added) made by lemburg
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: 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-1735632 ] Add O_NOATIME to os module
Bugs item #1735632, was opened at 2007-06-12 10:20 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=1735632&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 Private: No Submitted By: sam morris (cortana) Assigned to: Nobody/Anonymous (nobody) Summary: Add O_NOATIME to os module Initial Comment: Please add a constant for O_NOATIME to the os module. -- Macro: int O_NOATIME If this bit is set, `read' will not update the access time of the file. *Note File Times::. This is used by programs that do backups, so that backing a file up does not count as reading it. Only the owner of the file or the superuser may use this bit. and possibly even a new character to the 'mode' paramter of the builtin 'open' function to do the same thing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735632&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-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-1735418 ] file.read() truncating strings under Windows
Bugs item #1735418, was opened at 2007-06-11 20:19 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&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 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. -- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:47 Message: Logged In: YES user_id=281701 Originator: NO This is your coding bug. (a) I would not trust tell(). Calculate the absolute position and use seek(). (b) Just from the documentation to Python's file-like objects I can assume that read() and tell() belong to different levels of API. The read() function has this in its documentation: "Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible". http://docs.python.org/lib/bltin-file-objects.html The tell() function's documentation refers to stdio's ftell(). This hints that tell() will return the position of the fread() buffer's end, not the read()'s end. (c) It also appears that by adding 1 to the "current position - unget size" you are skipping the space character itself. (d) The rfind() might return -1 if the search fails. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1735418 ] file.read() truncating strings under Windows
Bugs item #1735418, was opened at 2007-06-11 20:19 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&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 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. -- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:51 Message: Logged In: YES user_id=281701 Originator: NO (e) To have tell() on the same level with read(), try the unbuffered mode by specifying bufsize=0 in open(), http://docs.python.org/lib/built-in-funcs.html -- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:47 Message: Logged In: YES user_id=281701 Originator: NO This is your coding bug. (a) I would not trust tell(). Calculate the absolute position and use seek(). (b) Just from the documentation to Python's file-like objects I can assume that read() and tell() belong to different levels of API. The read() function has this in its documentation: "Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible". http://docs.python.org/lib/bltin-file-objects.html The tell() function's documentation refers to stdio's ftell(). This hints that tell() will return the position of the fread() buffer's end, not the read()'s end. (c) It also appears that by adding 1 to the "current position - unget size" you are skipping the space character itself. (d) The rfind() might return -1 if the search fails. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1736103 ] Mac build fails if not building universal due to libtool
Bugs item #1736103, was opened at 2007-06-12 23:12 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=1736103&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: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac build fails if not building universal due to libtool Initial Comment: If you try to build the svn trunk without universalsdk the make will fail: the Makefile tries to use libtool to create the shared library, but on (unmodified) OSX it should use glibtool. I have no idea who to assign this to, I hope you have a bettter idea. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&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 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-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-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP
Bugs item #1704793, was opened at 2007-04-21 10:52
Message generated for change (Comment added) made by gbrandl
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: Georg Brandl (gbrandl)
Date: 2007-06-13 06: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 04: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 11: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 09: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 20: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
