[ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often
Bugs item #1607951, was opened at 2006-12-03 12:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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 Private: No Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-14 14:09 Message: Logged In: YES user_id=11375 Originator: NO Stray thought: would it help if the patch stored the (mtime - 1sec) instead of the mtime? Successive calls in the same second would then always re-read the directories, but once the clock ticks to the next second, re-reads would only occur if the directories have actually changed. The check would be 'if new_mtime > self._new_mtime' instead of '=='. Is this sort of mtime-based checking reliable on remote filesystems such as NFS? -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-13 08:38 Message: Logged In: YES user_id=11375 Originator: NO By stat()'ing the directories, do you mean checking the mtime? I think this isn't safe because of the limited resolution of mtime on filesystems; ext3 seems to have a 1-second resolution for mtime, for example. This means that _refresh() might read a directory, and if some other process adds or deletes a message in the same second, _refresh() couldn't detect the change. Is there some other property of directories that could be used for a more reliable check? The attached patch implements checking of mtime, but I don't recommend applying it; it causes the test suite in test_mailbox.py to break all over the place, because the process modifies mailboxes so quickly that the mtime check doesn't notice the process's own changes. I'll wait a bit for any alternative suggestion, and then close this bug as "won't fix". File Added: mailbox-mtime.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1600152 ] mailbox: Maildir.get_folder does not inherit factory
Bugs item #1600152, was opened at 2006-11-20 22:33
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&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: Duplicate
Priority: 5
Private: No
Submitted By: Tetsuya Takatsuru (taka2ru)
Assigned to: A.M. Kuchling (akuchling)
Summary: mailbox: Maildir.get_folder does not inherit factory
Initial Comment:
mailbox.Maildir.get_folder does not inherit _factory.
>>> import mailbox
>>>
>>> mbox = mailbox.Maildir('/home/xxx/Maildir', mailbox.MaildirMessage)
>>>
>>> subfolder = mbox.get_folder(mbox.list_folders()[0])
>>>
>>> for key, mail in subfolder.iteritems():
>>> print mail.__class__
>>> break
from this example, i got the following output:
rfc822.Message
'mailbox.MaildirMessage' should be gotten instead.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-12-14 15:18
Message:
Logged In: YES
user_id=11375
Originator: NO
Thanks for your report. This bug has already been reported as #1569790,
and has been fixed in both the trunk and 25-maint branches. Please see
that bug for a patch that fixes the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1616109 ] IA64/AMD64/x64 confusion
Bugs item #1616109, was opened at 2006-12-14 21:51 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=1616109&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-05 00:46 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&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: IDLE Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Douglas W. Goodall (douglas_goodall) Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-15 00:15 Message: Logged In: YES user_id=149084 Originator: NO Rev 53042 Also, it appears that os.__all__ is fixed. Thanks for the analysis! -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 12:33 Message: Logged In: YES user_id=1330769 Originator: NO This cause for this bug is an endless loop in AutoCompleteWindow.py, line 121: 114 selstart = self.completions[cursel] [snip...] 121 while cursel > 0 and selstart[:i] <= self.completions[cursel-1]: 122 i += 1 123 newstart = selstart[:i] The case where this loop becomes endless only arises when the same completion item appears twice in the completions list, thus self.completions[cursel-1] and self.completions[cursel] are identical. This happens with the os module because spawnv and spawnve appear twice in os.__all__. Solution: 1) Fix the potentially endless loop (add a bound for i) 2) Remove identical completion items from the completions list (its a bug anyways) -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 13:47 Message: Logged In: YES user_id=580910 As an additional data point: this seems to work just fine on Mac OS X. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 23:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 12:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599931 ] Immediate Crash on Open
Bugs item #1599931, was opened at 2006-11-20 14:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&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: IDLE Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Farhymn (farhymn) >Assigned to: Kurt B. Kaiser (kbk) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-15 00:30 Message: Logged In: YES user_id=149084 Originator: NO I'm sorry, I can't understand your report. Please tell me exactly how you are starting IDLE (using the icon? using a command window?) What does OpenRPG+ have to do with it, are you calling it along with IDLE? If so, please give me the command line and a url for the program. What does your "edit" have to do with the problem? The second number is illegal, because although it's coded as an octal (starts with 0) it has characters greater than 7 in it. Fix either of those issues, and it's fine. -- Comment By: Farhymn (farhymn) Date: 2006-11-20 14:53 Message: Logged In: YES user_id=1650037 Originator: YES (edit) Forgot to mention that the problem is pythonw.exe specific as well. Python DOS runs fine, I can only get it to register a token error by typing in the following at the prompt: 1234816587613289741-0152872349817230987 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612262 ] Class Browser doesn't show internal classes
Bugs item #1612262, was opened at 2006-12-09 12:38 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612262&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: IDLE >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Class Browser doesn't show internal classes Initial Comment: If I define a class within a class, like this: class A: class B: pass def foo(self): pass The class browser shows that A contains foo, but it doesn't show B at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
