[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Attached is a patch for distutils/sysconfig.py. -- keywords: +patch Added file: http://bugs.python.org/file18866/distutils_sysconfig.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Attached is a patch for sysconfig.py. -- Added file: http://bugs.python.org/file18867/sysconfig.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
N.B. without the sysconfig.py patch, sysconfig.get_path() fails, but
differently.
With the patch, sysconfig.get_path('stdlib') and sysconfig.get_path('include')
give the expected values, but _CONFIG_VARS['srcdir'] still seems wrong:
vi...@eta-jaunty:/tmp$ python3.2
Python 3.2a2+ (py3k:84759, Sep 13 2010, 05:14:55)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
import sysconfig
sysconfig._CONFIG_VARS['srcdir']
'/tmp'
Someone please take a look!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6087
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9844] calling nonexisting function under __INSURE__
New submission from Eli Bendersky eli...@gmail.com: The Py_Main function has a section under #ifdef __INSURE__ at the end, where it does: _Py_ReleaseInternedStrings(); _Py_ReleaseInternedUnicodeStrings(); The first function doesn't exist in Python 3K, so there will be a compile error with __INSURE__ defined. -- components: Interpreter Core messages: 116281 nosy: eli.bendersky priority: normal severity: normal status: open title: calling nonexisting function under __INSURE__ type: compile error versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9787] Release the TLS lock during allocations
Martin v. Löwis mar...@v.loewis.de added the comment: You may find this hard to believe, but we do in fact embed python into other applications. This is actually very easy to believe. appMalloc, is in this case, the canonical memory allocator in UnrealEngine. But it could be any other memory allocator so that is beside the point. This seems to be the core of the issue. Any other memory allocator would *not* inquire about the state of Python. Any other memory allocator would not even be aware that it is used by Python. What appMalloc is doing, in this case, is for every allocation, to get the python TLS pointer. There is nothing wrong with this I find this wrong. It violates the software layering. The memory management layer is not supposed to access upper layers (such as the interpreter state, or the application state). Now, regardless of the above, surely it is an improvement in general if we make tighter use of the TLS lock. It's not a good idea to hold this lock across malloc calls if we can avoid it. The patch is harmless, might even be an improvement, so why object to it? The code change itself is harmless, yes. The comment is not. It imposes a requirement on Python (namely, that the malloc implementation may be free to make calls to Python) which is harmful. The malloc implementation just has no business looking at the thread state. So I remain -1 on this change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9743] __call__.__call__ chain cause crash when long enough
Alex alex.gay...@gmail.com added the comment: I doubt there is a good usecase for it, nevertheless we should attempt to fix it, as segfaults are no good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9786] Native TLS support for pthreads
Martin v. Löwis mar...@v.loewis.de added the comment: It seems we need to clarify the return value of PyThread_create_key. The patch returns 0 in case of failure, which is clearly wrong as 0 is also a valid key. I think it's safe to return -1: TlsAlloc returns TLS_OUT_OF_INDEXES, which is 0x, i.e. -1 on a 32-bit system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
Kay Hayen kayha...@gmx.de added the comment: Why did you remove Python2.7 from the versions list? Isn't this supposed to track the affected versions? (This is not the first time I encountered that.) I understand that you may not fix all bugs in 2.x, but is it already unsupported in the sense that its bugs are not tracked, then remove it from the tracker. In the alternative, please add 2.7 (and 2.6) back. Thanks, Kay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8796] Deprecate codecs.open()
Marc-Andre Lemburg m...@egenix.com added the comment: We can reconsider this at some later time, when Python 2.x is not really used much anymore. -- resolution: - postponed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9787] Release the TLS lock during allocations
Kristján Valur Jónsson krist...@ccpgames.com added the comment: The malloc implementation just has no business looking at the thread state. Of course it does, if it you want to have any hope of instrumenting your python memory usage with detailed python runtime information. Your statement islike saying: A profiler has no business looking at the thread callstack. Note that we are not making any new requirements on python here. Merely facilitating the process, for those implementations that _wish_ to do so (at their own risk.) So, although you have nothing against the patch as such, you are against it on the principle that I am using it to facilitate something that you disapprove of. I find that a quite unreasonable position. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9786] Native TLS support for pthreads
Kristján Valur Jónsson krist...@ccpgames.com added the comment: I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key(). See e.g. thread.c:294 /* Return a new key. This must be called before any other functions in * this family, and callers must arrange to serialize calls to this * function. No violations are detected. */ int PyThread_create_key(void) -- Added file: http://bugs.python.org/file18868/pthread_tls.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9787] Release the TLS lock during allocations
Martin v. Löwis mar...@v.loewis.de added the comment: Note that we are not making any new requirements on python here. But you are. So far, there was no guarantee whatsoever about the state of Python when malloc is called. You are now introducing a requirement that Python must be in a certain state to make it correct to call malloc. IOW, this innocent change actually introduces a new feature. So, although you have nothing against the patch as such I think it's harmless - I don't think it is a good patch. It shouldn't matter whether or not it is applied (i.e. there is no change to Python that I can see). you are against it on the principle that I am using it to facilitate something that you disapprove of. I find that a quite unreasonable position. No. It's not the usage that I disapprove but, but the new requirement on Python. If you were able to do your profiling in a manner compatible with (the current) Python, it would be certainly fine with me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7994] object.__format__ should reject format strings
Florent Xicluna florent.xicl...@gmail.com added the comment: now the PendingDeprecationWarnings are checked in the test suite, with r84772 (for 2.7). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7994 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9799] Compilation error for branch py3k on AIX 6
Sébastien Sablé sa...@users.sourceforge.net added the comment: Yes, no problem; I will update the Misc/AIX-NOTES file with all the information I have been collecting recently on Python with AIX. I will do that when I will have solved some remaining issues I have on AIX, and also when I will have checked with AIX 5.3 as well (I am currently focused on 6.1). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9786] Native TLS support for pthreads
Martin v. Löwis mar...@v.loewis.de added the comment: Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson: Kristján Valur Jónsson krist...@ccpgames.com added the comment: I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key(). Right. That's why I'm thinking that we should introduce some. TLS creation *can* fail, and it is unfortunate that the original introduction of this API forgot to consider that. Your patch did (de facto) introduce an error return code (originally 0, now -1). So it would be good if this was documented, and the NT version adjusted. In principle, this is really difficult to get right. AFAICT, pthread_key_t doesn't even have to be an integral type, and even if it is, it may well become -1. However, we can probably worry about this when a system comes along where this implementation breaks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9779] argparse.ArgumentParser not support unicode in print help
Steven Bethard steven.beth...@gmail.com added the comment: Are you sure this is an argparse issue, and not a terminal issue? Here's what I see: parser = argparse.ArgumentParser(description=u'Rus Рус') print(parser.description) Rus Рус sys.stderr.write(parser.description) Traceback (most recent call last): File stdin, line 1, in module UnicodeEncodeError: 'ascii' codec can't encode characters in position 4-6: ordinal not in range(128) parser.format_help() u'usage: [-h]\n\nRus \u0420\u0443\u0441\n\noptional arguments:\n -h, --help show this help message and exit\n' sys.stderr.write(parser.format_help()) Traceback (most recent call last): File stdin, line 1, in module UnicodeEncodeError: 'ascii' codec can't encode characters in position 17-19: ordinal not in range(128) To me, it looks like sys.stderr doesn't like the unicode, even though at the interactive prompt I can print things okay. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
R. David Murray rdmur...@bitdance.com added the comment: We use versions to track which versions we are going to fix, not which versions are affected (which is why we don't list any versions pre-2.5...2.5 and 2.6 occasionally get security fixes, but no earlier versions even get those). Now, why Brett removed 2.7 is more of a mystery... -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames
STINNER Victor victor.stin...@haypocalc.com added the comment: I fail to see why removing incorrect file names from the result list is any better than keeping them. The result list will be incorrect either way. It depends if you focus on displaying the content of the directory, or on processing files and directories. If you focus on display, yes, missing files an be seen as a bug. But if you walk into directories (use cases: os.walk(), replace a text pattern in all files (~os.glob), ...), and the function raises an error (because a directory or a file name is invalid) is worse. I mean the user have to rename all unencodable names, or the devfeloper have to patch its application to catch IOError and ignore the specific IOError(22). If listdir() ignores unencodable names, os.walk() doesn't fail, but it misses some subdirectories and files. -- Another (worse?) idea: deny bytes path for os.listdir(), but I suppose that we will not like the idea ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames
STINNER Victor victor.stin...@haypocalc.com added the comment: I think trying to emulate, in Python, what the *A functions do is futile. My problem is that some functions will use mbcs in strict mode (functions using PyUnicode_EncodeFSDefault): raise UnicodeEncodeError, and other will use mbcs in replace mode (functions using Windows functions in ANSI mode): raise IOError (or other error depending on the function). It's inconsistent. We should try to keep the same behaviour for all functions. Examples of functions using (indirectly) PyUnicode_EncodeFSDefault to encode unicode filenames: bz2.BZ2File() and _ssl.SSLContext.load_cert_chain(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6011] python doesn't build if prefix contains non-ascii characters
Baptiste Carvello baptiste...@free.fr added the comment: Eric: the bug does not exist with 2.7, as the Makefile is read as bytes. It exists with 3.1.2. By the way, when I say the bug is solved on 3.2, I only mean the narrow problem of using a non-ascii prefix that *is* decodable with the current locale. I do not mean the more general problem that arises, for example, when building with the 'C' locale, as is discussed in issue9561. With a 'C' locale, the build fails also with 3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6011 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames
R. David Murray rdmur...@bitdance.com added the comment: After the decision to ignore undecodable file names in os.listdir but before PEP 383 there was a long discussion on python-dev (in which I was a participant) about how horrible just ignoring the undecodable filenames was. This applies *especially* to the os.walk case, where some files would be mysteriously skipped and it wouldn't be obvious why. Or even obvious that they'd been skipped, in some cases. The biggest issue was that the developer would likely never see the problem since the bulk of developers don't encounter encoding issues, so it would be the poor end user who would be confronted with the mystery, with no clues as to the cause or solution. The conclusion of that particular thread was that Guido approved adding warning messages for filenames that were undecodable, but otherwise leaving os.listdir unchanged. Fortunately Martin came up with PEP 383, which solved the underlying problem in a better way. So, I don't think that skipping the undecodable names is good, unless you generate a warning. In that thread I started out advocating raising an error, but in this case as Martin points out that would be a backward compatibility issue. Returning the munged filenames and having the error show up when the broken filename is used seems OK to me, even if imperfect. When the user sees the problem, they report it to the developer as a bug, who hopefully changes his code to use strings. Adding warning messages would probably be useless at best and annoying at worst on Windows. Maybe we could add a pseudo deprecation warning (ie: aimed at developers, silent by default) that says don't use listdir with bytes on windows? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9820] Windows : os.listdir(b'.') doesn't raise an errorfor unencodablefilenames
R. David Murray rdmur...@bitdance.com added the comment: But in the case of BZ2File and ssl.SSLContext.load_cert_chain(), isn't it the case that they are trying to open the files? So producing an early error about the decoding problem makes sense. Are there any functions other than listdir where the decoded filenames are not necessarily immediately used to manipulate the files? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9845] Allow changing the method in urllib.request.Request
New submission from Tarek Ziadé ziade.ta...@gmail.com: Right now you have to override Request or patch its get_method() method to be able to send HTTP requests where the method is not GET or POST. This is making some assumptions on what the users wants to do with the request. The way get_method guesses the method is good enough in most cases, but I think it would be good to let advanced developers provide their own method when they build a request. This would avoid unnecessary boiler-plate code to be able to customize the method. -- assignee: orsenthil components: Library (Lib) files: request_custom_method.patch keywords: patch messages: 116301 nosy: orsenthil, tarek priority: normal severity: normal status: open title: Allow changing the method in urllib.request.Request type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file18869/request_custom_method.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9845] Allow changing the method in urllib.request.Request
Tarek Ziadé ziade.ta...@gmail.com added the comment: sorry - Removed the assignment (the name is not followed by *) -- assignee: orsenthil - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
Nick Coghlan ncogh...@gmail.com added the comment: I assume Brett marked this 3.x only because we currently don't support builtin packages at all, so making this work crosses way over into feature request territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7). Added the relevant dependency regarding support for builtin packages and removed 3.2 as a target version (as per Brett's comment on the other issue - the necessary spec work hasn't even been started, so there's no way this is a chance for 3.2). -- dependencies: +Allow built-in packages and submodules as well as top-level modules type: behavior - feature request versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1475397] time.asctime_tz, time.strftime %z %C
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Would issue9527 address your request? Note that datetime.strftime already
supports %z:
from datetime import *
datetime.now(timezone.utc).strftime('%c %z')
'Mon Sep 13 13:43:19 2010 +'
(I assume you meant to write %c, not %C.)
--
assignee: - belopolsky
dependencies: +Add aware local time support to datetime module
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1475397
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9782] _multiprocessing.c warnings under 64-bit Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1076515] shutil.move clobbers read-only files.
Changes by Antoine Pitrou pit...@free.fr: -- stage: unit test needed - type: behavior - feature request versions: -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1076515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
Antoine Pitrou pit...@free.fr added the comment: Can you try using CC=cc -m64 OPT=-O3 instead? (replace cc with the proper compiler name, of course) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9566] Compilation warnings under x64 Windows
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9323] trace.py bug with the main file being traced
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: The full path *could* be easily passed, but I think we should address this problem from regrtest.py's side. I disagree. There may be other scripts that rely on __main__.__file__ being an absolute path and we cannot require everyone to change their assumptions to make their scripts traceable. It looks like absolute path assumption was added by Florent in r78723 (r78719 in trunk). Florent, I would like to hear from you before deciding how to proceed. See also issue #7712. -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9614] _pickle is not entirely 64-bit safe
Changes by Jon Anglin jang...@fortresgrand.com: -- nosy: +janglin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9614 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9828] Repeated Py_Initialize and Py_Finalize usage brings fatal error?
Antoine Pitrou pit...@free.fr added the comment: Fix committed in r84774. Thank you! -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4761] create Python wrappers for openat() and others
Changes by Chris Gerhard chris.gerh...@oracle.com: -- nosy: +Chris.Gerhard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
Charles Solar charlesso...@gmail.com added the comment: I just recompiled using your suggested flags and it is now properly linking my extensions. I guess using CFLAGS and LDFLAGS was causing the problem. Is specifying CC the recommended way to build 64 bit python? If so when I guess this issue is not really an issue at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
Antoine Pitrou pit...@free.fr added the comment: Is specifying CC the recommended way to build 64 bit python? Currently, yes. LDFLAGS is supposed to work, but it doesn't (open bug: #9437). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1538778] pyo's are not overwritten by different optimization levels
Barry A. Warsaw ba...@python.org added the comment:
How is this different than overwriting pyc files, except that there's probably
less of a use case for pycs? IOW, if we were to do something about this, it
should probably be an option to ignore any existing pyc (or pyo if -O is used)
files and write new ones. It *could* be a command line switch, but honestly I
think find ... -exec rm {} is just as good.
I'd probably prefer adding a switch to Lib/py_compile's main to remove
pyo/pyc's first or some such, but I'd still be -0 on supporting this directly
in Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1538778
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Barry A. Warsaw ba...@python.org added the comment: My (I think fairly straightforward) idea is to just compile the useful values in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import that and check it first (fallback to parsing mf and conf.h). I'll see if I can whip up a patch for that for review and feedback. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Antoine Pitrou pit...@free.fr added the comment: Is there any point in creating another extension module? We already have Modules/getpath.c which receives various configuration values at compile-time, themselves exposed as sys.prefix and friends. The simpler the better, IMO. sysconfig can choose to expose those sys values in a funkier format if it wishes to do so. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7280] PCBuild instruction says to use nasmw.exe but it no longer exist
sorin sorin.sbar...@gmail.com added the comment: Please reopen the bug, current documentation change is not a proper solution and also it does not work (see below). Python's openssl repository contain pregenerated mak files (/ms/*.mak), when it should not. If you check openssl repository you will see that these are set to be ignored. See http://cvs.openssl.org/fileview?f=openssl/ms/.cvsignorev=1.2.4.1 OpenSSL build script are able to detect properly nasm (or nasmw) but if you put the resulted mak files on the SVN it will break the build on other systems (like ones not having `nasmw` binary). There are several solutions for this problem: * (fast) modify mak files to replace nasmw with nasm - this may break the build on same machines that are not using a current version of nasm, or where people renamed the file instead of making a copy or a symlink. * (better but harder) remove the /ms/*.mak files from the repository and assure that the build system is calling the original openssl build scripts (the ones that are able to properly generate the mak files). Initially I considered that this is bug in OpenSSL, but this is not the case: http://rt.openssl.org/index.html?q=2338 -- nosy: +sorin type: - compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
What also worries me is the difference between the class statement and the
type() function.
class M_A(type):
def __new__(mcls, name, bases, ns):
print('M_A.__new__', mcls, name, bases)
return super().__new__(mcls, name, bases, ns)
class M_B(M_A):
def __new__(mcls, name, bases, ns):
print('M_B.__new__', mcls, name, bases)
return super().__new__(mcls, name, bases, ns)
class A(metaclass=M_A): pass
class B(metaclass=M_B): pass
class C(A, B): pass
D = type('D', (A, B), {})
The construction of C and D won't print the same messages.
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294232
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9561] distutils: set encoding to utf-8 for input and output files
Toshio Kuratomi a.bad...@gmail.com added the comment: - RPM spec files, which use ASCII or UTF-8 according to http://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Encoding but it’s not confirmed in http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html (linked from the LSB site) UTF-8 is a superset of ASCII. If you use utf-8 but only write ascii characters, your output file will be written to utf-8... but it will be also encoded to ascii. It's magical :-) I know that, but it does not answer the question: Is it okay for these files to use UTF-8? rpm spec files are encoding agnostic similar to POSIX filesystems. This causes no end of troubles for people writing python code that deals with python of course, as they cannot rely on the bytes that they are dealing with from one package to another to have the same encoding (Remember that things like dependency solvers have to compare the information from multiple packages to make their decisions). Individual distributions will have different policies about encoding and the use of unicode in spec files to try and mitigate the problems. For instance, Fedora specifies utf-8 in the spec files and additionally specifies that package names must be ascii. (So if there's a package name: python-café, we would likely transcribe it as python-cafe when we made a package for it). utf-8 is a good default for locales on POSIX systems so it's a good default for encoding spec files but I know there's some people out there who make their own packages that aren't utf-8. I haven't checked but I also wouldn't be surprised if some Asian countries (where the bytes-per-character with utf-8 is high) have local distributions that use non-utf-8 encoding as well. Whether either of these use cases needs to be catered to in distutils (when the support is going away in distutils2) I'll leave to someone else to decide. My personal gut instinct is no but I'm not one of the people using a non-utf-8 locale. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9841] sysconfig and distutils.sysconfig differ in subtle ways
Tarek Ziadé ziade.ta...@gmail.com added the comment: That's what I wanted to do first but it turned out to be a bad idea. This duplication is unfortunate but the freeze is also to prevent third party code that patches distutils to break. For instance, there's a lot of code out there that just patches distutils.sysconfig paths... So changing it would break them. -- resolution: - wont fix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll check if I can merge in patch 4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9699] invalid call of Windows API _popen() generating The input line is too long error message
sorin sorin.sbar...@gmail.com added the comment: I made a small but important update to quote_command(), now it does quote the command line only under Windows because doing this under other platforms may break the command line. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9323] trace.py bug with the main file being traced
Florent Xicluna florent.xicl...@gmail.com added the comment: I've made the wrong assumption that test.regrtest.__file__ is always absolute. Here is a patch which should fix it. -- nosy: +ezio.melotti Added file: http://bugs.python.org/file18870/issue9323_regrtest.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9846] ZipExtFile provides no mechanism for closing the underlying file object
New submission from John Admanski jadman...@gmail.com: When creating a ZipExtFile through ZipFile.open, the if the original ZipFile object was created with a filename then a new file object will be opened and given to the ZipExtFile to use for its file operations. There is no explicit mechanism that will allow you to release this file. ZipExtFile does have an (undocumented?) close method, but this won't actually close the file object that underlies it; probably because it has no way of knowing if it actually owns the file object or if it just has a reference to a file object that belongs to the ZipFile. You can work around this by destroying references to the ZipExtFile and letting the file's __del__ handle the close for you but this relies on implementation details of ZipExtFile. Found in Python 3.1 but a look at svn.python.org suggests that this problem is still there in 2.7 and 3.2; however, I haven't actually tried it with them. -- components: Library (Lib) messages: 116322 nosy: john.admanski priority: normal severity: normal status: open title: ZipExtFile provides no mechanism for closing the underlying file object type: feature request versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9716] The inittab modules cannot be packages
Brett Cannon br...@python.org added the comment: Both David and Nick are correct as to why I did what I did. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1538778] pyo's are not overwritten by different optimization levels
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
compileall module supports -f (force) option, so you can use:
python3.2 -O -m compileall -f ${files}
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1538778
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1538778] pyo's are not overwritten by different optimization levels
Barry A. Warsaw ba...@python.org added the comment: Uh, duh. Thanks for reminding me about that Arfrever! :) That should be everything Toshio needs I think. Plus this request is 4 years old. Closing as won't fix. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1538778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed with minor changes in r84777. Eli, please keep lines under 80 characters. Leaving the issue open pending py3k port. -- resolution: - accepted stage: patch review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1538778] pyo's are not overwritten by different optimization levels
Toshio Kuratomi a.bad...@gmail.com added the comment: It doesn't fix the problem as it falls into the third class of solutions (one that requires cooperation by the system administrator to diagnose and fix). OTOH, at this point in time I'm putting all of my packages in system packages where the .pyos are pregenerated correctly so I personally won't be getting new bug reports on this problem so I personally don't need to see this fixed anymore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1538778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9846] ZipExtFile provides no mechanism for closing the underlying file object
Antoine Pitrou pit...@free.fr added the comment: Indeed. However, the ZipFile itself knows whether to close the file (self._filePassed). By adding a constructor argument to ZipExtFile and a __del__ method, it would solve the issue. -- nosy: +pitrou stage: - needs patch versions: +Python 3.2 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1397474] timeit execution enviroment
Changes by Eli Bendersky eli...@gmail.com: -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1397474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1397474] timeit execution enviroment
Eli Bendersky eli...@gmail.com added the comment: Terry, I'm attaching a patch for 2.7, however it's more proof-of-concept than final, because I have a few comments. The patch generally implements your documentation suggestion without the `import *` warning and without adding the final example. The latter for a couple of reasons: 1) My tests show that passing the callable instead of the string 'test()' actually takes longer to run. 2) When the callable is passed, the setup of importing 'test' from '__main__' is necessary, because the timed code doesn't have to lookup the 'test' symbol. If you want to leave that example in, the setup string can be ditched. Let me know your thoughts and I will update the patch. -- Added file: http://bugs.python.org/file18871/issue1397474.py27.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1397474 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9847] Binary strings never compare equal to raw/normal strings
New submission from James Hutchison jamesghutchi...@gmail.com: Tested on Python 3.1.2 Windows XP 32-bit Binary strings (such as what is returned by filereader.readline()) are never equal to raw or normal strings, even when both strings are empty if(b == ): print(Strings are equal); else: if(b == r): print(raw and binary equal, normal isn't); else: print(they aren't equal); output: they aren't equal -- components: Interpreter Core messages: 116331 nosy: Jimbofbx priority: normal severity: normal status: open title: Binary strings never compare equal to raw/normal strings type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9844] calling nonexisting function under __INSURE__
Eli Bendersky eli...@gmail.com added the comment: Barry, I've taken the liberty to add you to the nosy list because I found in the logs you've originally added this code (in 2001!!) I hope it's OK with you :-) -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9323] trace.py bug with the main file being traced
Florent Xicluna florent.xicl...@gmail.com added the comment: regrtest fixed with r84776 (3.x) and r84779 (2.7) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Eli, while porting your tests to py3k, I had to change expected output for list comprehension testing. This is not really surprising because 3.x comprehensions differ from 2.x (they don't leak the loop variable anymore). The difference between versions is most pronounced if a comprehension is spread in several lines: l = [i for i in range(10)] The coverage of the above code in 2.x is 1: l = [i for i in 11: range(10)] but in 3.x, I get 12: l = [i for 10: i in 1: range(10)] Not surprisingly, 3.x coverage output for generators is the same as for comprehensions: 12: l = list(i for 10: i in 1: range(10)) but in 2.x, 12: l = list(i for i in 1: range(10)) In any case, I think the counts from the second and third line (10 and 1) are probably correct in 3.x, but I cannot explain 12 in the first line. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1538778] pyo's are not overwritten by different optimization levels
Barry A. Warsaw ba...@python.org added the comment: Thanks Toshio, I get it now. I think pre-generating the proper pyo's is probably the best solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1538778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in: py3k: r84780 release31-maint: r84783 release27-maint: r84777 Need a separate issue for the problem highlighted in msg116336. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue665761] reduce() masks exception
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Since noone have spoken in favor of 2.7 backport, I am closing this issue as committed to py3k. -- keywords: -needs review resolution: - accepted stage: patch review - committed/rejected status: pending - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue665761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Florent Xicluna florent.xicl...@gmail.com added the comment: You probably missed Lib/test/tracedmodules/ in r84780 ;) -- keywords: +buildbot nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9848] setup.py contains needless references to built-in _weakref module
New submission from Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: _weakref module is a built-in module in Python 3 since r58602, but references to _weakref module in setup.py haven't been removed. They can be removed in py3k and 3.1 branches. setup.py in 2.7 branch (since r84233) contains unused, commented out reference to _weakref module, which also can be removed. -- components: Build messages: 116343 nosy: Arfrever, georg.brandl priority: normal severity: normal status: open title: setup.py contains needless references to built-in _weakref module versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Changes by Santoso Wijaya santa@me.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9802] Document 'stability' of builtin min() and max()
Mark Dickinson dicki...@gmail.com added the comment: Of course, there are subtle implications of how it will be implemented Indeed. Ideally, as you mention, the implementation would only use __lt__ (as with sort and bisect). I think that constraint only leaves one reasonable choice: namely, max and min for multiple args would be functionally equivalent to max_list and min_list below: def min2(x, y): return y if y x else x def max2(x, y): return x if y x else y def min_list(xs): return reduce(min2, xs) def max_list(xs): return reduce(max2, xs) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue767645] incorrect os.path.supports_unicode_filenames
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file18841/test_pep277.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue767645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9786] Native TLS support for pthreads
Martin v. Löwis mar...@v.loewis.de added the comment: Perhaps we can simply call Py_FatalError() instead? There's not much we can do when such a failure occurs anyway. Sounds fine as well. Python's own usage definitely shouldn't fail. If extension modules use this in an aggressive manner, they may actually exhaust TLS keys (at least on Windows, where old versions had only 64 slots). Having the interpreter fail then sounds reasonable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Martin v. Löwis mar...@v.loewis.de added the comment: My (I think fairly straightforward) idea is to just compile the useful values in Makefile and config.h into _sysconfig.c and arrange for sysconfig to import that and check it first (fallback to parsing mf and conf.h). You seem to suggest that by doing so, one can actually dispose of pyconfig.h afterwards, as all information is in the module. This is definitely not the case: pyconfig.h continues to be required, as an include that is literally used when compiling extension modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue767645] incorrect os.path.supports_unicode_filenames
STINNER Victor victor.stin...@haypocalc.com added the comment: r84784 sets os.path.supports_unicode_filenames to True on Mac OS X (macpath module). About test_supports_unicode_filenames.patch. test_unicode_listdir() is wrong: os.listdir(str) always return str (see r84701). verify that the new file's name is equal to the name we tried check of test_unicode_filename() is also wrong: newfile.name is always equal to fname, it doesn't depend on support_unicode_filenames. Since the test is wrong, I don't want to commit it. test_pep277 is enough to test the creation of files with unicode names. I don't see anything else to do now, so I close this issue. Reopen it if I forgot something, or open a new issue. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue767645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue767645] incorrect os.path.supports_unicode_filenames
STINNER Victor victor.stin...@haypocalc.com added the comment: I backported r84701 and r84784 to Python 2.7 (r84787). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue767645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9360] nntplib cleanup
R. David Murray rdmur...@bitdance.com added the comment: Assuming we can break backward compatibility, it sounds fine to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9360] nntplib cleanup
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7994] object.__format__ should reject format strings
Eric Smith e...@trueblade.com added the comment: Manually merged to py3k in r84790. I'll leave this open until I create the 3.3 issue to change it to a DeprecationWarning. -- keywords: -needs review versions: -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7994 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: You must be right. I thought I did all the svn adds, but may have missed something. I'll take care of this tonight, but I am off the grid for the next 3-4 hours. On Sep 13, 2010, at 3:13 PM, Florent Xicluna rep...@bugs.python.org wrote: Florent Xicluna florent.xicl...@gmail.com added the comment: You probably missed Lib/test/tracedmodules/ in r84780 ;) -- keywords: +buildbot nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ -- nosy: +Alexander.Belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment: Committed as r84791. Question: should this bugfix be backported to Python 3.1 and to xrange objects in Python 2.7? Since it's a bugfix that adds new methods, it's a gray-area. (same question applies to the closely related Issue #9212) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9840] Recursive Repr
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Committed in r84792. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue767645] incorrect os.path.supports_unicode_filenames
Ned Deily n...@acm.org added the comment: There seems to be some confusion about the macpath.py module. I'm not sure why it even exists in Python 3. Note it has to do with obsolete Classic MacOS-style paths (colon-separated paths) which are available on Mac OS X only through deprecated Carbon interfaces. I'm not even sure that those style paths do support unicode. More importantly, the underlying Carbon interfaces that macpath.py uses were removed for Python 3. AFAIK, virtually nothing on OS X uses these style paths anymore and, with the removal of all the old Mac Carbon support in Python 3, I don't think there is any Python module that can use these paths other than macpath. I think this module should be marked for deprecation and removed. There is no reason to modify it nor add a NEWS note, even for 2.7. -- nosy: +ned.deily, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue767645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9849] Argparse needs better error handling for nargs
New submission from Jason Baker amnorv...@gmail.com:
This is referring to argparse 1.1 installed under Python 2.6. When I was
passing in an nargs flag, I figured that since '+' and '*' are valid options, I
should pass in strings. So when I tried passing in the string '1' instead of
the integer 1, I got the following error:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs='1')
_StoreAction(option_strings=[], dest='foo', nargs='1', const=None,
default=None, type=None, choices=None, help=None, metavar=None)
parser.parse_args()
Traceback (most recent call last):
File stdin, line 1, in module
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 1698, in
parse_args
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 1730, in
parse_known_args
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 1935, in
_parse_known_args
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 1884, in
consume_positionals
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 2028, in
_match_arguments_partial
File build/bdist.macosx-10.6-universal/egg/argparse.py, line 2169, in
_get_nargs_pattern
TypeError: can't multiply sequence by non-int of type 'str'
Fortunately, I had just added the nargs and knew to correct that. However, if
I were to do something like read that value in from a config file and forget to
coerce the value from a string to an int, I could see how this could be a giant
pain to track down.
--
components: Library (Lib)
messages: 116355
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Argparse needs better error handling for nargs
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9849
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9846] ZipExtFile provides no mechanism for closing the underlying file object
John Admanski jadman...@gmail.com added the comment: I'm not sure that's much of an improvement on the existing behavior, though; as I mentioned you can already work around it by killing all the references to the ZipExtFile and the underlying file object will get automatically closed if the ZipExtFile is the only object using it, so adding an explicit __del__ that does the same thing isn't much of an improvement. Since ZipExtFile is supposed to be a file-like object (albeit a read-only one) it would make sense to be able to release the underlying resources the same way you normally do with a file...by closing it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9849] Argparse needs better error handling for nargs
Ned Deily n...@acm.org added the comment: Note, argparse is not part of the Python standard library in 2.6 but the 2.7 and 3.2 versions exhibit the same behavior. -- assignee: - bethard nosy: +bethard, ned.deily versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9849 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: You probably missed Lib/test/tracedmodules/ fixed in r84794. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9810] bzip2 build sometimes fails (VS8.0)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I propose following solution. * svn copy http://svn.python.org/projects/external/bzip2-1.0.5 http://svn.python.org/projects/external/bzip2-1.0.5.0 * fix makefile in http://svn.python.org/projects/external/bzip2-1.0.5 * svn copy http://svn.python.org/projects/external/bzip2-1.0.5 http://svn.python.org/projects/external/bzip2-1.0.5.1 Or, use nmake /nologo /f makefile.msc instead of nmake /nologo /f makefile.msc lib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9815] test_tarfile sometimes ends with error Cannot remove dir
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I tried test_tar_pipe_open_read_error_v2.py on py3k, I saw 3 uncollectable objects are reported. But they are *collected* by gc.collect() without gc.set_debug(gc.DEBUG_LEAK). (I'm not familiar to gc, so maybe this is normal) I didn't see uncollectable objects in release27-maint and release31-maint. And I replaced py3k's Lib/unittest with release31-maint's one, the error was gone. Maybe problem is in Lib/unittest. Actually, if I run the code in test_null_tarfile without unittest, everything runs fine. E:\python-devpy3k test_tar_pipe_open_read_error_v2.py . -- Ran 1 test in 0.050s OK === gc: collectable cell 00C4F968 gc: collectable tuple 00BF1968 gc: collectable function 00C53C98 gc: collectable tuple 00BF5C78 gc: collectable function 00C53CF8 gc: collectable tuple 00BF99A0 gc: collectable function 00C53D58 gc: collectable tuple 00C2D8C0 gc: collectable function 00C53DB8 gc: collectable tuple 00C37348 gc: collectable function 00C53E18 gc: collectable tuple 00C37460 gc: collectable function 00C53E78 gc: collectable tuple 00C37540 gc: collectable function 00C53ED8 gc: collectable function 00C53F38 gc: collectable type 00C73CE0 gc: collectable dict 00C4DD58 gc: collectable getset_descriptor 00C52AB8 gc: collectable getset_descriptor 00C52AF8 gc: collectable tuple 00AF7778 gc: collectable frame 00C28D70 gc: collectable method 00AE6278 gc: collectable frame 00C299A8 gc: collectable tuple 00BD4498 gc: collectable frame 00C29B50 gc: collectable frame 00C29CF8 gc: collectable frame 00C753A0 gc: collectable frame 00C75F40 gc: collectable tuple 00C375E8 gc: collectable frame 00C760E8 gc: collectable method 00C52B38 gc: collectable frame 00C766C8 gc: collectable _io.FileIO 00C52D38 gc: collectable _io.BufferedWriter 00BF0758 gc: collectable frame 00C78F80 gc: collectable tuple 00AEB9F8 gc: collectable _AssertRaisesContext 00C4FAF0 gc: collectable dict 00C554D0 gc: collectable frame 00C79328 gc: collectable TarFile 00C4FB98 gc: collectable frame 00C89390 gc: collectable dict 00C55770 gc: collectable list 00AEF978 gc: collectable frame 00C89780 gc: collectable frame 00C8A040 gc: collectable frame 00C89CC0 gc: collectable frame 00C89E70 gc: collectable traceback 00C56038 gc: collectable tuple 00C4F850 gc: collectable IOError 00C508F8 gc: collectable tuple 00C4FC08 gc: collectable ReadError 00C4CC50 gc: collectable method 00AE6338 gc: collectable tuple 00BF5150 gc: collectable tuple_iterator 00C4FA80 gc: collectable map 00C4FAB8 gc: collectable list 00AFAD38 gc: uncollectable _Stream 00C4FB28 gc: uncollectable dict 00C55620 gc: uncollectable _LowLevelFile 00C4FB60 === Traceback (most recent call last): File test_tar_pipe_open_read_error_v2.py, line 25, in test_main unittest.main() File e:\python-dev\py3k\lib\unittest\main.py, line 95, in __init__ self.runTests() File e:\python-dev\py3k\lib\unittest\main.py, line 231, in runTests sys.exit(not self.result.wasSuccessful()) SystemExit: False During handling of the above exception, another exception occurred: Traceback (most recent call last): File test_tar_pipe_open_read_error_v2.py, line 33, in module test_main() File test_tar_pipe_open_read_error_v2.py, line 30, in test_main shutil.rmtree(TEMPDIR) File e:\python-dev\py3k\lib\shutil.py, line 283, in rmtree onerror(os.remove, fullname, sys.exc_info()) File e:\python-dev\py3k\lib\shutil.py, line 281, in rmtree os.remove(fullname) WindowsError: [Error 32] プロセスはファイルにアクセスできません。別のプロセスが 使用中です。: 'c:\\docume~1\\ocean\\locals~1\\temp\\__foobarbaz__\\tmp.tar' gc: 61 uncollectable objects at shutdown: [54634 refs] -- versions: +Python 3.1 Added file: http://bugs.python.org/file18873/test_tar_pipe_open_read_error_v2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9815 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9846] ZipExtFile provides no mechanism for closing the underlying file object
R. David Murray rdmur...@bitdance.com added the comment: Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method? (And document it, of course). -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9810] bzip2 build sometimes fails (VS8.0)
Martin v. Löwis mar...@v.loewis.de added the comment: Another solution would be not to make clean, but del *.obj. However, I would prefer if we stopped using makefile.msc altogether, and explicitly included the source files of bzip2 into bz2.vcproj, similar to the way _bsddb is built (in 2.7). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9850] obsolete macpath module dangerously broken and should be removed
New submission from Ned Deily n...@acm.org:
The macpath module in the standard library purports to supply the Mac OS 9
(and earlier) implementation of the os.path module. It can be used to
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).
The following functions are available in this module: normcase(), normpath(),
isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other
functions available in os.path dummy counterparts are available.
Old-style Mac pathnames are not further documented - in fact, the above quote
is the entire external documentation for the module - but they are ones using
colon separators, like (MacHD:Users:nad:macpath_test:file). These style path
names were initially supported on Mac OS X by compatibility APIs for programs
ported from classic Mac OS but those interfaces have long been deprecated in OS
X and in most cases are not available in 64-bit execution mode.
Even if one did have a need to use the obsolete old-style paths, the macpath
module is currently practically unusable for anything other than simple
character manipulations of the path. Nearly all of the functions that actually
call OS routines are broken in one or more ways.
Those that do make file system calls are calling APIs that are expecting normal
posix-style ('/' separated paths) incorrectly with old-style (:) paths
(ispath, isdir, lexists, etc) which means they only give correct results in the
trivial case of unqualified file or directory names, i.e. those in the working
directory.
The islink() function confusingly is testing whether a path points to a Finder
Alias file (not a symlink). Unfortunately, the Carbon API used for that test
does not exist in a 64-bit version and all of the Python Carbon modules were
removed in Python 3.
$ arch -i386 python2.7 -c 'import macpath;
print(macpath.islink(alias_to_file))'
1
$ arch -x86_64 python2.7 -c 'import macpath;
print(macpath.islink(alias_to_file))'
False
$ python3.2 -c 'import macpath; print(macpath.islink(alias_to_file))'
False
The underlying import errors are being masked by try's:
$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File string, line 1, in module
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.1 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named Carbon.File
The realpath function is also broken in 2.7, calling
Carbon.File.FSResolveAliasFile with a : separated path when it expects a /
path, and is totally broken in 3.x (no Carbon modules).
While ospath *could* be repaired by proper documentation, fixing the mishmash
of path types internally, and supplying C wrappers and/or alternative 64-bit
APIs, it does not seem worth the effort as these style paths are seldom
encountered in modern code. Considering how broken the module currently is and
given that it probably was simply overlooked in the Python 2 to 3 transition, I
think a case could be made for immediate removal prior to Python 3.2 release
and even for a 3.1.x maintenance release. Short of that, it should be cleared
documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken
functionality along with added DeprecationWarnings to the module.
I can write up patches to do that depending on what the consensus is.
--
assignee: ronaldoussoren
components: Macintosh
messages: 116365
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: obsolete macpath module dangerously broken and should be removed
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9850
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9850] obsolete macpath module dangerously broken and should be removed
Ned Deily n...@acm.org added the comment:
The macpath module in the standard library purports to supply the Mac OS 9
(and earlier) implementation of the os.path module. It can be used to
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).
The following functions are available in this module: normcase(), normpath(),
isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other
functions available in os.path dummy counterparts are available.
Old-style Mac pathnames are not further documented - in fact, the above quote
is the entire external documentation for the module - but they are ones using
colon separators, like (MacHD:Users:nad:macpath_test:file). These style path
names were initially supported on Mac OS X by compatibility APIs for programs
ported from classic Mac OS but those interfaces have long been deprecated in OS
X and in most cases are not available in 64-bit execution mode.
Even if one did have a need to use the obsolete old-style paths, the macpath
module is currently practically unusable for anything other than simple
character manipulations of the path. Nearly all of the functions that actually
call OS routines are broken in one or more ways.
Those that do make file system calls are calling APIs that are expecting normal
posix-style ('/' separated paths) incorrectly with old-style (:) paths
(ispath, isdir, lexists, etc) which means they only give correct results in the
trivial case of unqualified file or directory names, i.e. those in the working
directory.
The islink() function confusingly is testing whether a path points to a Finder
Alias file (not a symlink). Unfortunately, the Carbon API used for that test
does not exist in a 64-bit version and all of the Python Carbon modules were
removed in Python 3.
$ arch -i386 python2.7 -c 'import macpath;
print(macpath.islink(alias_to_file))'
1
$ arch -x86_64 python2.7 -c 'import macpath;
print(macpath.islink(alias_to_file))'
False
$ python3.2 -c 'import macpath; print(macpath.islink(alias_to_file))'
False
The underlying import errors are being masked by try's:
$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File string, line 1, in module
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.2 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
File string, line 1, in module
ImportError: No module named Carbon.File
The realpath function is also broken in 2.7, calling
Carbon.File.FSResolveAliasFile with a : separated path when it expects a /
path, and is totally broken in 3.x (no Carbon modules).
While macpath *could* be repaired by proper documentation, fixing the mishmash
of path types internally, and supplying C wrappers and/or alternative 64-bit
APIs, it does not seem worth the effort as these style paths are seldom
encountered in modern code. Considering how broken the module currently is and
given that it probably was simply overlooked in the Python 2 to 3 transition, I
think a case could be made for immediate removal prior to Python 3.2 release
and even for a 3.1.x maintenance release. Short of that, it should be cleared
documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken
functionality along with added DeprecationWarnings to the module.
I can write up patches to do that depending on what the consensus is.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9850
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
