[issue3624] Null byte \0 not listed as a possible escape sequence

Georg Brandl <[EMAIL PROTECTED]> added the comment: The \0 falls under this case: \oooCharacter with octal value ooo where the note says "As in Standard C, up to three octal digits are accepted. " -- resolution: -> works for me status: open -> closed _

[issue3627] apple security patches need to be forward ported to py3k

New submission from Neal Norwitz <[EMAIL PROTECTED]>: The trunk revision was 65335. -- components: Interpreter Core messages: 71608 nosy: nnorwitz priority: release blocker severity: normal status: open title: apple security patches need to be forward ported to py3k versions: Python 3.0

[issue3618] possible deadlock in IO library (Lib/io.py)

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: see the python-3000 thread I just started asking for opinions on this. I'd personally say this bug is a good reason to go ahead with #3001 for 3.0. ___ Python tracker <[EMAIL PROTECTED]>

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- nosy: +gregory.p.smith ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3626] python3.0 interpreter on Cygwin ignores all arguments

New submission from Yaakov (Cygwin Ports) <[EMAIL PROTECTED]>: Attempting to build 3.0b3, the sharedmods make target results only in a python command prompt. In fact, it seems that the interpreter doesn't accept any arguments: $ /usr/bin/python --version Python 2.5.2 $ /usr/bin/python -c 'prin

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Mark Hammond <[EMAIL PROTECTED]> added the comment: Obviously IANAL, but my reading of eula.txt included with VS9 seems less restrictive than the 2003 one. It has 2 clauses that seem relevant: * [you must] require distributors and external end users to agree to terms that protect it at least as

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Changes by Mark Hammond <[EMAIL PROTECTED]>: -- nosy: +mhammond ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue1342811] Tkinter.Menu.delete doesn't delete command of entry

Guilherme Polo <[EMAIL PROTECTED]> added the comment: Well, beta3 was released and the problem remained there. Robert, I believe MvL assigned this to you for a reason.. I'm a bit stressed but what I'm trying to say is that you could have decided about this issue yourself and you decided to keep

[issue3625] test issues on 64bit windows

New submission from Mark Hammond <[EMAIL PROTECTED]>: A number of tests are designed to be skipped on 64bits, but they don't detect 64bit windows builds as 64bits. Also, test_bytes.test_repeat() assumes sys.maxint bytes can't be allocated, which isn't necessarily true on Win64. I'm attaching a

[issue2356] sys.exitfunc should raise a Py3K warning

Brett Cannon <[EMAIL PROTECTED]> added the comment: Actually, a fixer probably won't work since that would require the atexit module to be imported. ___ Python tracker <[EMAIL PROTECTED]> _

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3187] os.listdir can return byte strings

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3352] Deficiencies in multiprocessing/threading API

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3444] add warnings for intra-package imports

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3589] Misleading names for multiprocessing "convenience" functions

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3419] multiprocessing module is racy

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3612] Add some missing basic types in ctypes.wintypes

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>: -- title: Add some basic mssing types in ctypes.wintypes -> Add some missing basic types in ctypes.wintypes ___ Python tracker <[EMAIL PROTECTED]> __

[issue3373] sys recursion limit a lot shorter on trunk?

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Guido, can you comment? -- assignee: -> gvanrossum nosy: +gvanrossum priority: high -> release blocker ___ Python tracker <[EMAIL PROTECTED]>

[issue3612] Add some basic mssing types in ctypes.wintypes

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Module will be deleted at the end of file anyway (delete _ctypes), maybe we could just do "import ctypes" and "delete ctypes". Added file: http://bugs.python.org/file11183/avoid_giant_all_v2.patch ___ P

[issue3603] trivial typo in Include/pymath.h

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Don't worry. It's taken care of in all the active lines of development. ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Christian, I believe, did the original 3.0 porting, so he can probably shed some light on this. -- nosy: +benjamin.peterson, christian.heimes ___ Python tracker <[EMAIL PROTECTED]>

[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()

Bob Ippolito <[EMAIL PROTECTED]> added the comment: That patch looks ok to me, but I'm not at all familiar with the changes in python 3.0 yet. Is this something that needs to be backported to 2.6? ___ Python tracker <[EMAIL PROTECTED]>

[issue3611] invalid exception context

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue3611] invalid exception context

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Ok. I'll move the test after the betas. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ P

