[issue3359] add 'rbU' mode to open()
anatoly techtonik [EMAIL PROTECTED] added the comment: If lineends are mixed I would like to leave them as is. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2378] UnboundLocalError when trying to raise exceptions inside execfile
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10953/localstofast.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2378] UnboundLocalError when trying to raise exceptions inside execfile
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10707/localstofast.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2378] UnboundLocalError when trying to raise exceptions inside execfile
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- assignee: - amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3415] Interpreter error when running a script under debugger control
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: This issue is a duplicate of issue2378; the patch attached there corrects this problem. I will commit it tonight. -- nosy: +amaury.forgeotdarc resolution: - duplicate status: open - closed superseder: - UnboundLocalError when trying to raise exceptions inside execfile ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon Martin v. Löwis [EMAIL PROTECTED]: Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't understand the second loop (where n is given). If n is given, there should be only a single read operation, using max(buffer_size, n-avail) I mimicked the original logic rather than rethink the algorithm. I'm not totally sure what motivates the original logic but the purpose seems to be that non-blocking streams can return at least a few bytes rather than an empty string when less than N bytes are ready at OS level. (i.e. the way it is in patch 2). In particular, if the stream is unbuffered, it shouldn't ever end up with buffered data. Hmm, what do you mean by if the stream is unbuffered? Unbuffered streams should use the raw unbuffered objects (e.g. FileIO) rather than wrap them with BufferedReader. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: IMO the struct tok_state should not be part of the API, it contains too many implementation details. Or maybe as an opaque structure. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Fredrik Lundh [EMAIL PROTECTED] added the comment: There are a few things in the struct that needs to be public, but that's nothing that cannot be handled by documentation. No need to complicate the API just in case. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: The patch looks good to me. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: PyCFunctionObject has indeed no way to store annotations. This could be useful for extension module writers. The PyMethodDef structure could grow a ml_annotations member. A patch is welcome! -- nosy: +amaury.forgeotdarc resolution: works for me - status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3387] undefined array passed to CryptGenRandomBytes
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- assignee: - amaury.forgeotdarc nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3396] rlcompleter can't autocomplete members of callable objects
Facundo Batista [EMAIL PROTECTED] added the comment: I don't understand. I tried the following: Python 2.6b2+ (trunk:65167M, Jul 21 2008, 09:51:48) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. import rlcompleter import readline readline.parse_and_bind(tab: complete) Then I wrote int. Then I pressed TAB. Nothing happened. I pressed TAB again, and the following appeared: int int( intern( To me this is the expected behaviour: if the system has two alternatives (in this case it does not if it should follow with ( or e), don't continue with the first tab, and then show all the options with the second tab (I'm used to this in bash). Is this wrong according to you? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3396 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3396] rlcompleter can't autocomplete members of callable objects
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon Facundo Batista [EMAIL PROTECTED]: Then I wrote int. Then I pressed TAB. Nothing happened. I pressed TAB again, and the following appeared: int int( intern( This is not the point. The problem is when you type int., then press TAB twice and it doesn't show the list of int members. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3396 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3366] Add gamma and error functions to math module
nirinA raseliarison [EMAIL PROTECTED] added the comment: and this is the header. it is stolen from glibc. Added file: http://bugs.python.org/file10955/math_private.h ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3373] sys recursion limit a lot shorter on trunk?
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3373 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton [EMAIL PROTECTED] added the comment: I know the discussions more or less says this, but I want to add some additional information. For the record, the reason that mod_python crashes with 'Invalid thread state for this thread' when Py_DEBUG is defined in part relates to: http://issues.apache.org/jira/browse/MODPYTHON-217 Also, that Py_DEBUG check effectively says that if you use simplified GIL API for a particular thread against the first interpreter, you are prohibited from creating additional thread states for that thread. I haven't checked the documentation lately, but I am not sure it is really clear on that specific point and so in some respects the documentation may be at fault here. Someone might like to point to exact part of documentation which states this requirement. The problem thus is that code which worked prior to Python 2.3 would still work with Python 2.3 and later, up to the point that some code decided to use the simplified GIL API. At that point Python would create its own internal thread state for that thread even if user code had already created one. Conversely, if the simplified GIL API was used against the thread first and then user code tried to create an additional thread state for that thread against first interpreter. With Py_DEBUG defined, this scenario causes the assertion failure and the above error. Without Py_DEBUG defined, the code can quite happily run fine, at least until the point where code which left Python using a user thread state object attempts to reenter Python by using simplified GIL API. At that point it would deadlock. Now, as I said, that one was effectively forced to use simplified GIL API for first interpreter with Python 2.3 probably wasn't at all clear and so mod_python was never updated to meet that requirement. As per the JIRA issue referenced above it is a known problem that code isn't meeting this requirement, but not much development has been done on mod_python for quite a while. I have though recently made changes to personal copy of mod_python code such that it uses simplified GIL API for all access against first interpreter and it no longer suffers that assertion failure when Py_DEBUG defined. The code also should work for any modules which use simplified GIL API, such as SWIG generated bindings for Xapian. You do have to force the application using such modules to run under first interpreter. The code for mod_wsgi uses simplified GIL API for first interpreter as well and works with SWIG generated bindings, but it is possible that it may still fail that assertion when Py_DEBUG is defined. This is because in order to allow mod_python and mod_wsgi to be used in Apache at the same time, mod_wsgi had to incorporate some hacks to workaround the fact that mod_python was not using simplified GIL API for first interpreter, but also because mod_python wasn't releasing the GIL for a critical section between when it was initialised and Apache child processes were created. It was in this section that mod_wsgi has to initialise itself and so it had to fiddle the thread states to be able to do its things. This workaround may have been enough to create additional thread state of a thread for first interpreter, thus later triggering the assertion. It would have been nice to have mod_wsgi do the correct thing from the start, but that would have barred it being used at same time as mod_python and so people may have baulked at trying mod_wsgi as a result. Now that mod_wsgi has got some traction, in mod_wsgi version 3.0 it will be changed to remove the mod_python fiddle. This will mean that mod_wsgi 3.0 will not be usable at same time as current mod_python versions and would only be usable with the mod_python version (maybe 3.4) which I have made modifications for to also use simplified GIL APIs properly. So that is the state of play as I see and understand it. As to Adam's comments about use cases for multiple interpreters, we have had that discussion before and despite that many people rely on that feature in both mod_python and mod_wsgi he still continues to dismiss it outright and instead calls for complete removal of the feature. Also Adam's comments that multiple interpreters were used in mod_wsgi only to support buggy third party software, that is untrue. Multiple interpreter support exists in mod_wsgi because mod_python provided a similar feature and mod_python existed before many of the Python web applications which are claimed to be the reason that sub interpreters are used in the first place. So, mod_python and use of sub interpreters came first, and not really the other way around. Where Python web applications do rely on os.environ it is historically because that is how things were done in CGI. Many such as Trac may still support that means of configuration as a fall back, but Trac now also supports other ways which are thread safe. All up, use of distinct sub
[issue3396] rlcompleter can't autocomplete members of callable objects
Facundo Batista [EMAIL PROTECTED] added the comment: Ah, sorry, missed that point. Ok, I included this change and now it works ok. Also worked a little that code (change the name of the variable object, used extend() for a list instead of adding to itself, and removed a comparison from a loop). Commited in r65168. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3396 ___ ___ 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: Also, that Py_DEBUG check effectively says that if you use simplified GIL API for a particular thread against the first interpreter, you are prohibited from creating additional thread states for that thread. I found that you cannot create additional thread states against the first interpreter and swap between them w/o this assertion occurring. I didn't use the GIL functions at all and had this issue in debug. PyInitialize initializes the GIL and hijacks the main interpreter. We always call PyInitialize so does that mean we can only use the GIL functions with the main interpreter and nothing else when locking/unlocking the global lock as you seem to infer? Does that mean there is a backward compatibility issue here with those who used the main interpreter only and created thread states from it to handle multi- threading, like I did (thru the use of PyEval_Acquire/Release PyThreadState_Swap)? ___ 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
[issue1758146] Crash in PyObject_Malloc
Franco DiRosa [EMAIL PROTECTED] added the comment: By the way. I switched to using the GIL functions on the main interpreter and everything works great now. It is a better solution to use the GIL functions because I also had my own code that prevented dead lock from occuring when a python script calls back into the extension module that ends up calling PyEval_Acquire again (deadlock) even though it is the same thread. Now with the GIL functions I don't need that code. It is a good feature but it broke my previous implementation and it is not obvious why. ___ 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
[issue3409] ElementPath.Path.findall problem with unicode input
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- assignee: - effbot nosy: +effbot ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3409 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1758146] Crash in PyObject_Malloc
Adam Olsen [EMAIL PROTECTED] added the comment: Graham, I appreciate the history of sub-interpreters and how entrenched they are. Changing those practises requires a significant investment. This is an important factor to consider. The other factor is the continuing maintenance and development cost. Subinterpreters add substantial complexity, which I can personally vouch for. This is exhibited in the GIL API not supporting them properly and in the various bugs that have been found over the years. Imagine, for a moment, that the situation were reversed; that everything were built on threading. Would you consider even for a moment adding sub-interpreters? How could you justify it? It's not a decision to be taken lightly, but my preference is clear: bite the bullet, make the change. It's easier in the long run. ___ 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
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick [EMAIL PROTECTED] added the comment: This bug should be re-opened. The patch to configure.in wasn't quite right. I'm attaching a slight fix. `autoconf`ing removes one level of square brackets in the 'sed' command to create $tgt. (Q about the issue tracker: I'm unable to change the Status field on this bug. I'm guessing that is by design, right? I.e., only certain people have the privs to change bug status?) -- keywords: +patch type: - compile error Added file: http://bugs.python.org/file10956/issue3381_configure_fix.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Georg Brandl [EMAIL PROTECTED] added the comment: Reopening. Yes, Status is settable only by Developers, but as a committer, you should certainly have that privilege. -- nosy: +georg.brandl status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2960] bsddb/test/test_replication.py bus error, segfault, assertion error, pass
Jesús Cea Avión [EMAIL PROTECTED] added the comment: Are you using a python pydebug version?. Can you reproduce the issue with a no pydebug python interpreter? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2960] bsddb/test/test_replication.py bus error, segfault, assertion error, pass
Gregory P. Smith [EMAIL PROTECTED] added the comment: using a python trunk optimized (non-debug) build and pybsddb r530: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berkeley DB 4.7.25: (May 15, 2008) bsddb.db.version(): (4, 7, 25) bsddb.db.__version__: 4.7.2devel3 bsddb.db.cvsid: $Id: _bsddb.c 527 2008-07-19 09:06:38Z jcea $ py module: /home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/__init__.py extension module: /home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/_pybsddb.so python version: 2.6b2+ (trunk:65173M, Jul 21 2008, 11:46:04) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] My pid: 9144 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Failure in test test01_basic_replication (bsddb3.tests.test_replication.DBReplicationManager) Traceback (most recent call last): File /home/greg/sandbox/python/trunk/Lib/unittest.py, line 279, in run testMethod() File /home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/tests/test_replication.py, line 134, in test01_basic_replication self.assertTrue(time.time()timeout) File /home/greg/sandbox/python/trunk/Lib/unittest.py, line 325, in failUnless if not expr: raise self.failureException, msg AssertionError Failure in test test01_basic_replication (bsddb3.tests.test_replication.DBBaseReplication) Traceback (most recent call last): File /home/greg/sandbox/python/trunk/Lib/unittest.py, line 279, in run testMethod() File /home/greg/sandbox/pybsddb/trunk/build/lib.linux-i686-2.6/bsddb3/tests/test_replication.py, line 352, in test01_basic_replication self.assertEquals(None, v) File /home/greg/sandbox/python/trunk/Lib/unittest.py, line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: None != '123' ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3387] undefined array passed to CryptGenRandomBytes
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed as r65174 and r65175. (for trunk, I had to change PyBytes_AS_STRING into PyString_AS_STRING) Thanks! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3387 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Martin v. Löwis [EMAIL PROTECTED] added the comment: max(buffer_size, n-avail) I mimicked the original logic rather than rethink the algorithm. I'm not totally sure what motivates the original logic but the purpose seems to be that non-blocking streams can return at least a few bytes rather than an empty string when less than N bytes are ready at OS level. IIUC, a read of the full requested size would achieve exactly that: on a non-blocking stream (IIUC), a read will always return min(bytes_available, bytes_requested). Hmm, what do you mean by if the stream is unbuffered? Unbuffered streams should use the raw unbuffered objects (e.g. FileIO) rather than wrap them with BufferedReader. IIUC, io.open will always return a BufferedReader, potentially with buffer_size=0 for unbuffered IO. This case must be supported. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3366] Add gamma and error functions to math module
Mark Dickinson [EMAIL PROTECTED] added the comment: Thanks for the patch! I probably won't get to this properly until after 2.6 final, but it won't get lost. It seems like there's pretty good support for adding these functions. By the way, there's already a setup in Python 2.6 (ad 3.0) for substitutes for missing math functions: take a look at the file Python/pymath.c, which provides inverse hyperbolic functions for those platforms that need them, as well as the bits in configure.in that check for these functions. This is the really the right place for the tgamma/lgamma/erf/erfc code. So a full patch for this should touch at least Python/pymath.c, Modules/mathmodule.c, configure.in, Lib/test/test_math.py, and Doc/Library/math.rst. If you have time to fill in any of these pieces, it would be greatly appreciated. -- priority: - normal ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Mark Dickinson [EMAIL PROTECTED] added the comment:
I still think this is the wrong solution, and should be fixed before 2.6;
long(float('nan')) should raise ValueError. As Alexander points out,
this fits much better with the IEEE 754 standard, and also with the C99
standard. It also just feels right, to me; an attempt to convert a nan
to an integer should not pass silently.
Here's a patch, based on Ronald's original patch.
Christian, what was the motivation for returning 0 here?
(One could also argue on the basis of IEEE 754 and C99 that
long(float('inf')) should raise ValueError instead of OverflowError;
personally, I'm content that long(float('inf')) raises an exception---I'm
not too bothered which one.)
I agree that there doesn't seem much value in backporting the fix.
--
keywords: +patch
Added file: http://bugs.python.org/file10957/issue1481296.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1481296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2378] UnboundLocalError when trying to raise exceptions inside execfile
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed as r65177. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Changes by Georg Brandl [EMAIL PROTECTED]: -- priority: normal - critical status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Mark Dickinson [EMAIL PROTECTED] added the comment: Assigning to me; I'd like to check in the new fix for 2.6/3.0, but I'll give it a couple of weeks for any objections to surface first. -- assignee: - marketdickinson versions: +Python 2.6, Python 3.0 -Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2523] binary buffered reading is quadratic
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le lundi 21 juillet 2008 à 21:18 +, Martin v. Löwis a écrit : IIUC, a read of the full requested size would achieve exactly that: on a non-blocking stream (IIUC), a read will always return min(bytes_available, bytes_requested). Hmm, it seems logical indeed... Alexandre, do you have other information on the subject? IIUC, io.open will always return a BufferedReader, potentially with buffer_size=0 for unbuffered IO. This case must be supported. No, io.open returns the raw object without wrapping it: if buffering == 0: if binary: raw._name = file raw._mode = mode return raw raise ValueError(can't have unbuffered text I/O) We could even decide to raise a ValueError when trying to construct a BufferedReader with a buffer_size 1. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3344] IDLE - use enumerate instead of zip(count(), ...)
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: -- assignee: - kbk ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3344 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3366] Add gamma and error functions to math module
Daniel Stutzbach [EMAIL PROTECTED] added the comment: On Mon, Jul 21, 2008 at 5:34 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: There are several different approximations to choose from. Each of them has their own implications for speed and accuracy. FWIW, the current patch dynamically selects one of a few different approximation methods based on the input value. +1 on kicking it around and comparing the output with that from other mathematics tools. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3423] DeprecationWarning message applies to wrong context with exec()
New submission from Greg Hazel [EMAIL PROTECTED]: exec()ing a line which causes a DeprecationWarning causes the warning to quote the file exec() occurs in instead of the string. Demonstration of the issue: http://codepad.org/aMTYQgN5 -- components: None messages: 70129 nosy: ghazel severity: normal status: open title: DeprecationWarning message applies to wrong context with exec() versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3359] add 'rbU' mode to open()
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Did you look at the io.open() function? It's a new module in python2.6, but also the builtin open in py3k! * On input, if newline is None, universal newlines mode is enabled. Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller. If it is '', universal newline mode is enabled, but line endings are returned to the caller untranslated. If it has any of the other legal values, input lines are only terminated by the given string, and the line ending is returned to the caller untranslated. I suggest to try io.open(filename, newline=) -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3366] Add gamma and error functions to math module
Raymond Hettinger [EMAIL PROTECTED] added the comment: It would be nice if we knew the error bounds for each of the approximation methods. Do we know how the coefficients were generated? When switching from one method to another, it might be nice to have a range where the results slowly blend from one method to another: if x a: return f1(x) if x b: return f2(x) t = (x - a) / (b - a) return (1-t)*f1(x) + t*f2(x) This minimizes discontinuities in the first and second derivatives. The lowword/highword macros look to be tightly tied to the internal processor representation for floats. It would be more portable and maintainable to replace that bit twiddling with something based on frexp (). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672115] Assignment to __bases__ of direct object subclasses
lorph [EMAIL PROTECTED] added the comment: Is anyone still working on this? It seems like an oddity of python that has been a stumbling block for me to create a super reload. I've found that i am able to bypass this problem by creating the following definition: class object(object):pass However, this feels like an ugly hack. -- nosy: +lorph ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue672115 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672115] Assignment to __bases__ of direct object subclasses
Michael Hudson [EMAIL PROTECTED] added the comment: Another 3 and a bit years on wink I still think my comment http://bugs.python.org/msg14169 is the crux of the issue. It's even relevant to your class object(object): pass hack! I'm not at all likely to work on this any time soon myself. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue672115 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3417] make the fix_dict fixer smarter
Collin Winter [EMAIL PROTECTED] added the comment: I think the proper way to address this is via the confidence levels that Rodrigo Bernardo Pimentel is adding for his Summer of Code project. The idea is that you'll be able to say let me inspect any changes where the fixer is less than X% confident. fix_dict and for loops would be one such place. Until that mechanism is in place, I agree with Raymond that we should err on the side of correctness. -- nosy: +rbp ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Martin v. Löwis [EMAIL PROTECTED] added the comment: We would need the copyright holder of the patch to submit a contributor form. Would that be possible? -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1767370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Senthil [EMAIL PROTECTED] added the comment: Sorry for the delay and my miss in further communication on this issue. I would like to take this issue in two fronts for its closure. 1) Issue with headers .capitalize() vs .title() 2) Documenting the Interface With respect to point 1), I assume that we all agree upon that headers should stored in Titled-Format instead of Capitalized-format. So I went ahead with the implementation of Titled format with a CaseInsensitive Lookup so that previous code using Capitalize format would also return values from the headers dict. John: I agree with your point that these changes would break the .header_items() that returns a list of Titled() key-value pairs, whereas the previous existing code would be expecting Capitalized key-value pairs. CaseInsensitive Dict lookup would not solve it. I had assumed that new code will be confirming to it and changed the tests. Even though I thought about it, I did not bring it up for discussion for backward compatibility header_items() method. - I don't have a solution for how to make header_items() backward compatible if we go for headers title() change. I shall try to come up by today. Now, if we go for a Case Normalization at the much later stage, will the headers be stored still in capitalize() format? ( In that case, this bug requests it be stored in .titled() format confirming to many practices) Would you like to explain a bit more on that? We can address the documentation of interface later to coming upon conclusion on the first one. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Gregory P. Smith [EMAIL PROTECTED] added the comment: Commited to trunk. r65182. This still needs backporting to release25-maint. (and release24-maint if anyone is maintaining that) -- keywords: +patch versions: +Python 3.0 -Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
