[issue3323] Clarify __slots__ behaviour when inheriting
New submission from Andy [EMAIL PROTECTED]: Suggest clarification on behaviour of the __slots__ attribute when inheriting from classes that don't have __slots__ defined. Obviously the superclass automatically creates __dict__, and it seems the subclass inherits this. I presume this is expected behaviour, but I think it would be worth clarifying in the 'Notes on using __slots__' section - perhaps add something like: If you define __slots__ on a subclass when its superclass doesn't have __slots__ defined, the superclass will automatically create a __dict__ instance which will be inherited by the subclass (as will other instance attributes). Defining __slots__ on the subclass doesn't block this inheritance. -- assignee: georg.brandl components: Documentation messages: 69460 nosy: georg.brandl, strangefeatures severity: normal status: open title: Clarify __slots__ behaviour when inheriting type: feature request versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3238] backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
kai zhu [EMAIL PROTECTED] added the comment: update: these 3k language features have been tested to work in python 2.5.2 w/ the backported opcodes pep3104 Access to Names in Outer Scopes pep3105 Make print a function pep3111 Simple input built-in in Python 3000 pep3113 Removal of Tuple Parameter Unpacking pep3114 Renaming iterator.next() to .__next__() pep3115 Metaclasses in Python 3000 pep3127 Integer Literal Support and Syntax pep3129 Class Decorators pep3132 Extended Iterable Unpacking had to backport __build_class__ in bltinmodule.c to get metaclasses working. u can go to http://www-rcf.usc.edu/~kaizhu/work/py3to2/ for more info install/usage summary: 1. build python 2.5.2 w/ patched ceval.c bltinmodule.c 2. download scripts: py3to2.py _py3to2.py 3. ln -s python3.0 python3k 4. run python2.5 type 'import py3to2' # it will automatically run the pep tests the script provides 3 functions similar to those in __builtin__: compile_py3k, exec_py3k, eval_py3k right now, working on backporting pep 3102 3107 - annotations keyword-only arguments. apparently appending the co_kwonlyargcount attr to codeobject in 2.5.2 doesn't seem to affect the build ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3324] Broken link in online doc
New submission from ThomasH [EMAIL PROTECTED]: The page http://docs.python.org/inst/search-path.html contains a broken link to site module documentation. Is: http://www.python.org/doc/devel/lib/module-site.html Should be: http://docs.python.org/lib/module-site.html -- assignee: georg.brandl components: Documentation messages: 69462 nosy: ThomasH, georg.brandl severity: normal status: open title: Broken link in online doc type: behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3325] use of cPickle in multiprocessing
New submission from Andrii V. Mishkovskyi [EMAIL PROTECTED]: There are two places in multiprocessing where cPickle (gone from py3k already) is used. Both of them are in try .. except, so they don't break code. Here is a patch that removes these uses. -- components: Library (Lib) messages: 69463 nosy: jnoller, mishok13, roudkerk severity: normal status: open title: use of cPickle in multiprocessing versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3325] use of cPickle in multiprocessing
Andrii V. Mishkovskyi [EMAIL PROTECTED] added the comment: And here is the patch. -- keywords: +patch Added file: http://bugs.python.org/file10867/issue3325.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3326] py3k shouldn't use -fno-strict-aliasing anymore
New submission from Ismail Donmez [EMAIL PROTECTED]: py3k branch is still using -fno-strict-aliasing but I tested with gcc 4.3.1 and there are no strict aliasing warnings when this flag is removed. Attached patch for py3k branch removes this flag. After applying the patch configure should be regenerated with autoconf. -- components: Interpreter Core files: strict-aliasing.patch keywords: patch messages: 69465 nosy: cartman severity: normal status: open title: py3k shouldn't use -fno-strict-aliasing anymore type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10868/strict-aliasing.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Jesse Noller [EMAIL PROTECTED] added the comment: Amaury - your latest patch doesn't seem to apply cleanly to trunk, it's choking on the Python/ceval.c changes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Here is a third patch with latest trunk. Did you apply it to a clean checkout? Added file: http://bugs.python.org/file10869/fork-and-thread3.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Jesse Noller [EMAIL PROTECTED] added the comment: I had to flip on ignore whitespace to patch: patch -p0 -l ~/Desktop/fork-and-thread3.patch Worked. Unfortunately, test_threading is locking up during a make test. Here's the verbose regrtest.py output: woot:python-trunk jesse$ ./python.exe Lib/test/regrtest.py -v test_threading ...snip thread 9 done thread 9 is finished. 0 tasks are running all tasks done ok test_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... At this point it hangs (OS/X 10.5 latest) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3327] NULL member in modules_by_index
New submission from Kristján Valur Jónsson [EMAIL PROTECTED]: In _PyState_AddModule(), a list of (initially) 20 elements is created, but there is no guarantee that all elements are initialized. In particular, it appears that element 0 is always NULL. This is bad since this list is accessible through introspection, e.g. by gc.get_objects() -- components: Interpreter Core messages: 69469 nosy: krisvale severity: normal status: open title: NULL member in modules_by_index type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3327 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Jesse Noller [EMAIL PROTECTED] added the comment: Amaury, it looks like it's hanging in subprocess: /Users/jesse/open_source/subversion/python- trunk/Lib/test/test_threading.py(338)_run_and_join() - p = subprocess.Popen([sys.executable, -c, script], stdout=subprocess.PIPE) (Pdb) step ...snip... (Pdb) step --Call-- /Users/jesse/open_source/subversion/python- trunk/Lib/threading.py(788)current_thread() - def current_thread(): (Pdb) step /Users/jesse/open_source/subversion/python- trunk/Lib/threading.py(789)current_thread() - try: (Pdb) step /Users/jesse/open_source/subversion/python- trunk/Lib/threading.py(790)current_thread() - return _active[_get_ident()] (Pdb) step /Users/jesse/open_source/subversion/python- trunk/Lib/subprocess.py(1097)_execute_child() - data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB (Pdb) step ... lockup ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: OK, I think I found my problem. I was using the main interpreter state (the one created by Py_Initialize) to create new thread states with. It seems that this interpreter state is reserved for GIL functions so one will need to create a new interpreter state with PyInterpeterState_New and use that interpreter state when creating the cooperating threads. So now this check makes sense. If one is swapping in a ts belonging to the main interpreter state, it best be the GIL thread state. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1758146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Tom Pinckney [EMAIL PROTECTED] added the comment: I mentioned this is in a brief python-dev discussion earlier this spring, but many popular websites such as Wikipedia and Facebook do use UTF-8 as their character encoding scheme for the path and argument portion of URLs. I know there's no RFC that says this is what should be done, but in order to make urllib work out-of-the-box on as many common websites as possible, I think defaulting to UTF-8 decoding makes a lot of sense. Possibly allow an option charset argument to be passed into quote and unquote, but default to UTF-8 in the absence of an explicit character set being passed in? -- nosy: +thomaspinckney3 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: OK I've gone back over the patch and decided to add the encoding and errors arguments from the str.encode/decode methods as optional arguments to quote and unquote. This is a much bigger change than I originally intended, but I think it makes things much better because we'll get UTF-8 by default (which as far as I can tell is by far the most common encoding). (Tom Pinckney just made the same suggestion right as I'm typing this up!) So my new patch is a bit more extensive, and changes the interface (in a backwards-compatible way). Both quote and unquote now support encoding and errors arguments, defaulting to utf-8 and replace, respectively. Implementation detail: This changes the Quoter class a lot; it now hashes four fields to ensure it doesn't use the wrong cache. Also fixed an issue with the previous patch where non-ASCII-compatible encodings broke for code points 128. I then ran the full test suite and discovered two other modules test cases broke. I've fixed them so the full suite passes, but I'm suspicious there may be more issues (see below). * Lib/test/test_http_cookiejar.py: A test case was written explicitly expecting Latin-1 encoding. I've changed this test case to expect UTF-8. * Lib/email/utils.py: I extensively analysed this code and discovered that it kind of cheats - it uses the Latin-1 encoding and treats it as octets, then applies its own encoding scheme. So to fix this, I changed the email module to call quote and unquote with encoding=latin-1. Hence it has the same behaviour as before. Some potential issues: * I have not updated the documentation yet. If this idea is to go ahead, the docs will need to show these new optional arguments. (I'll do that myself but haven't yet). * While the full test suite passes, I'm sure there will be many more issues since I've changed the interface. Therefore I don't recommend this patch is accepted just yet. I plan to do an investigation into all uses (within the standard lib) of quote and unquote to see if there are any other compatibility issues, particularly within urllib. Hence I'll respond to this again in a few days. * The new patch to safe argument of quote allows non-ASCII characters to be made safe. This correspondingly allows the construction of URIs with non-ASCII characters. Is it better to allow users to do this if they really want, or just mysteriously fail to let those characters through? I would also like to have a separate pair of functions, unquote_raw and quote_raw, which work on bytes objects instead of strings. (unquote_raw would take a str and produce a bytes, while quote_raw would take a bytes and produce a str). As URI encoding is fundamentally an octet encoding, not a character encoding, this is the only way to do URI encoding without choosing a Unicode character encoding. (I see some modules such as email treating the implicit Latin-1 encoding as byte encoding, which is a bit dodgy - they could benefit from raw functions). But as that requires further changes to the interface, I'll save it for another day. Patch (parse.py.patch2) is for branch /branches/py3k, revision 64820. Commit log: urllib.parse.unquote: Added encoding and errors optional arguments, allowing the caller to determine the decoding of percent-encoded octets (previously implicitly decoded as ISO-8859-1). As per RFC 3986, default is utf-8. urllib.parse.quote: Added encoding and errors optional arguments, allowing the caller to determine the encoding of non-ASCII characters before being percent-encoded (previously characters in range(128, 256) were encoded as ISO-8859-1, and characters above that as UTF-8). Also fixed characters greater than 256 not responding to safe, and also not being cached. Lib/test/test_urllib.py, Lib/test/test_http_cookiejar.py: Updated test cases which expected output in ISO-8859-1, now expects UTF-8. Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote with encoding=latin-1, to preserve existing behaviour (which the whole email module is dependent upon). Added file: http://bugs.python.org/file10870/parse.py.patch2 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3328] When PyObject_CallMethod fails, refcount is incorrect
New submission from Dominic Lavoie [EMAIL PROTECTED]:
This issue is similar to issue 1229429. In the called Python method, a
regular expression fails to compile PyEval_CallMethod() returns 0.
However, the reference count is incremented by 1 which prevents the
object from being destroyed.
Could the problem be in classobject.c, in instancemethod_call() ?
if (newarg == NULL)
return NULL;
Py_INCREF(self);
PyTuple_SET_ITEM(newarg, 0, self);
for (i = 0; i argcount; i++) {
PyObject *v = PyTuple_GET_ITEM(arg, i);
Py_XINCREF(v);
PyTuple_SET_ITEM(newarg, i+1, v);
}
arg = newarg;
}
result = PyObject_Call((PyObject *)func, arg, kw);
Py_DECREF(arg);
return result;
}
If result is null, should Py_DECREF(self) be called in the case where
self was non-null ?
--
components: Interpreter Core
messages: 69474
nosy: dominic.lavoie
severity: normal
status: open
title: When PyObject_CallMethod fails, refcount is incorrect
type: resource usage
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3328
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3328] When PyObject_CallMethod fails, refcount is incorrect
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: No, PyTuple_SET_ITEM() steals a reference to its argument, so that ownership is transferred to the tuple. The reference will be released when the tuple is disposed, with Py_DECREF(arg). What makes you think that there is a reference leak? Do you have a test case? -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Jesse Noller [EMAIL PROTECTED] added the comment: Here's the good news, with the patch applied to trunk, I'm not seeing hangs in the multiprocessing test suite. I'm running it on a tight loop excluding the threading tests to confirm. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Well I was a bit presumptuous that my thread+fork tests would pass on all platforms out of the box. We should disable the tests, or have someone with better Unix expertise examine and correct them. At least I feel that the actual correction in threading.py goes in the right direction. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Adam Olsen [EMAIL PROTECTED] added the comment: In general I suggest replacing the lock with a new lock, rather than trying to release the existing one. Releasing *might* work in this case, only because it's really a semaphore underneath, but it's still easier to think about by just replacing. I also suggest deleting _active and recreating it with only the current thread. I don't understand how test_join_on_shutdown could succeed. The main thread shouldn't be marked as done.. well, ever. The test should hang. I suspect test_join_in_forked_process should call os.waitpid(childpid) so it doesn't exit early, which would cause the original Popen.wait() call to exit before the output is produced. The same problem of test_join_on_shutdown also applies. Ditto for test_join_in_forked_from_thread. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Adam Olsen [EMAIL PROTECTED] added the comment: Looking over some of the other platforms for thread_*.h, I'm sure replacing the lock is the right thing. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3328] When PyObject_CallMethod fails, refcount is incorrect
Dominic Lavoie [EMAIL PROTECTED] added the comment: My application is fairly complex so I am currently trying to build a simple test case that reproduces the problem. Will let you know as soon as it is ready. Regards, Dominic ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3328] When PyObject_CallMethod fails, refcount is incorrect
Dominic Lavoie [EMAIL PROTECTED] added the comment: OK, I have been able to reproduce the problem with a simple test program. All you have to do is compile issue328.c and run it. issue328.py compiles an invalid regexp. You will see that the refcount goes from 1 to 2 if the regexp compilation fails but stays constant if the regexp compilation is successful. Added file: http://bugs.python.org/file10871/issue3328.zip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
New submission from Jukka Laurila [EMAIL PROTECTED]: Currently Python always uses the C library malloc/realloc/free as the underlying mechanism for requesting memory from the OS, but especially on memory-limited platforms it is often desirable to be able to override the allocator and to redirect all Python's allocations to use a special heap. This will make it possible to free memory back to the operating system without restarting the process, and to reduce fragmentation by separating Python's allocations from the rest of the program. The proposal is to make it possible to set the allocator used by the Python interpreter by calling the following function before Py_Initialize(): void Py_SetAllocator(void* (*alloc)(size_t), void* (*realloc)(void*, size_t), void (*free)(void*)) Direct function calls to malloc/realloc/free in obmalloc.c must be replaced with calls through the function pointers set through this function. By default these would of course point to the C stdlib malloc/realloc/free. -- components: Interpreter Core messages: 69482 nosy: jlaurila severity: normal status: open title: API for setting the memory allocator used by Python type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
Brett Cannon [EMAIL PROTECTED] added the comment: Is registering pointers to functions really necessary, or would defining macros work as well? From a performance perspective I would like to avoid having a pointer indirection step every time malloc/realloc/free is called. I guess my question becomes, Jukka, is this more for alternative implementations of Python where changes to source are already expected, or for apps that embed Python where a change of malloc/realloc/free varies from app to app that dynamically loads Python? -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
Adam Olsen [EMAIL PROTECTED] added the comment: How would this allow you to free all memory? The interpreter will still reference it, so you'd have to have called Py_Finalize already, and promise not to call Py_Initialize afterwords. This further supposes the process will live a long time after killing off the interpreter, but in that case I recommend putting python in a child process instead. -- nosy: +Rhamphoryncus ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- versions: +Python 3.1 -Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Martin v. Löwis [EMAIL PROTECTED] added the comment: Assuming the patch is acceptable in the first place (which I personally have not made my mind up), then it lacks documentation and test suite changes. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2542] PyErr_ExceptionMatches must not fail
Guido van Rossum [EMAIL PROTECTED] added the comment: FWIW some comments by Amaury are here: http://codereview.appspot.com/483 -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises
Guido van Rossum [EMAIL PROTECTED] added the comment: Does anyone care about this still? I added some comments on http://codereview.appspot.com/504 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2303 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3330] webbrowser module doesn't correctly handle '|' character.
New submission from Adrian Petrescu [EMAIL PROTECTED]: The webbrowser module seems to treat URLs containing the | character differently based on whether the browser is already running or not. For instance, consider the following python script: import webbrowser url = http://foo.com/bar.html?var=x|y|z webbrowser.open(url) If you run this script while the browser is already running (so that webbrowser.open creates a new tab) this behaves as you would expect, with the given URL as an address. However, if a browser is not already running, when webbrowser.open creates it, it seems to interpret the | as a seperator character, so that the browser will open with THREE tabs, one open to http://foo.com/bar.html?var=x;, one to http://y; and one to http://z;. This is clearly a bug, webbrowser module should be smart enough to escape the | character if the browser is interpreting that line differently. This happens in Linux with Python 2.5 and Firefox 3.0. Not sure if it happens with anything else. -- components: Library (Lib) messages: 69488 nosy: AdrianP severity: normal status: open title: webbrowser module doesn't correctly handle '|' character. type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3330] webbrowser module doesn't correctly handle '|' character.
Adrian Petrescu [EMAIL PROTECTED] added the comment: Just as an aside, the reason I consider this a fairly serious bug is that the Google Charts API urls make heavy use of the '|' character, which means if I want to have Python use it by opening the user's browser, it won't work if they don't already have a browser open. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3328] When PyObject_CallMethod fails, refcount is incorrect
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Thanks for the short case. It makes everything simpler.
First, note that you get the same behaviour with python-only code:
import re, sys
class Issue3328:
def f(self):
# unbalanced parenthesis
x = re.compile('(123')
o = Issue3328()
sys.getrefcount(o) # prints 2
o.f()
sys.getrefcount(o) # prints 3
And this is normal: the last exception contains the traceback (stored in
sys.last_traceback) which contains the live context frames which
reference the self variable which is the additional reference to our
object.
Try to provoke another error (any SyntaxError will do) and see the
refcount decrease.
Now, the three variables sys.last_traceback, sys.last_type and
sys.last_value contain the info about the last *uncaught* exception.
An exception is said to be *uncaught* when PyErr_Print() is called to
print it... That's what happens at the interactive prompt, of course,
and in your C code.
Looking at python source code, PyErr_Print() is actually a single call
to PyErr_PrintEx(1), the parameter (1) is named set_sys_last_vars
(aha!). You should try to call PyErr_PrintEx(0) instead, and see if this
improves something.
Then a documentation path will be very welcomed ;-)
--
resolution: - works for me
status: open - pending
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3328
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662581] the re module can perform poorly: O(2**n) versus O(n**2)
Yarko Tymciurak [EMAIL PROTECTED] added the comment: Not sure if this is a real-world case of this in particular, but possibly: http://groups.google.com/group/web2py/browse_thread/thread/59ff2e31698bced6/9bbae2d482d11b88 -- nosy: +yarkot ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1662581 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: A new patch: - I replaced _active_limbo_lock.release() by _active_limbo_lock=_allocate_lock() - I replaced the successive deletions in _active by a re-creation with only the current thread. There is no difference in the result, but I agree that the intent is more clear. - yes, the main thread is marked as done when the interpreter exits (hence the convoluted tests with subprocesses): in Modules/main.c, WaitForThreadShutdown() calls threading._shutdown(). Also, I hope the tests make more sense now. Added file: http://bugs.python.org/file10872/fork-and-thread4.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: OK well here are the necessary changes to the documentation (RST docs and docstrings in the code). As I said above, I plan to to extensive testing and add new cases, and I don't recommend this patch is accepted until that's done. Patch (parse.py.patch3) is for branch /branches/py3k, revision 64834. Commit log: urllib.parse.unquote: Added encoding and errors optional arguments, allowing the caller to determine the decoding of percent-encoded octets (previously implicitly decoded as ISO-8859-1). As per RFC 3986, default is utf-8. urllib.parse.quote: Added encoding and errors optional arguments, allowing the caller to determine the encoding of non-ASCII characters before being percent-encoded (previously characters in range(128, 256) were encoded as ISO-8859-1, and characters above that as UTF-8). Also fixed characters greater than 256 not responding to safe, and also not being cached. Doc/library/urllib.parse.rst: Updated docs on quote and unquote to reflect new interface. Lib/test/test_urllib.py, Lib/test/test_http_cookiejar.py: Updated test cases which expected output in ISO-8859-1, now expects UTF-8. Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote with encoding=latin-1, to preserve existing behaviour (which the whole email module is dependent upon). Added file: http://bugs.python.org/file10873/parse.py.patch3 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
