[ python-Feature Requests-1175686 ] add "reload" function
Feature Requests item #1175686, was opened at 2005-04-03 08:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add "reload" function Initial Comment: The file menu in Editor windows could benefit from a "reload" function that re-reads the file from disc and loads it into the editor, replacing what's currently in the editor. That's useful for those of us who like to edit with Emacs in another window while running the code under Idle. To get really fancy, it might be cool to optionally display a diff between the in-editor version and the on-disk version allowing merging changes, but that's maybe over the top. Other editors usually do have commands like this, e.g.M-x Revert-file in Emacs or ":e!" in vi. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174712 ] subclassing ModuleType and another built-in type
Bugs item #1174712, was opened at 2005-04-01 10:22
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type
Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault
This buggy subclassing goes through typeobject.c's checks because
PyModuleObject looks exactly like a user-defined subclass of 'object': it has a
PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.
A fix would be to forbid any subclassing to move the tp_dictoffset of a
non-heap type.
--
>Comment By: Michael Hudson (mwh)
Date: 2005-04-03 14:39
Message:
Logged In: YES
user_id=6656
> This might point to the need for cleaning up typeobject.c's
> darker corners...
No kidding. Maybe Samuele, you and I can gang up on Guido at
EuroPython (is he sprinting? Perhaps we should ask).
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-02 13:27
Message:
Logged In: YES
user_id=4771
The proposed fix is not good enough. If another built-in C type similar to
PyModuleObject is defined (say by a C extension module), then it would become
possible to subclass both this new type and ModuleType. This might lead to
unwanted behavior if e.g. one parent class allows rebinding __dict__ and the
other not (and crashes if __dict__ is rebound).
This might point to the need for cleaning up typeobject.c's darker corners...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175848 ] poorly named variable in urllib2.py
Bugs item #1175848, was opened at 2005-04-03 11:26 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=1175848&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: poorly named variable in urllib2.py Initial Comment: This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local variable "server_version" is poorly named. The name makes it sound like it's the version of the HTTP (or whatever) server we're talking to. How about client_version or library_version or module_version? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175202 ] python hangs if import statement launches threads
Bugs item #1175202, was opened at 2005-04-02 07:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175202&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jeff Stearns (jeffstearns) Assigned to: Nobody/Anonymous (nobody) Summary: python hangs if import statement launches threads Initial Comment: (This bug looks similar to bug 1175194, but reports a different problem.) I have a simple module which launches multiple HTTP client threads. The main thread creates 10 HTTP clients, each of which fetches documents from a web server. The main thread then simply goes to sleep while the client threads work. The threads are launched when the module is imported. If I launch the script via python bug1.py it launches and runs OK. But if I launch the script via python -c 'import bug1' it runs a bit, then hangs. Here's an example: [EMAIL PROTECTED]> ./python -c 'import bug1' Using 10 threads cc <- [program hangs here] Each thread prints a character every time that it does something interesting. The 'c' characters indicate that a connect syscall was made. These should be followed by 'C', indicating the the connect returned. That never happens. You might argue that it's inappropriate to launch threads from within import statement, but I can't find a specific prohibition against it. Here's a trace of the last few syscalls before it hangs (pids are actually thread ids): [pid 15481] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15481] futex(0x8148698, FUTEX_WAIT, 0, NULL [pid 15482] futex(0x81a9a80, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] write(2, "c", 1c)= 1 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x820cc48, FUTEX_WAKE, 1) = 0 [pid 15482] futex(0x8148698, FUTEX_WAIT, 0, NULL <- hangs here Please note that this bug is similar to bug 1175194, but reports a different problem. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-03 18:24 Message: Logged In: YES user_id=21627 This is not a bug. The import statement returns when the code of the module completes. In this example, the import statement returns when the call run(10) completes. As the run method has a very long sleep, the import won't return until that sleep is over. So the problem is not that 10 threads are started, but that the module then blocks in its module execution. Furthermore, Python serializes all import statements, with a single import lock. So while one thread performs an import, other threads block when trying to import. So if the threads just started try to import something, they wait until the "main" import completes. If the main imports wait for the threads to complete (i.e. the commented-out thread.join), you get a dead-lock. Closing as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175202&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1155485 ] file() on a file
Feature Requests item #1155485, was opened at 2005-03-03 00:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: file() on a file Initial Comment: it would be nice if file(f) worked when f is already a file, either by returning f or by constructing a new file that refers to the same thing. that would make it easy to write functions that can take either a file or a filename as an argument, like so: def p(f): print list(file(f)) which is kind of like using int() as a cast operation. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-04-03 18:28 Message: Logged In: YES user_id=21627 Since several people have commented that the change would not be desirable, I'm closing it as "Won't fix". If you still think that feature should be added, please write a PEP, and collect feedback from the community (altough a part of the community will likely react the same way to such a PEP). -- Comment By: Tim Peters (tim_one) Date: 2005-03-15 01:00 Message: Logged In: YES user_id=31435 I'm also -1 on this -- I have no idea what would make sense when applying file() to a file object, or to a file-like object. Therefore anything it did in response would be surprising to me, except for raising an exception. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-14 22:20 Message: Logged In: YES user_id=21627 The same argument can *not* be made for strings, since strings are immutable, so it does not matter whether you get the original thing or a copy. Also, str(x) invokes x's __str__ conversion. For lists, the argument is also different: list(x) requires an iterable object and creates a list out of it. The notion of an iterable object is well-defined, and if you pass something that is not iterable, you get a TypeError. For files, this is entirely different. file() does not take one argument, but three (and two of them are optional). The first (mandatory) argument is a "filename". It might be debatable what precisely a file name is, and indeed you can pass both byte strings and unicode strings. A file, most certainly, is *not* a filename, and there is no notion of "converting to a file" in Python (e.g. by means of __file__). This just isn't a useful generalization. -- Comment By: Felix Lee (felixlee) Date: 2005-03-14 21:47 Message: Logged In: YES user_id=77867 that argument also works against str() and list(). it's not obvious whether str(s) and list(v) should return itself, a proxy, or a copy, and they're all useful in different situations. I don't think anyone would argue that the ambiguity means those should be undefined. I think file(f) is similar. it has a few more issues because files are special, but I think picking a reasonable behavior for file(f) would simplify some programming. returning a dup is probably the least surprising in most situations, because of f.close(). -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-13 23:53 Message: Logged In: YES user_id=21627 It's not at all obvious what this should do. Three alternatives come to mind: 1. return f 2. return a wrapper object which delegates all calls 3. return a new file object, which is dup(2)'ed from the original one. Either of them might be meaningful in some context, and they are mutually incompatible. In the face of ambiguity, refuse the temptation to guess, so I'm -1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175967 ] StringIO and cStringIO don't provide 'name' attribute
Bugs item #1175967, was opened at 2005-04-03 15: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=1175967&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO and cStringIO don't provide 'name' attribute Initial Comment: Documentation explicitly states that file-like objects should return a repr-style psuedoname. Patch is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175967&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1176012 ] compiler module didn't get updated for "class foo():pass"
Bugs item #1176012, was opened at 2005-04-03 16:21 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=1176012&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module didn't get updated for "class foo():pass" Initial Comment: Patch with fix and testcase is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1176012 ] compiler module didn't get updated for "class foo():pass"
Bugs item #1176012, was opened at 2005-04-03 16:21 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module didn't get updated for "class foo():pass" Initial Comment: Patch with fix and testcase is attached. -- >Comment By: logistix (logistix) Date: 2005-04-03 17:01 Message: Logged In: YES user_id=699438 The parser module didn't get corrected either. Here is another patch with test case for that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
