[issue13246] Py_UCS4_strlen and friends needn't be public
STINNER Victor victor.stin...@haypocalc.com added the comment: It seems there's no reason to document these functions which operate on null-terminated unicode arrays. It's the easiest way to create a new string with the new Unicode API, when it's difficult to predict the exact output length and maximum character: Py_UCS4 *buffer = PyMem_Malloc(...); ... str = PyUnicode_FromKindAndBuffer(buffer, PyUnicode_4BYTE_KIND); PyMem_Free(buffer); PyUCS4_* functions are useful in the ... (to write characters, expecially when you manipulate multiple strings). For examples, see Python/import.c which used char*, then Py_UNICODE* and now Py_UCS4*. It's maybe possible to avoid functions like xxx_strlen(), but it was easier to replace str*() functions by Py_UNICODE_* and then PyUCS4_* functions. -- Py_UNICODE_* and PyUCS4_* functions are not part of the stable API. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13246 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13247] os.path.abspath returns unicode paths as question marks
STINNER Victor victor.stin...@haypocalc.com added the comment: abspath() is implemented using nt._getfullpathname() which calls GetFullPathNameA(). The returned path with question marks is completely useless. Can you open the file using such filename? If no, I agree that the result is useless. It's better that python throw an error than return the question marks. Python is currently a thin wrapper on the Windows API. Windows doesn't consider that a filename with question marks as an error. http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963%28v=vs.85%29.aspx Python can maybe uses GetFullPathNameW() and encode manually the filename using its strict MBCS codec. MBCS codec is strict since Python 3.2: it raises a UnicodeEncodeError if the string cannot be encoded. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Oleg Plakhotnyuk oleg...@gmail.com added the comment: Thank you all for help. I finally managed to build it. :-) So here are complete steps I've taken to build python after OS reinstall: 1. Install XCode 4.2 2. Install MacPorts 3. sudo port -v selfupdate 4. sudo port install gcc46 5. ./configure CC=gcc-mp-4.6 LDFLAGS=-L/opt/local/lib --with-pydebug make -j2 Should I post this somewhere for others who may face similar problems? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Changes by Oleg Plakhotnyuk oleg...@gmail.com: -- resolution: - works for me ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Changes by Oleg Plakhotnyuk oleg...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Changes by Oleg Plakhotnyuk oleg...@gmail.com: -- resolution: works for me - fixed status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Changes by Oleg Plakhotnyuk oleg...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13105] Please elaborate on how 2.x and 3.x are different heads
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0541f815d016 by Nick Coghlan in branch 'default': Update NEWS entry policy based on recent mailing list discussion and forward porting section based on Issue 13105 http://hg.python.org/devguide/rev/0541f815d016 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13105 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13105] Please elaborate on how 2.x and 3.x are different heads
Nick Coghlan ncogh...@gmail.com added the comment: The devguide actually did align with what I said in my email, but this wasn't clear if you only read the Forward Porting section (you had to read the Porting Between Major Versions section further down the page as well). I added a new paragraph to the forward porting section so it describes the whole policy, leaving the following two sections to cover the mechanics of actually handling that with Mercurial. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13105 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
Charles-François Natali neolo...@free.fr added the comment: The recent issue #13146 renewed my interest, so I'd like to make this move forward, since I think an atomic rename/write API could be quite useful. Issue #8604 (Adding an atomic FS write API) can be achieved relatively easily with the typical (fsync() left aside) - create temporary file - write to the temp file - atomically rename the temp file to the target path But the problem is that rename is only atomic on POSIX, and not on Windows. So I'd suggest to: - rename this issue to target specifically Windows ;-) - add MoveFileTransacted to the standard library (PC/msvcrtmodule.c, posixmodule?) I'm -1 on exposing a best effort atomic rename/file API: either the OS offers the primitives necessary to achieve atomicity, or it doesn't. It's better to have a working implementation on some OSes than a flaky implementation on every OS. Note that I'll happily take over the atomic file API part (issue #8604), but since my Windows kung-fu is so poor, it'd be nice if someone with some Windows experience could tackle this MoveFileTransacted -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13140] ThreadingMixIn.daemon_threads is not honored when parent is daemon
Charles-François Natali neolo...@free.fr added the comment: I would prefer to preserve the inheritance by default, and to change the daemonic attribute only if it is explicitly set to True or False. This way it will be backward compatible. It may be backward compatible, but IMHO, the current behavior is broken: while it can certainly make sense to set the server thread daemonic, you most certainly don't want to have client threads daemonic implicitely (since you usually don't want to terminate the client's connections abruptly when the main thread exits). But I must admit I don't have a strong opinion, so both solutions are OK to me. The only thing that bothers me is this: +.. versionchanged:: 3.3 + previously, the *daemon_threads = False* flag was ignored. You usually document new features or behavior changes: this really looks like a bug fix (and is one actually). Something like the semantics of *daemon_threads* changed slighty might be better (but I'm no native speaker). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13217] Missing header dependencies in Makefile
Changes by Petri Lehtinen pe...@digip.org: -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13217 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Martin v. Löwis mar...@v.loewis.de added the comment: Maybe we should change the build system to always regenerate the files or add something to automation that regenerates the AST C file every time. Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13246] Py_UCS4_strlen and friends needn't be public
Martin v. Löwis mar...@v.loewis.de added the comment: Before the release, we should consider whether we can drop these functions altogether. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13246 ___ ___ 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
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c2a89b509be4 by Nick Coghlan in branch '3.2': Issue 1294232: Fix errors in metaclass calculation affecting some cases of metaclass inheritance. Patch by Daniel Urban. http://hg.python.org/cpython/rev/c2a89b509be4 New changeset c72063032a7a by Nick Coghlan in branch 'default': Merge issue 1294232 patch from 3.2 http://hg.python.org/cpython/rev/c72063032a7a -- nosy: +python-dev ___ 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
[issue13246] Py_UCS4_strlen and friends needn't be public
Georg Brandl ge...@python.org added the comment: Making sure we don't forget that :) -- priority: normal - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13246 ___ ___ 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
Nick Coghlan ncogh...@gmail.com added the comment: Fix has been applied to 3.x and hence will be in 3.3 and the next 3.2 release. I have adjusted the issue metadata to reflect the fact 2,7 still exhibits the problem, but the patch requires significant work to account for the 3.x vs 2.x changes in class creation before it can be backported. -- components: -Documentation stage: patch review - needs patch versions: -Python 3.1, Python 3.2, Python 3.3 ___ 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
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Ned Deily n...@acm.org added the comment: In general, I would not recommend using anything other than an Apple-supplied tool chain for building anything on Mac OS X. To help us better understand the issues, can you say exactly which compilers you tried originally, i.e. the complete --version output from the compiler(s) used in your failing Python builds? Because of the current somewhat chaotic OS X compiler situation, I am in the process of performing a controlled test of building and testing various current versions of Python with the available Xcode compilers for 10.7 and 10.6. -- assignee: - ned.deily components: +Macintosh priority: normal - high resolution: fixed - status: pending - open type: compile error - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
Oleg Plakhotnyuk oleg...@gmail.com added the comment: Ah, of course. Initially I've tried to compile using this: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) XCode version 4.2, build 4C199 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13240] sysconfig gives misleading results for USE_COMPUTED_GOTOS
Meador Inge mead...@gmail.com added the comment: Actually, I think sysconfig does the right thing when it comes to all the configure-generated HAVE_XXX variables I agree. The 'configure' script could be improved, though. If we truly want to enable this by default, then the defaulting should be moved to configure. This will give a more accurate portrayal in sysconfig. Also, we can do the USE but !HAVE check in configure, which is better anyway because the error is caught earlier. I am thinking something like the attached. Thoughts? P.S. We could probably get rid of the HAVE macro all together by doing all the work in the 'configure' script. -- keywords: +patch nosy: +meador.inge Added file: http://bugs.python.org/file23503/issue13240.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13248] deprecated in 3.2, should be removed in 3.3
New submission from Florent Xicluna florent.xicl...@gmail.com:
The PEP 387 suggests that deprecated objects or arguments are removed in
version (n+1).
I've listed these DeprecationWarnings in 3.2, which are still in 3.3.
I assume that most of these deprecated objects or arguments could be removed
before next release.
*_pyio*
argument max_buffer_size of BufferedWriter and BufferedRWPair
*argparse*
argument version and related methods of ArgumentParser
*asyncore*
shortcut dispatcher.* for dispatcher.socket.* attributes
*base64*
functions encodestring and decodestring
*cgi*
functions parse_qs and parse_qsl
*configparser*
ParsingError.filename, RawConfigParser.readfp, SafeConfigParser
*decimal*
Context._clamp
*difflib*
SequenceMatcher.isbjunk, SequenceMatcher.isbpopular
*gzip*
GzipFile.filename
*http.client*
argument strict of HTTPResponse and HTTPConnection
*lib2to3*
methods set_prefix and get_prefix of pytree.Base
*mailbox*
argument of type StringIO or text mode files
*ntpath*
function splitunc
*tarfile*
argument exclude of TarFile.add
*trace*
old API
*unittest*
assert{DictContainsSubset,RaisesRegexp,RegexpMatches}, fail*
*xml.etree*
Element.getchildren, XMLParser.doctype
--
components: Library (Lib)
messages: 146236
nosy: flox
priority: normal
severity: normal
status: open
title: deprecated in 3.2, should be removed in 3.3
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13248
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13248] deprecated in 3.2, should be removed in 3.3
Florent Xicluna florent.xicl...@gmail.com added the comment: In addition, we have some object and attributes which are triggering PendingDeprecationWarning in 3.2. We may keep these warnings in 3.3, or choose to turn some of them into DeprecationWarning, to prepare their removal in 3.5. *cgi* cgi.escape *distutils argument compress=compress of make_tarball function check_metadata in command.register option force-manifest of command.sdist *importlib* abc.PyLoader and abc.PyPycLoader *nntplib* _NNTPBase.xgtitle and _NNTPBase.xpath *smtpd* the class-private __* attributes *xml.etree* method getiterator of Element and ElementTree -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Meador Inge mead...@gmail.com added the comment: Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not. OK, thanks for the background. To be clear, though, the build dependency is already there. You just have to touch the ASDL sources to run into it (Lib/opcode.py as well). This is even documented in the Makefile*: # XXX Note that a build now requires Python exist before the build starts ASDLGEN= $(srcdir)/Parser/asdl_c.py However, modifying the ASDL source is, with respect to other source modifications, not as common. So, I see no reason to make the situation worse by running asd_c.py all the time. Suggestion withdrawn. * If not relying on an external Python is a hard requirement (and I do see why that may be useful), then the build system could be changed to only allow changes to problematic sources (ASDL, opcode.py) after Python has been built once. Then the built Python could be used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
New submission from Roy Smith r...@panix.com: The docs list the arguments in the order: class argparse.ArgumentParser([description][, epilog][, prog]... but the code (I'm looking at the 2.7.2 source) lists them as: class ArgumentParser(_AttributeHolder, _ActionsContainer): [...] def __init__(self, prog=None, usage=None, description=None, [...] If you create a parser with just: parser = argparse.ArgumentParser(foo) you end up setting the 'prog' argument instead of the expected 'description'. It's unclear if the order in the code should be fixed to match the docs, or the order in the docs fixed to match the code, or just a note added to the docs saying you should not rely on positional argument ordering and always create a parser with named arguments. -- components: Library (Lib) messages: 146238 nosy: roysmith priority: normal severity: normal status: open title: argparse.ArgumentParser() lists arguments in the wrong order type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X
STINNER Victor victor.stin...@haypocalc.com added the comment: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Oh, that's not GCC but llvm-gcc. It is maybe a bug in LLVM? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Florent Xicluna florent.xicl...@gmail.com added the comment: in 3.x, same issue. IMHO documentation should be fixed. -- assignee: - docs@python components: +Documentation nosy: +bethard, docs@python, flox stage: - needs patch versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
New submission from Meador Inge mead...@gmail.com: While implementing a patch for issue13096 I found a reference leak in 'ctypes'. I couldn't find the cause immediately, but it can be reproduced by applying the attached patch and running: [meadori@motherbrain cpython]$ ./python -m test -R : test_ctypes [1/1] test_ctypes beginning 9 repetitions 123456789 . test_ctypes leaked [51, 51, 51, 51] references, sum=204 1 test failed: test_ctypes [174347 refs] -- components: ctypes files: ctypes-refleak-repro.patch keywords: patch messages: 146242 nosy: amaury.forgeotdarc, belopolsky, meador.inge priority: normal severity: normal stage: needs patch status: open title: ctypes: reference leak in POINTER code type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file23504/ctypes-refleak-repro.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
Benjamin Peterson benja...@python.org added the comment: The cause is ctypes caches POINTER types. You have to make sure to clear the cache. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Mark Dickinson dicki...@gmail.com added the comment: In most cases, global variables Py_Zero and Py_One would be enough to simplify this kind of code. Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Changes by Mark Dickinson dicki...@gmail.com: -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13201] Implement comparison operators for range objects
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 479a7dd1ea6a by Mark Dickinson in branch 'default': Issue #13201: equality for range objects is now based on equality of the underlying sequences. Thanks Sven Marnach for the patch. http://hg.python.org/cpython/rev/479a7dd1ea6a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Petri Lehtinen pe...@digip.org added the comment: Fixing the documentation is better, as changing the argument order would break existing code. -- keywords: +easy nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10925] Document pure Python version of integer-to-float correctly-rounded conversion
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 117d51d3dd7d by Mark Dickinson in branch 'default': Issue #10925: Add equivalent pure Python code for the builtin int-to-float conversion to test_long. http://hg.python.org/cpython/rev/117d51d3dd7d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10925] Document pure Python version of integer-to-float correctly-rounded conversion
Changes by Mark Dickinson dicki...@gmail.com: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Terry J. Reedy tjre...@udel.edu added the comment: In the doc, the signature line is followed by a list of short descriptions in a third order. That perhaps should be changed to follow the same corrected order as the signature line. On the other hand, it matches the order of the detail sections that follow. On the third hand, that current order is confusing as it intermixes parameters that affect the help message behavior with those that affect the actual argument parsing behavior. I think these should be separated with one group following the other. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9980] str(float) failure
Mark Dickinson dicki...@gmail.com added the comment: Closing as won't fix, for reasons given above. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith r...@panix.com added the comment: An Nth place is in the docstring: Keyword Arguments: - prog -- The name of the program (default: sys.argv[0]) - usage -- A usage message (default: auto-generated from arguments) - description -- A description of what the program does - epilog -- Text following the argument descriptions - parents -- Parsers whose arguments should be copied into this one - formatter_class -- HelpFormatter class for printing help messages - prefix_chars -- Characters that prefix optional arguments - fromfile_prefix_chars -- Characters that prefix files containing additional arguments - argument_default -- The default value for all arguments - conflict_handler -- String indicating how to handle conflicts - add_help -- Add a -h/-help option which omits 'version'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12965] longobject: documentation improvements
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset d4839fea4a5a by Mark Dickinson in branch 'default': Issue #12965: Fix some inaccurate comments in Objects/longobject.c. Thanks Stefan Krah. http://hg.python.org/cpython/rev/d4839fea4a5a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12965] longobject: documentation improvements
Mark Dickinson dicki...@gmail.com added the comment: I've fixed some of the inaccurate comments in Objects/longobject.c, for the default branch; I'm still looking at the Doc update. This really is a bit of a mess, especially for cases like PyLong_AsVoidPtr, which can either end up calling PyLong_As(Long)Long (which allows conversion via __int__), or PyLong_AsUnsigned(Long)Long (which doesn't). Ultimately, I think it would make sense to remove all __int__ conversions from Objects/longobject.c; this would affect: - PyLong_AsLongAndOverflow - PyLong_AsLong - PyLong_AsUnsignedLongMask and the 'LongLong' variants of these. The ramifications of such a change might be quite long-reaching; in particular, I seem to recall that this would affect the 'getargs' machinery. It could be fun to remove these conversions and see how much of the test-suite fails. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12965] longobject: documentation improvements
Mark Dickinson dicki...@gmail.com added the comment: It could be fun to remove these conversions and see how much of the test-suite fails. :-) ... On my machine, just test_ctypes and test_getargs2, as it turns out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith r...@panix.com added the comment: I'm working on a doc patch now... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13141] get rid of old threading API in the examples
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset d34beaaf7060 by Florent Xicluna in branch '3.2': Issue 13141: Demonstrate recommended style for socketserver examples. http://hg.python.org/cpython/rev/d34beaaf7060 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13141] get rid of old threading API in the examples
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8de472fb8cfe by Florent Xicluna in branch '2.7': Issue #13141: Demonstrate recommended style for SocketServer examples. http://hg.python.org/cpython/rev/8de472fb8cfe -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13141] get rid of old threading API in the examples
Changes by Florent Xicluna florent.xicl...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith r...@panix.com added the comment: Patch attached. I just deal with putting all the items into the same order, not terry.reedy's idea for separating them into two groups. Added a recommendation to only use keywords, which seems sane given the number of arguments. -- keywords: +patch Added file: http://bugs.python.org/file23505/Issue13249.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith r...@panix.com added the comment: PS -- this is against the 2.7 branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13248] deprecated in 3.2, should be removed in 3.3
Ezio Melotti ezio.melo...@gmail.com added the comment:
*unittest*
assert{DictContainsSubset,RaisesRegexp,RegexpMatches}, fail*
The fail* should stay.
The general idea is that with Python3 we can wait a bit more before getting rid
of things, because if someone jumps from 2.7 to 3.3, he might not find things
that got deprecated in 3.2 and disappeared on 3.3.
That said, some of the more obscure functions/method/attributes can probably go.
Also I think that PendingDeprecations are now quite useless, since
DeprecationWarnings are silenced by default. I think we can convert them to
DeprecationWarnings, even if we leave them there for a couple of versions.
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13248
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13243] _Py_identifier should be _Py_IDENTIFER
Martin v. Löwis mar...@v.loewis.de added the comment: Am 23.10.2011 20:33, schrieb Meador Inge: Meador Inge mead...@gmail.com added the comment: Most definitely not. It is very deliberate that asdl_c.py is only invoked when the ASDL sources change. Otherwise, having Python installed would be a build requirement for Python, which it must be not. OK, thanks for the background. To be clear, though, the build dependency is already there. You just have to touch the ASDL sources to run into it (Lib/opcode.py as well). This is even documented in the Makefile*: Just to be more clear: normally, generated files shouldn't be checked into the source repository. However, exceptions are typically made for generated files that may be difficult to regenerate on some target systems. For Python, this includes configure (depends on autoconf being run), and various files generated from Python scripts (also including the Unicode database, for example). So when we check in generated files, the build dependency becomes unused unless the source file gets modified - which, as you point out, happens rarely, and never happens for somebody who just wants to build Python. * If not relying on an external Python is a hard requirement (and I do see why that may be useful), then the build system could be changed to only allow changes to problematic sources (ASDL, opcode.py) after Python has been built once. Then the built Python could be used. See above. It's fine to require core contributors to have Python installed (and also autoconf). We just need to make sure that Python is not required on the target system (as people may try to install Python initially on that system). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
Martin v. Löwis mar...@v.loewis.de added the comment: So it's not a bug at all, right? -- nosy: +loewis resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13251] Update string description in datamodel.rst
New submission from Ezio Melotti ezio.melo...@gmail.com: The attached patch updates the definition of String after PEP 393. -- assignee: ezio.melotti components: Documentation, Unicode files: issue13251.diff keywords: needs review, patch messages: 146262 nosy: eric.araujo, ezio.melotti, haypo, lemburg, loewis priority: normal severity: normal stage: patch review status: open title: Update string description in datamodel.rst versions: Python 3.3 Added file: http://bugs.python.org/file23506/issue13251.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13252] new decumulate() function in itertools module
New submission from Carlo Verre carlo.ve...@gmail.com: After in Python 3.2 the accumulate() function has been added to itertools module, for self-evident reasons of completeness and symmetry we could add in 3.3 the inverse decumulate() function, which, given the iterable argument p, yields p[0], p[1] - p[0], p[2] - p[1]... Its equivalent python form is in the attached file decumulate.py, below. -- components: Extension Modules files: decumulate.py messages: 146263 nosy: carlo.verre, rhettinger priority: normal severity: normal status: open title: new decumulate() function in itertools module type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23507/decumulate.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13252 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13251] Update string description in datamodel.rst
Ezio Melotti ezio.melo...@gmail.com added the comment: New patch that doesn't mention surrogates, as suggested by Antoine. -- Added file: http://bugs.python.org/file23508/issue13251-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13251] Update string description in datamodel.rst
Martin v. Löwis mar...@v.loewis.de added the comment: LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13251 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13250] ctypes: reference leak in POINTER code
Meador Inge mead...@gmail.com added the comment: Ah, I see now. Thanks Benjamin. So it's not a bug at all, right? A bug in regrtest.py maybe. 'dash_R_cleanup' clears various other caches in between test runs to avoid false positives like this. Perhaps 'ctypes._pointer_type_cache' should be cleared there as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13215] multiprocessing Manager.connect() aggressively retries refused connections
Antoine Pitrou pit...@free.fr added the comment: I'm not sure, but I think that would be for the case where you are spawning the server yourself and the child process takes time to start up. -- nosy: +neologix, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10332] Multiprocessing maxtasksperchild results in hang
Antoine Pitrou pit...@free.fr added the comment: The patch looks good to me, thanks. -- versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10332 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13228] Add Quick Start section to the devguide index
Ezio Melotti ezio.melo...@gmail.com added the comment: That's a good point, but I find the wording a bit long. The attached patch tries to keep it short and adds a link to the section that explains when and why it's python.exe. -- Added file: http://bugs.python.org/file23509/issue13228-3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13228] Add Quick Start section to the devguide index
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 25f1c003ea01 by Ezio Melotti in branch 'default': #13228: add a Quick Start section to the index page. http://hg.python.org/devguide/rev/25f1c003ea01 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13228] Add Quick Start section to the devguide index
Ezio Melotti ezio.melo...@gmail.com added the comment: Done, thanks for the feedback! -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13141] get rid of old threading API in the examples
Antoine Pitrou pit...@free.fr added the comment: Should be closed, no? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
Antoine Pitrou pit...@free.fr added the comment: MoveFileTransacted is only available under Vista or later. You should be able to use MoveFileEx for the same effect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
Antoine Pitrou pit...@free.fr added the comment: The solution? Let's remember that metadata changes are atomic. Rename is such a case. This is from a MSDN blog, I would hope he knows what he's talking about. http://blogs.msdn.com/b/adioltean/archive/2005/12/28/507866.aspx (MoveFileEx appears in Windows XP, which is fine: in Python 3.3, Windows 2000 and Windows platforms which set COMSPEC to command.com are no longer supported due to maintenance burden) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9239] zipfile: truncating comment can corrupt the zipfile
Changes by Antoine Pitrou pit...@free.fr: -- stage: - patch review type: performance - behavior versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
Antoine Pitrou pit...@free.fr added the comment: Closing as outdated. There are no freelists anymore in the unicode implementation. -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10363] Embedded python, handle (memory) leak
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pitrou versions: +Python 3.2, Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10363 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11447] test_pydoc refleak
Antoine Pitrou pit...@free.fr added the comment: I can't reproduce anymore. I believe this may have been due to the fact that pydoc can try to import everything on sys.path, including third-party libraries. I got bitten by that on another issue. -- resolution: - invalid stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Meador Inge mead...@gmail.com added the comment: Nick, the revised definition of 'getclosurevars' seems reasonable to me. I will cut a new patch this week. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
