[issue3385] cPickle to pickle conversion in py3k missing methods
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: A use case: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/572213 shows how code can use the Pickler.dispatch dict, but also some Pickler.save_xxx function which should be exposed as well. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3385 ___ ___ 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: - A immmutable object may contain mutable members. Try with a tuple containing a list. Then, I don't think that something says that CFunctionObjects are immutable. They don't have any modifiable attribute, until today! - (Did I say string?) The new PyMethodDef::ml_annotations would not be a char*, but a PyObject* member. If it is not possible to set it in the static array, one could update the array in the module init function. Anyway, for a SWIG module I think the best is to set the __annotations__ in the shadow python file. It seems more practical to build the dict there. ___ 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
[issue2523] binary buffered reading is quadratic
Antoine Pitrou [EMAIL PROTECTED] added the comment: When I revised the patch I had a weak understanding of nonblocking I/O. I thought the exponential reads were for nonblocking I/O, but I see now that is non-sense. Fine, so it will make the patch simpler. As for non-blocking IO, I think we should raise the general issue on python-3000. There is no real support for it right now, by which I mean (1) no easy and portable way of enable non-blocking IO on a file object and (2) no test cases of non-blocking IO in real-world conditions (rather than with mock objects). This shouldn't stop us from fixing the present bug though. I am not sure, but I think Martin is also right about the second loop. The max() call should be changed back to max(self.buffer_size, n)), like in the 2nd patch. Ok. Could you produce an updated patch? :) ___ 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
[issue3379] Option to not-exit on test
J. Pablo Fernández [EMAIL PROTECTED] added the comment: What about always returning the results. Granted, when sys.exit is run there will be no results returned, but then nothing to get the results. If we divided in two functions, would one be unittest.main and the other unittest.nonExitingMain? Sounds ugly, but OK if no other better way is possible. I personally believe that main should not hijack the current interpreter with sys.exit at all, but I understand that behavior is not changeable at the moment (is it?). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3379 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2417] [py3k] Integer floor division (//): small int check omitted
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- nosy: +pitrou priority: - normal ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2417 ___ ___ 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
Antoine Pitrou [EMAIL PROTECTED] added the comment: Greg, I'm not sure your improvement patch is right, since some code may be holding a reference to the former _MainThread instance and expecting it to still be part of the active threads container. On the other hand there are things in the Thread class that may need reinitializing after a fork (e.g. self.__block = Condition(Lock()), and self.__ident = _get_ident() :-))... so perhaps your patch is a good enough approximation of what is needed. ___ 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
[issue3256] Multiprocessing docs are not 3.0-ready
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10848/multiprocessing.rst.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3256] Multiprocessing docs are not 3.0-ready
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10960/issue3256.multiprocessing.rst.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3256] Multiprocessing docs are not 3.0-ready
Andrii V. Mishkovskyi [EMAIL PROTECTED] added the comment: Here is the updated version of multiprocessing.rst patch. Not much has changes, as you can see (if you've seen the previous version, of course ;) ). I have only one question left about multiprocessing.rst, it's about 'allow_connection_pickling' function -- should documentation cover this function or just leave it as it is? The only issue I still have is mp_distributing.py example, which is not properly documented. Jesse, I think you should review both patches and leave this issue open until mp_distributing.py is documented. If you have any questions -- ping me on #python-dev. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3431] multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle
New submission from Georg Brandl [EMAIL PROTECTED]: multiprocessing's new ForkingPickler uses Pickler's dispatch attribute which is only present in the Python version, not the C one. As a result, a straightforward merge isn't possible. -- assignee: jnoller components: Library (Lib) messages: 70176 nosy: alexandre.vassalotti, georg.brandl, jnoller severity: normal status: open title: multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle versions: Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524] os.system() fails for commands with multiple quoted file names
qiang [EMAIL PROTECTED] added the comment: in subprocess.py , change line 788: args = comspec + /c + args to: args = comspec + args it will be ok. -- nosy: +likes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1524 ___ ___ 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
Haoyu Bai [EMAIL PROTECTED] added the comment: I think there is reason that CFunctionObjects are immutable: single CFunctionObject is shared by mutiple Python interpreters, so any change of CFunctionObject would affect other Python interpreters. Is that right? If it should be immutable, then we should use something like static array to assign annotations to CFunctionObject, and the value also should be immutable, that means the value couldn't be abitrary PyObject. (by value I mean the value of every __annotations__ dict items.) For SWIG, there's a way to bypass the Python side proxy, eg. for a simple C function, in the shadow module we directly let 'func=_cmod.func', where _cmod is the C DLL module. So the annotation information would be lost if we can't directly assign annotation to C function. ___ 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
[issue3208] function annotation for builtin and C function
Benjamin Peterson [EMAIL PROTECTED] added the comment: There never should be multiple Python interpreters running in the same process, though. -- nosy: +benjamin.peterson ___ 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
[issue3359] add 'rbU' mode to open()
Skip Montanaro [EMAIL PROTECTED] added the comment:
As I indicated in msg69679 if you want to see the line endings just open
the file in binary mode ('rb').
___
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
[issue3353] make built-in tokenizer available via Python C API
Andy [EMAIL PROTECTED] added the comment: Sorry for the terribly dumb question about this. Are you meaning that, at this stage, all that is required is: 1. the application of the PyAPI_FUNC macro 2. move the file to the Include directory 3. update Makefile.pre.in to point to the new location Just I have read this now 10 times or so and keep thinking more must be involved :-) [certainly given my embarrassing start to the Python dev community re:asynchronous thread exceptions :-| ] I have attached a patch that does this. Though at this time it is lacking any documentation that will state what parts of struct tok_state are private and public. I will need to trawl the code some more to do that. I have executed: - ./configure - make - make test And all proceed well. -- keywords: +patch nosy: +kirkshorts Added file: http://bugs.python.org/file10961/issue3353.diff ___ 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
[issue2975] VS8 include dirs grow without bound
Jim Kleckner [EMAIL PROTECTED] added the comment: Any new thoughts on this? I had to patch my local copy again after a reinstall. It would be nice to fix it upstream. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner [EMAIL PROTECTED] added the comment:
Sorry, posted too quickly.
Actually, the problem was a little different.
There was an environment variable with '=' characters in it.
Here is a patch to deal with that:
--- msvc9compiler.py.orig 2008-07-23 16:13:25.248438400 -0700
+++ msvc9compiler.py2008-07-23 16:13:54.059867200 -0700
@@ -252,7 +252,9 @@
if '=' not in line:
continue
line = line.strip()
-key, value = line.split('=')
+i = line.index('=')
+key = line[0:i]
+value = line[i:]
key = key.lower()
if key in interesting:
if value.endswith(os.pathsep):
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2975
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3431] multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Duplicate of issue3385 -- resolution: - duplicate status: open - closed superseder: - cPickle to pickle conversion in py3k missing methods ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2417] [py3k] Integer floor division (//): small int check omitted
Facundo Batista [EMAIL PROTECTED] added the comment: Alexander, tried the issue2417a.diff patch against 65210, and does not apply cleanly, could you please submit an updated one? Thanks! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2417 ___ ___ 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
Haoyu Bai [EMAIL PROTECTED] added the comment: As I understand, at least C extension modules, which built as shared library, would be shared among Python interpreter in different process space. Is that correct? ___ 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
[issue1758146] Crash in PyObject_Malloc
Graham Dumpleton [EMAIL PROTECTED] added the comment: Franco, you said 'I found that you cannot create additional thread states against the first interpreter and swap between them w/o this assertion occurring. ...' Since the Py_DEBUG check is checking against the simplified GIL state API thread state object, then technically you could have a thread with multiple thread states, that thread just can't ever use/have used simplified GIL state API. Take for example a system where threads are actually foreign threads and not created within Python. In this case simplified GIL state API thread state object would never have been created for that thread. For those you could have multiple thread states and not trip the test. In other words, multiple thread states only blocked if one of them is the internal one created by simplified GIL state AP. This is getting hard to avoid though. In summary, the simplified GIL state API is basically viral in nature. ___ 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
[issue2417] [py3k] Integer floor division (//): small int check omitted
Alexander Belopolsky [EMAIL PROTECTED] added the comment: It looks like e-mail submission did not work. Uploading updated patch as issue2417b.diff . Added file: http://bugs.python.org/file10962/issue2417b.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3432] Mac, 2.6 framework install error
New submission from Robin Dunn [EMAIL PROTECTED]: OSX Leopard (10.5.4) Python-2.6b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd Mac make installmacsubtree DESTDIR= Creating directory /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386 ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools Traceback (most recent call last): File ./scripts/cachersrc.py, line 7, in module import macresource File /projects/Python-2.6b2/Lib/plat-mac/macresource.py, line 6, in module from Carbon import Res File /projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py, line 4, in module from _Res import * ImportError: No module named _Res make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Since by this time in the install process the _Res module has already been installed I was able to work around this issue by hacking the generated Mac/Makefile and setting RUNSHARED to nothing. The same problem happens in Mac/IDLE/Makefile as well. -- components: Macintosh messages: 70189 nosy: robind severity: normal status: open title: Mac, 2.6 framework install error type: compile error versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] Mac, 3.0 framework install error with fink cp
New submission from Robin Dunn [EMAIL PROTECTED]: OSX Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd PythonLauncher make install DESTDIR= test -d /Applications/Python 3.0 || mkdir -p /Applications/Python 3.0 test -d /Applications/Python 3.0/Python Launcher.app rm -r /Applications/Python 3.0/Python Launcher.app cp -r Python Launcher.app /Applications/Python 3.0 touch /Applications/Python 3.0/Python Launcher.app test -d /Applications/Python 3.0 || mkdir -p /Applications/Python 3.0 test -d /Applications/Python 3.0/IDLE.app rm -r /Applications/Python 3.0/IDLE.app make[1]: [install_IDLE] Error 1 (ignored) cp -PR IDLE/IDLE.app /Applications/Python 3.0 cp: Warning: the meaning of `-P' will change in the future to conform to POSIX. Use `--parents' for the old meaning, and `--no-dereference' for the new one. ln -sf /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python /Applications/Python 3.0/IDLE.app/Contents/MacOS/Python ln: creating symbolic link `/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python' to `/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python': No such file or directory make[1]: *** [install_IDLE] Error 1 make: *** [frameworkinstallapps] Error 2 It looks like this is due to fink's cp being found first on the PATH. Temporarily disabling /sw/bin/cp so /bin/cp would be found first then the install finished. -- components: Macintosh messages: 70190 nosy: robind severity: normal status: open title: Mac, 3.0 framework install error with fink cp type: compile error versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3434] Mac, 3.0 framework install, Python.app not created
New submission from Robin Dunn [EMAIL PROTECTED]: OS X Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app is not created by the install step, but it is needed for running python3.0: $ python3.0 python3.0: execv: /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python: No such file or directory -- components: Macintosh messages: 70191 nosy: robind severity: normal status: open title: Mac, 3.0 framework install, Python.app not created type: compile error versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3434 ___ ___ 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
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, Jul 23, 2008 at 8:44 PM, Haoyu Bai [EMAIL PROTECTED] wrote: Haoyu Bai [EMAIL PROTECTED] added the comment: As I understand, at least C extension modules, which built as shared library, would be shared among Python interpreter in different process space. Is that correct? The operating system should provide memory protection between processes. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3208 ___ Added file: http://bugs.python.org/file10963/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3208 ___div dir=ltrbrbrdiv class=gmail_quoteOn Wed, Jul 23, 2008 at 8:44 PM, Haoyu Bai lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br Haoyu Bai lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br As I understand, at least C extension modules, which built as sharedbr library, would be shared among Python interpreter in different processbr space. Is that correct?/blockquotedivbrThe operating system should provide memory protection between processes. br/divblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br br ___br Python tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue3208; target=_blankhttp://bugs.python.org/issue3208/agt;br ___br /blockquote/divbrbr clear=allbr-- brCheers,brBenjamin Petersonbrquot;There#39;s no place like a href=http://127.0.0.1;127.0.0.1/a.quot; /div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