[issue3611] invalid exception context

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Patch was applied in r65921. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-

[issue3611] invalid exception context

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Short patch review: __context__ tests are mostly found in test_raise.py (class TestContext) test_exceptions.py seems to only deal with the exception object. ___ Python tracker <[EMAIL PROTECTED]>

[issue3611] invalid exception context

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3611] invalid exception context

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Here's Amaury's patch and a unittest based on lostcontext.py. -- keywords: +patch Added file: http://bugs.python.org/file11182/3611.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue3611] invalid exception context

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: This last proposal does not correct the behaviour of lostcontext.py. ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3611] invalid exception context

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: And if it doesn't work, try the following instead: if (why == WHY_EXCEPTION) { PyObject *tmp1, *tmp2, *tmp3; tmp1 = tstate->exc_type; tmp2 = tstate->exc_value; tmp3 = tstate->exc_traceback; tstate->exc_

[issue3624] Null byte \0 not listed as a possible escape sequence

New submission from Matt Aasted <[EMAIL PROTECTED]>: In current, future and past documentation, the valid escape sequence \0 (equivalent to \x00) is missing from the list of possible escape sequences in the documentation. As far as I can tell, it is not a case covered by any of the other elements

[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> bob.ippolito nosy: +bob.ippolito ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3611] invalid exception context

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Can you try with the following patch, "throwflag" is specific to a generator being deleted. Index: Python/ceval.c === --- Python/ceval.c (revision 65919) +++ Python/ce

[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()

New submission from STINNER Victor <[EMAIL PROTECTED]>: _json module of python 3.0 has some bugs. (a) [_json.c] raise_errmsg() calls json.decoder.errmsg() from Python module, but this function may fails. If it fails, error should be be set to NULL. Example: >>> import _json >>> _json.scanstri

[issue3611] invalid exception context

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Unfortunately, removing those lines causes a RuntimeError about exceeding the recursion limit for about 1/3 of the tests. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]>

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

Heikki Toivonen <[EMAIL PROTECTED]> added the comment: I would think most people/applications want to know to which host they are talking to. The reason I am advocating adding a default check to the stdlib is because this is IMO important for security, and it is easy to get it wrong (I don't thin

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: All right. You win! :) ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list m

[issue3622] Slight documentation quirk for random.random

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: [0, 1) denotes an interval, not a python object; 0 is included, 1 is excluded. And it follows (one of) the standard syntax to express intervals: http://en.wikipedia.org/wiki/Interval_notation -- nosy: +amaury.forgeotdarc resolu

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 3:05 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > Alternatively, you could just have another copy of catch_warning in > test_warnings with the extra argu

[issue3622] Slight documentation quirk for random.random

New submission from Allan Crooks <[EMAIL PROTECTED]>: The documentation for random.random function shows this: random() -> x in the interval [0, 1). That should either be "[0, 1]" or "(0, 1)". -- assignee: georg.brandl components: Documentation messages: 71582 nosy: amc1, georg.brandl

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: high -> deferred blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyt

[issue3611] invalid exception context

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-b

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 5:03 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Well, the bulk of the code needs to live in 'warnings' for it to exist > if the 'test' package is missing. So any differences need to come from > the test.support

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 2:53 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> Brett Cannon <[EMAIL PR

[issue3611] invalid exception context

STINNER Victor <[EMAIL PROTECTED]> added the comment: Great job amaury! So in ceval, here is the block responsible to clear the execution informations: Index: Python/ceval.c === --- Python/ceval.c (révision 65915) +++ Python/c

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Brett Cannon <[EMAIL PROTECTED]> added the comment: > > On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> >> Benjamin Peterson <[

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > I don't think the using argument should live in warnings; it's too test > specific. I recommend we st

[issue3614] typo in xmlrpc.client

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Corrected as r65920. Thanks for the report! -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3611] invalid exception context

STINNER Victor <[EMAIL PROTECTED]> added the comment: It looks that the problem is that PyErr_SetObject() is not re-entrant. The crash occurs when PyErr_SetObject() is called (indirectly) by PyErr_SetObject(): tstate->exc_value value is changed (set to NULL). As noticed by amaury.forgeotdarc, t

[issue3611] invalid exception context

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Having a snippet deterministically reproducing the problem > would really help in any case. Here you are. Don't ask how I found this. The attached script, when run, prints (KeyError(), ValueError()) (KeyError(), None) The current e

[issue3608] memoryview constructor has no deallocator

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue504152] rfc822 long header continuation broken

Kenneth Arnold <[EMAIL PROTECTED]> added the comment: This issue still seems to be present in Python 2.5's email module. feedparser.py line 444-445 says: # XXX reconsider the joining of folded lines lhdr = EMPTYSTRING.join(lastvalue)[:-1].rstrip('\r\n') I think that should be something like: l

[issue3612] Add some basic mssing types in ctypes.wintypes

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: And "avoid_giant_all_and_add_LPs.patch" adds bunch of LP(C)s. I'm not sure all LP types are needed. (Especially handle types) Added file: http://bugs.python.org/file11179/avoid_giant_all_and_add_LPs.patch _

[issue3612] Add some basic mssing types in ctypes.wintypes

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: >We could avoid the giant __all__ list when we 'import ctypes as >_ctypes' How about the attached patch "avoid_giant_all.patch"? Added file: http://bugs.python.org/file11178/avoid_giant_all.patch ___ P

[issue3611] invalid exception context

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > The problem comes when PyErr_SetObject triggers garbage collection which > runs python code (finalizers...). Mmmh, normally this shouldn't change the value of tstate->exc_value once that Python code returns. That's what exception stacking i

[issue3611] invalid exception context

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The problem comes when PyErr_SetObject triggers garbage collection which runs python code (finalizers...). I could reproduce the crash several times, and each time garbage collection was triggered by the normalization of the exception (

[issue3001] RLock's are SLOW

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Gregory, would you have an advice on #3618? -- versions: -Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3608] memoryview constructor has no deallocator

Roger Upole <[EMAIL PROTECTED]> added the comment: Aha, thanks. I'll go that route for now. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pytho

[issue1674032] Make threading.Event().wait(timeout=3) return isSet

Adam Milner <[EMAIL PROTECTED]> added the comment: I would like to add my support for this change. As David described, it is often useful to know why the x.wait() has returned, not just that it has. -- nosy: +carmiac ___ Python tracker <[EMAIL PROTEC

[issue3612] Add some basic mssing types in ctypes.wintypes

Thomas Heller <[EMAIL PROTECTED]> added the comment: I think this is too fancy. I would prefer to spell the definitions out like this: LPDWORD = PDWORD = POINTER(DWORD) LPCSTR = LPSTR = c_wchar_p We could avoid the giant __all__ list when we 'import ctypes as _ctypes' and write (for exampl

[issue3001] RLock's are SLOW

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I doubt subclassability of RLock matters but who knows, people do code things. Regardless, using a C version wrapped in a simple python container class that calls the underlying C implementation's methods should be sufficient to allow sub-c

[issue3608] memoryview constructor has no deallocator

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > As background, what I need is an equivalent of > PyBuffer_New(size), which creates an object that manages its > own buffer memory, and is not based on another object at all. Well, you can create either a bytes or bytearray object with an i

[issue3608] memoryview constructor has no deallocator

Roger Upole <[EMAIL PROTECTED]> added the comment: As background, what I need is an equivalent of PyBuffer_New(size), which creates an object that manages its own buffer memory, and is not based on another object at all. ___ Python tracker <[EMAIL PROTECTED]>

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I don't think the using argument should live in warnings; it's too test specific. I recommend we still keep a catch_warning in test_support (or even just test_warnings since this seems to be the only use-case). -- nosy: +benjamin.p

[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module

Brett Cannon <[EMAIL PROTECTED]> added the comment: Just some quick notes on this. The decorator should become: def catchwarning(*, record=False, using=warnings) Name change is to follow the naming convention in 'warnings' (even though I prefer underscores). The 'using' argument is what modul

[issue1675334] Draft implementation for PEP 364

Brett Cannon <[EMAIL PROTECTED]> added the comment: At this point we should probably just have PEP 364 rejected since 2to3 handles the renamings so well. -- assignee: brett.cannon -> barry ___ Python tracker <[EMAIL PROTECTED]>

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3611] invalid exception context

STINNER Victor <[EMAIL PROTECTED]> added the comment: I'm unable to write a short Python script to reproduce the bug. So download the full program: http://neudorf.hachoir.org/tmp/fusil3000.tar.gz Run in with: $ gdb python3.0 (gdb) run fusil-python --fast __

[issue3611] invalid exception context

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: [...] > > This exception may comes from PyObject_IsSubclass() which calls > PyObject_GetAttr(cls, "__subclasscheck__"). If you look at the code for PyObject_IsSubclass(), there is a pair of PyErr_Fetch / PyErr_Restore calls around PyObject_Ge

[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry

Jason Spiro <[EMAIL PROTECTED]> added the comment: Attaching testcase. It's basically just some sample code from the distutils documentation. Added file: http://bugs.python.org/file11177/testcase.zip ___ Python tracker <[EMAIL PROTECTED]>

[issue3565] array documentation, method names not 3.0 compliant

Matt Giuca <[EMAIL PROTECTED]> added the comment: A similar issue came up in another bug (http://bugs.python.org/issue3613), and Guido said: "IMO it's okay to add encodebytes(), but let's leave encodestring() around with a deprecation warning, since it's so late in the release cycle." I think t

[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry

New submission from Jason Spiro <[EMAIL PROTECTED]>: == Summary == Installers made by bdist_wininst never set EstimatedSize in the Windows registry. So Windows makes an estimate[1] of the installed software's size so the Add/Remove Programs control panel can tell users how much space the sof

[issue3611] invalid exception context

STINNER Victor <[EMAIL PROTECTED]> added the comment: About the PyEval_CallObject() call in errors.c, here is an example: Call exception<0x81dcee0>(args<0x8751dc4>) with exception= object : type: type refcount: 6 address : 0x81dcee0 and args= object : ("type object 'ProcE

[issue3611] invalid exception context

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: I retract what I said above. PyErr_SetObject() and friends only change tstate->curexc_* variables, not tstate->exc_*. The former (tstate->curexc_*) contain the current, pending (uncaught) exception state of the thread. The latter (tstate->exc

[issue3611] invalid exception context

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Selon STINNER Victor <[EMAIL PROTECTED]>: > > > How can tstate->exc_value become NULL at that point? [error.c:86] > > Could you investigate? > > PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since > the same thread state is t

[issue3613] base64.encodestring does not actually accept strings

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Did someone fix xmlrpc.client:1168 yet? IMO it's okay to add encodebytes(), but let's leave encodestring() around with a deprecation warning, since it's so late in the release cycle. -- nosy: +gvanrossum __

[issue3620] test_asyncore is not cleanup after its self?

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: This is from the sparc Unbuntu 3.0 bot. I'm having trouble reproducing it, though. test test_smtplib produced unexpected output: ** *** line 2 of actual output doesn't a

[issue3611] invalid exception context

STINNER Victor <[EMAIL PROTECTED]> added the comment: > How can tstate->exc_value become NULL at that point? [error.c:86] > Could you investigate? PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since the same thread state is the same, tstate->exc_value also changes during this

[issue3612] Add some basic mssing types in ctypes.wintypes

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: I've created the patch which adds LPDWORD and friends. Can you review it? Added file: http://bugs.python.org/file11176/adds_LPDWORD_and_friends.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue3001] RLock's are SLOW

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Wow, that was quick. Did you try to replace threading.RLock with your implementation, and run the tests? By the way: > - acquire() method argument "blocking" is not a keyword > - In the Python version, RLock._release_save() replaces owner and

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ooops again, I uploaded my patch to the wrong issue! The new patch is now in the issue #3001. ___ Python tracker <[EMAIL PROTECTED]> _

[issue3618] possible deadlock in IO library (Lib/io.py)

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11174/rlock.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3001] RLock's are SLOW

STINNER Victor <[EMAIL PROTECTED]> added the comment: Oops, I forgot to update PyInit__Thread() with my new time: - Add PyType_Ready() - Register RLockType to threading dict Here is the new patch. Added file: http://bugs.python.org/file11175/rlock-v2.patch ___

[issue3619] A more informative message for ImportError

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- components: +Interpreter Core -None priority: -> low versions: +Python 3.1 ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: Oops, I forgot to update PyInit__Thread() with my new time: - Add PyType_Ready() - Register RLockType to threading dict Here is the new patch -- keywords: +patch Added file: http://bugs.python.org/file11174/rlock.patch ___

[issue3619] A more informative message for ImportError

New submission from Kent Tenney <[EMAIL PROTECTED]>: from foo import bar ImportError: cannot import name bar The error may be due to the wrong 'foo' being found, some investigation is required. If the the ImportError message included the filename for 'foo', the problem would be obvious. ImportE

[issue3618] possible deadlock in IO library (Lib/io.py)

STINNER Victor <[EMAIL PROTECTED]> added the comment: @pitrou: I wrote an implementation of RLock in C (see #3001). So it would be possible to use threading.RLock instead of threading.Lock ;-) ___ Python tracker <[EMAIL PROTECTED]>

[issue3001] RLock's are SLOW

STINNER Victor <[EMAIL PROTECTED]> added the comment: As suggested by pitrou, I wrote an implementation of RLock in C. Changes to Python version: - no debug message: i leave the message in #if 0 ... #endif - acquire() method argument "blocking" is not a keyword Notes: - RLock has no docstrin

[issue3612] Add some basic mssing types in ctypes.wintypes

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: I've committed basic type addition in r65908. Addition of LPDWORD and its friends will follow. ___ Python tracker <[EMAIL PROTECTED]> __

[issue3618] possible deadlock in IO library (Lib/io.py)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Yes indeed. We could use an RLock to avoid the problem but RLock's are damn slow since they are written in pure Python (see #3001). Rewriting the critical parts of RLock (constructor, acquire(), release(), __enter__(), __exit__()) in C should

[issue3618] possible deadlock in IO library (Lib/io.py)

New submission from STINNER Victor <[EMAIL PROTECTED]>: BufferedWriter from Lib/io.py is thread-safe, but... the Python instruction "with self._write_lock:" could be interrupted when the lock is already acquired. Especially, _lsprof.Profiler() uses ceval hook and is called when the lock is acq

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca <[EMAIL PROTECTED]> added the comment: > > it should be renamed to encodestring > Huh ? It is already called that :) Um ... yes. I mean encodebytes :) > > Best we can do is document them. > Oh well. But I don't know the rules. People are saying things like "no new features after bet

[issue3613] base64.encodestring does not actually accept strings

Dmitry Dvoinikov <[EMAIL PROTECTED]> added the comment: > I think it probably is correct to NOT accept a string I agree. > it should be renamed to encodestring Huh ? It is already called that :) IMO it should be renamed to encodebytes or simply encode if the module is only (or most frequently)

[issue3612] Add some basic mssing types in ctypes.wintypes

Thomas Heller <[EMAIL PROTECTED]> added the comment: I have no objections against this patch - feel free to check it in if it is not too late before the beta. Also I think that LPDWORD and friends are a good idea, you should extend the patch with them. -- assignee: theller -> ocean-city

[issue3300] urllib.quote and unquote - Unicode issues

Matt Giuca <[EMAIL PROTECTED]> added the comment: Thanks for pointing that out, Antoine. I just commented on that bug. ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3613] base64.encodestring does not actually accept strings

Matt Giuca <[EMAIL PROTECTED]> added the comment: Hi Dmitry, RE the method behaviour: I think it probably is correct to NOT accept a string. Given that it's base64 encoding it, it only makes sense to encode bytes, not arbitrary Unicode characters which have no well-defined binary representation.

[issue3613] base64.encodestring does not actually accept strings

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: The encodestring() function is refered to in the docs as "the legacy interface". Perhaps it should be simply deprecated in 3.0? -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl, pitrou priority: -> high _

[issue3300] urllib.quote and unquote - Unicode issues

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: There's an unquote()-related failure in #3613. ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3615] Expect methods for testing.

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Interesting, but it should be discussed on the mailing-list first. Also, since this is a new feature, it must be retargeted to 2.7/3.1. -- nosy: +pitrou priority: -> normal type: -> feature request versions: +Python 2.7, Python 3.1

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: Note that there are a few gotchas in the MS EULA, such as disallowing to ship the DLLs with GPLed Python products or requiring that the PSF prevents further redistribution of the DLLs unless used in conjunction with Python. -- pri

  1   2   >