[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Ezio Melotti added the comment: We discussed about this on IRC, and I'll try to summarize the outcomes. If we want devs to run doctests, the syntax should be as simple as possible, ideally there shouldn't be any extra syntax -- at least for the common case. Note that there are two kind of doctests: * the ones in the *.rst files in the Doc dir; * the ones in the docstrings of the *.py files in the Lib dir; Some of the use cases are: 1) being able to run all the doctests at once; 2) being able to run individual doctests files; 3) being able to discover/run doctests in a specified dir; The use case 1) likely needs an extra flag (e.g. --docall), and could be done by default with -uall. The use case 2) can be already done with `./python -m doctest path/to/doctest.rst`, but, if doctest support is added to regrtest, it would be nice to have this too. The following issues were discussed: * should regrtest accept them with no extra syntax (e.g. `./python -m test path/to/doctest.rst` -- this would be nice but probably tricky/hackish) or should they marked somehow (e.g. `fdoc:path/to/doctest.rst`, or `--doctests path/to/doctest1.rst path/to/doctest2.rst`)? * should we use paths (e.g. Doc/library/textwrap.rst -- easier) or dotted names (e.g. Doc.library.textwrap -- more consistent with unittests)? * should we require the full path/name, or just the filename like we do with regular unittests (e.g. `-m test test_textwrap`)? * should we use the fact that Doc/Lib or rst/py are in the name to distinguish the doctests, or can we search for the name in Lib/test/ first, and fallback on Doc/ and Lib/ if it's not there? The use case 3) is less common, it can be provided with an additional flag but it's not strictly necessary IMHO (might be handy when we want to run all the doctests in a package). Other issues that we haven't discussed are: * it would be nice to have something like run_doctests(['path/to/doctest.rst', 'path/to/module.py']) to be added in the test_module and be called automatically by `-m test test_module`; * which way should be used to mark the files/snippets as doctest-compatible; * how to have a doctest equivalent to setUp/tearDown (this is optional, we can always skip the test if it fails without initialization); (FTR: I was trying the patch on 3.2 and since there were a few conflicts I uploaded the resulting patch in case anyone needs it -- this doesn't mean it should go on 3.2 though.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11643] Use |version| instead of X.Y in the doc
Changes by Mike Hoy mho...@gmail.com: -- nosy: +mikehoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11643] Use |version| instead of X.Y in the doc
Mike Hoy added the comment: So we could fix this in reverse? Remove the |version| and replace them with X.Y since |version| doesn't expand within :file:? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15276] unicode format does not really work in Python 2.x
Chris Jerdonek added the comment: Eric, it looks like you wrote this comment: /* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since we can live with only the string versions of those. The builtin format() will convert them to unicode. */ in http://hg.python.org/cpython/file/19601d451d4c/Python/formatter_unicode.c It seems like the current issue may be a valid reason for introducing a unicode FORMAT_INT (i.e. not just for type-purity and PEP 3101 compliance, but to avoid an exception). What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15952] format(value) and value.__format__() behave differently with unicode format
Chris Jerdonek added the comment: See this code comment: /* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since we can live with only the string versions of those. The builtin format() will convert them to unicode. */ from http://hg.python.org/cpython/file/19601d451d4c/Python/formatter_unicode.c In other words, it was deliberate not to make value.__format__(format_spec) return unicode when format_spec is unicode. So the docs should be adjusted to say that they are not always the same. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15419] distutils: build should use a version-specific build directory
Ronald Oussoren added the comment: I don't think this is a bugfix, but a new feature and as such the behavior should only be changed for 3.4. The easiest workaround for this issue is to use setuptools or distribute when installing, as those tools do set the various build directories to version-specific values. -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11643] Use |version| instead of X.Y in the doc
Roundup Robot added the comment: New changeset de6976fe19aa by Ezio Melotti in branch '2.7': #11643: fix rst markup error in site.rst. http://hg.python.org/cpython/rev/de6976fe19aa New changeset 7aca2781c381 by Ezio Melotti in branch '3.2': #11643: fix rst markup error in site.rst. http://hg.python.org/cpython/rev/7aca2781c381 New changeset c6892ce7e56f by Ezio Melotti in branch 'default': #11643: merge with 3.2. http://hg.python.org/cpython/rev/c6892ce7e56f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11643] Use |version| instead of X.Y in the doc
Ezio Melotti added the comment:
I fixed the one in site.py.
If there's no way to use |version| in :file:`...` I think using {X.Y} is OK, so
that can be done where a bare X.Y (without {}) is currently used.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11643
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15953] Incorrect some fields declaration in the PyTypeObject documentation
New submission from Serhiy Storchaka: The declaration of some fields in the PyTypeObject documentation does not match the sources. Here is a patch that fixes the mismatch. -- assignee: docs@python components: Documentation files: doc_newtypes.patch keywords: easy, patch messages: 170591 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Incorrect some fields declaration in the PyTypeObject documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27207/doc_newtypes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15954] No error checking after using of the wcsxfrm()
New submission from Serhiy Storchaka: The wcsxfrm() function may fail but there is no error check code. I don't know what exception type should be used here: OSError with an errno EINVAL or some specialized type. I can't prepare tests, because I don't know under what conditions it would be possible error, and whether we can get it on any system at all without broking some internal unicode object invariants. -- components: Library (Lib), Windows messages: 170592 nosy: loewis, storchaka priority: low severity: normal status: open title: No error checking after using of the wcsxfrm() type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15954] No error checking after using of the wcsxfrm()
Christian Heimes added the comment: Have you tried code points beyond the BMP? The C function doesn't have a return value that signals an error. An explicit check of errno is required. http://linux.die.net/man/3/wcsxfrm -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15921] select module uses uninitialized value tv.tv_usec
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +benj resolution: fixed - stage: committed/rejected - patch review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15921] select module uses uninitialized value tv.tv_usec
Changes by Jesús Cea Avión j...@jcea.es: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Martin v. Löwis added the comment: I disagree that sizeof cannot work well for variable-sized types. It works very well for strings, lists, tuple, dicts, and other regular containers. I agree that it is not important that it is absolutely correct (in some sense) for every object, but it shouldn't lose big chunks of data. A bug where it misses four bytes is much less important than a bug where it misses N bytes (for an object-specific value N that can grow indefinitely). As for the specific patch, I don't think any action should be taken before the 3.3 release. I would personally prefer if the computations where done in Py_ssize_t, not PyObject* (i.e. the result of the recursive call should be unwrapped). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15954] No error checking after using of the wcsxfrm()
Serhiy Storchaka added the comment: Here is a sample patch (to specify the location of the issue). I don't sure OSError is well here. As far as I understand, this function is Windows-specific, so I can't check how it works with code points beyond the BMP or with surrogates. -- keywords: +patch Added file: http://bugs.python.org/file27208/wcsxfrm_error_check.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15954] No error checking after using of the wcsxfrm()
Christian Heimes added the comment: The patch looks good. `s` and `buf` are cleaned up after the exit label. -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15922] make howto/urllib2.rst doctests pass
Ezio Melotti added the comment: + try: +... urllib.request.urlopen(req) +... except urllib.error.URLError as e: +...print(Error opening url.) +...# E.g. [Errno 8] nodename nor servname provided, or not known +...print(Reason:, e.reason) #doctest: +ELLIPSIS +Error opening url. +Reason: ... I think the previous version was clearer, so maybe this should be a skip. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15955] gzip, bz2, lzma: add method to get decompressed size
New submission from Christian Heimes: The gzip, bz2 and lzma file reader have no method to get the actual size and compression ratio of a compressed file. In my opinion it's useful to know how much disk space a file will need before it's decompressed. -- components: Library (Lib) messages: 170598 nosy: christian.heimes, nadeem.vawda priority: normal severity: normal status: open title: gzip, bz2, lzma: add method to get decompressed size type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Serhiy Storchaka added the comment:
It can't work well if we count internal Python objects that can be shared. This
is because the work well concept is not well defined. And because the
implementation of a certain defined calculation algorithm can be completely
unmaintainable, that is not well.
If we wrote in the StringIO the same 1 MB string twice, should the __sizeof__()
return about 1) 2 MB, 2) 1 MB or 3) size of empty stream if there are external
links to this shared string? Patch implements the second strategy, it can be
simplified to the first one or complicated even more to a third one. Even more
complication will need to take into account the sharing of eol string ('\r' and
'\n' always shared, '\r\n' may be).
I would personally prefer if the computations where done in Py_ssize_t, not
PyObject*
I too. But on platforms with 64-bit pointers and 32-bit sizes we can allocate
total more than PY_SIZE_MAX bytes (hey, I remember the DOS memory models with
16-bit size_t and 32-bit pointers). Even faster we get an overflow if allow the
repeated counting of shared objects. What to do with overflow? Return
PY_SIZE_MAX or ignore the possibility of errors?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Antoine Pitrou added the comment: I think I'm -1 to run doctests as part of regrtest. Documentation examples are meant to be read, not executed: it is fine for them to omit unimportant information or trivial boilerplate (such as imports). Any complication in the way doc examples must be written will deter us from actually writing examples. Furthermore, spreading unit tests in the doc files instead of Lib/test files will make maintenance of tests more tedious as well. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15954] No error checking after using of the wcsxfrm()
Martin v. Löwis added the comment: I don't know what exception type should be used here: OSError with an errno EINVAL or some specialized type. No, I think the appropriate error is ValueError, at least if errno is EINVAL. because I don't know under what conditions it would be possible error AFAICT, glibc never sets errno. msvcrt gives EILSEQ or ERANGE, but never EINVAL. EILSEQ is returned if LCMapString failed, and ERANE if the output buffer is too small. In either case, the result is INT_MAX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Ezio Melotti added the comment: Documentation examples are meant to be read, not executed I agree, but several of them already run, and others run with the addition of doctests directives (that are hidden in the html output). If the code needs to be changed in a way that is less readable, the test can just be skipped. Furthermore, spreading unit tests in the doc files instead of Lib/test files will make maintenance of tests more tedious as well. Tests should be kept in Lib/test, this is mostly to make sure that the examples are correct. The examples in the docs should still be written with the goal to be clear for the user -- being valid doctests is a secondary goal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15952] format(value) and value.__format__() behave differently with unicode format
Eric V. Smith added the comment: I believe the conversion is happening in Objects/abstract.c in PyObject_Format, around line 864, near this comment: /* Convert to unicode, if needed. Required if spec is unicode and result is str */ I think changing the docs will result in more confusion than clarity, but if you can come up with some good wording, I'd be okay with it. I think changing the code will likely break things with little or no benefit. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Martin v. Löwis added the comment: Am 17.09.2012 14:26, schrieb Serhiy Storchaka: I would personally prefer if the computations where done in Py_ssize_t, not PyObject* I too. But on platforms with 64-bit pointers and 32-bit sizes we can allocate total more than PY_SIZE_MAX bytes (hey, I remember the DOS memory models with 16-bit size_t and 32-bit pointers). Even faster we get an overflow if allow the repeated counting of shared objects. What to do with overflow? Return PY_SIZE_MAX or ignore the possibility of errors? It can never overflow. We cannot allocate more memory than SIZE_MAX; this is (mostly) guaranteed by the C standard. I don't know whether you deliberately brought up the obscure case of 64-bit pointers and 32-bit sizes. If there are such systems, we don't support them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15956] backreference to named group does not work
New submission from Steve Newcomb: The '\\gstartquote' in the below does not work: repr( re.compile( '!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?PentityName[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?Pstartquote[\\042\\047])(?PentityText.+?)\\gstartquote[ \\011\\012\\015]*\\', re.IGNORECASE | re.DOTALL).search( '!ENTITY % m.mixedContent ( #PCDATA | i | b)')) 'None' In the following, the '\\gstartquote' has been replaced by '\\2'. It works. repr( re.compile( '!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?PentityName[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?Pstartquote[\\042\\047])(?PentityText.+?)\\2[ \\011\\012\\015]*\\', re.IGNORECASE | re.DOTALL).search( '!ENTITY % m.mixedContent ( #PCDATA | i | b)')) '_sre.SRE_Match object at 0x7f77503d1918' Either this feature is broken or the re module documentation is somehow misleading me. (Yes, I know there is an XML error in the above. That's because it's SGML.) -- components: Regular Expressions messages: 170605 nosy: ezio.melotti, mrabarnett, steve.newcomb priority: normal severity: normal status: open title: backreference to named group does not work type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11664] Add patch method to unittest.TestCase
Michael Foord added the comment: Why would mock.patch.object be the appropriate one to add to TestCase? patch.object is used orders of magnitude less than patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11664 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15419] distutils2: build should use a version-specific build directory
Éric Araujo added the comment: Okay, then it’s distutils2 material. -- components: -Distutils title: distutils: build should use a version-specific build directory - distutils2: build should use a version-specific build directory versions: +3rd party, Python 3.4 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15419] distutils2: build should use a version-specific build directory
Éric Araujo added the comment: A doc note for distutils in stable versions could also be added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15475] Correct __sizeof__ support for itertools
Meador Inge added the comment: Unassigning from myself. I thought I would have more time to review and push this through. -- assignee: meador.inge - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15956] backreference to named group does not work
Amaury Forgeot d'Arc added the comment: \g is meant to be used in re.sub(), in the replacement text (see the docs); in the search pattern, (?P=startquote) can be used to refer to a named group. The docs of (?Pname...) looks clear to me. -- nosy: +amaury.forgeotdarc resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14616] subprocess docs should mention pipes.quote/shlex.quote
Éric Araujo added the comment: You thought it was better not to mention that pipes.quote is semi-official and becomes public as shlex.quote in 3.3? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
R. David Murray added the comment: I've given this some more thought, and I'm leaning toward Antoine's POV here. The point of running the doctests in the docs is not to test python, but to test the docs. Sphinx has a facility to do that: make doctest. So I think it is better to use that doc-specific infrastructure to test the docs. This also allows us to use the full Sphinx facilities to work with those doctests, which includes hiding the not-necessary-for-docs bits. I think we should be moving *away* from having special infrastructure in regrtest. As much stuff as makes sense should be moved to unittest, and we've been slowly doing that. Correspondingly, we should use Sphinx's native test facilities, not add special stuff to regrtest. If Sphinx doesn't have the ability to run individual files, we should add that ability to Sphinx, not regrtest. (Note: I personally do not use the ability recently added to regrtest to select unit tests from the command line, instead I use the unittest CLI directly, and I think that's the better way to do it. IMO regrtest should be focused on running the test *suite*, not on running individual tests.) Once we've refined the docs so that 'make doctest' runs cleanly, we should automate the testing of the docs in some fashion. One way to do that would be to define a test module that handles the interfacing with Sphinx, and is controlled by a resource that is *not* included in -uall, and is then explicitly enabled on certain buildbots. Doctests in module files could be handled the same way: build a test module that does whatever autodiscovery is needed, and control it via a resource not included in -uall. (I am, however, open to the argument that this one should be included in -uall.) Again, there already exists a way to invoke individual files, using the native doctest facilities. So adding hooks to regrtest is not really needed, IMO. Also again, if the doctest CLI is lacking, the improvement should go into doctest. IMO :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Antoine Pitrou added the comment: I think we should be moving *away* from having special infrastructure in regrtest. As much stuff as makes sense should be moved to unittest, and we've been slowly doing that. Correspondingly, we should use Sphinx's native test facilities, not add special stuff to regrtest. If Sphinx doesn't have the ability to run individual files, we should add that ability to Sphinx, not regrtest. (Note: I personally do not use the ability recently added to regrtest to select unit tests from the command line, instead I use the unittest CLI directly, and I think that's the better way to do it. IMO regrtest should be focused on running the test *suite*, not on running individual tests.) The main reason to add it to regrtest was to allow special test modes with it (such as -R or -F). (and, also, the unittest CLI's poor online help makes it rather unusable for me :-)). But I agree on the principle that unittest should be expanded to better accomodate the needs of regrtest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Éric Araujo added the comment: RDM’s arguments make a lot of sense. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
R. David Murray added the comment: We should improve the unittest help, then :) I will also note that the couple of times I tried it I couldn't figure out how to use the regrtest test selection :) What we probably need for regrtest is a way to pass through a selection string from the regrtest command line to the unittest test discovery, and then run the selected tests under regrtest control. The same could apply to Sphinx doctests and module doctests. This may require adding APIs to those packages (unittest may already have the necessary API). I think the Sphinx case is the one that will take the most work to accomplish, but I also think it is worth the effort to do that rather than adding CPython-specific stuff to regrtest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Brett Cannon added the comment: I should mention that http://bugs.python.org/issue10967 exists as a meta issue about trying to gut regrtest in favour of using other things in unittest (and doctest in this case) when possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Interpreter Core nosy: +storchaka versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15957] README.txt points to broken contributing url in python wiki
New submission from Cliff Dyer: The README.txt file for distutils2 points to http://wiki.python.org/Distutils2/Contributing, which raises a 404. The correct URL is http://wiki.python.org/moin/Distutils2/Contributing. The attached patch fixes this typo. -- assignee: docs@python components: Distutils2, Documentation files: broken_link.diff keywords: patch messages: 170617 nosy: alexis, docs@python, jcd, tarek priority: normal severity: normal status: open title: README.txt points to broken contributing url in python wiki Added file: http://bugs.python.org/file27209/broken_link.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15945] memoryview + bytes fails
Antoine Pitrou added the comment: Opened issue15958 for the bytes.join enhancement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
New submission from Antoine Pitrou: This should ideally succeed: b''.join([memoryview(b'foo'), b'bar']) Traceback (most recent call last): File stdin, line 1, in module TypeError: sequence item 0: expected bytes, memoryview found (ditto for bytearray.join) -- components: Interpreter Core messages: 170618 nosy: pitrou priority: normal severity: normal stage: needs patch status: open title: bytes.join() should allow arbitrary buffer objects type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15144] Possible integer overflow in operations with addresses and sizes.
Antoine Pitrou added the comment: Perhaps the three new macros should be made available in a .h file? (in which case they should be private, i.e. start with _). -- type: security - behavior versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15959] Declaration mismatch of quick integer allocation counters
New submission from Serhiy Storchaka: In Objects/longobject.c quick_int_allocs and quick_neg_int_allocs defined as int but in Objects/object.c they are declared and used as Py_ssize_t. Here is a patch that fixes this mismatch. See also issue4850. -- components: Interpreter Core files: quick_int_allocs.patch keywords: patch messages: 170621 nosy: loewis, storchaka priority: normal severity: normal status: open title: Declaration mismatch of quick integer allocation counters type: resource usage versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27210/quick_int_allocs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15959] Declaration mismatch of quick integer allocation counters
Christian Heimes added the comment: The patch looks good. IMO it can safely be applied as it fixes a rarely used debug feature. -- nosy: +christian.heimes stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15144] Possible integer overflow in operations with addresses and sizes.
Serhiy Storchaka added the comment: Perhaps the three new macros should be made available in a .h file? (in which case they should be private, i.e. start with _). Perhaps. There are similar macros in other files (Include/objimpl.h, Objects/obmalloc.c, Python/pyarena.c, Modules/expat/xmlparse.c). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15903] Make rawiobase_read() read directly to bytes object
Richard Oudkerk added the comment: New patch which checks the refcount of the memoryview and bytes object after calling readinto(). If either refcount is larger than the expected value of 1, then the data is copied rather than resized. -- Added file: http://bugs.python.org/file27211/iobase_read.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15950] open() should not accept bool argument
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15836] unittest assertRaises should verify excClass is actually a BaseException class
Daniel Wagner-Hall added the comment: Is anything blocking this patch's submission? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed
Arfrever Frehtes Taifersar Arahesis added the comment: I think that email.utils.parsedate_to_datetime(0) should raise ValueError instead of TypeError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15903] Make rawiobase_read() read directly to bytes object
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +IO, Library (Lib) type: - performance ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15903] Make rawiobase_read() read directly to bytes object
Antoine Pitrou added the comment: If either refcount is larger than the expected value of 1, then the data is copied rather than resized. I think that's a useless precaution. The bytes object cannot leak since you are using PyMemoryView_FromMemory(), which doesn't know about the original object. Out of curiousity, have you done any benchmarks? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15903] Make rawiobase_read() read directly to bytes object
Richard Oudkerk added the comment: I think that's a useless precaution. The bytes object cannot leak since you are using PyMemoryView_FromMemory(), which doesn't know about the original object. The bytes object cannot leak so, as you say, checking that refcount is pointless. But the view might leak, and since it does not own a reference to the base object we have a problem: we can't deallocate the bytes object for fear of breaking the view. It looks like objects returned by PyMemoryView_FromMemory() must never be allowed to leak, so I am not sure there are many circumstances in which PyMemoryView_FromMemory() is safe to use. Perhaps using PyBuffer_FillInfo() and PyMemory_FromBuffer() would keep alive the bytes object while the view is alive, without letting the bytes object leak. Out of curiousity, have you done any benchmarks? No. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15903] Make rawiobase_read() read directly to bytes object
Antoine Pitrou added the comment: The bytes object cannot leak so, as you say, checking that refcount is pointless. But the view might leak, and since it does not own a reference to the base object we have a problem: we can't deallocate the bytes object for fear of breaking the view. Indeed, that's a problem (but your patch does deallocate the bytes object). It's quite fishy, I'm not sure how to solve the issue cleanly. Stefan, do you have an idea? -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8542] Another test issue
Changes by R. David Murray rdmur...@bitdance.com: -- stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12849] Cannot override 'connection: close' in urllib2 headers
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12849 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15956] backreference to named group does not work
Steve Newcomb added the comment: I have re-read the documentation on re.sub(). Even now, now that I understand that the \ggroupname syntax applies to the repl argument only, I cannot see how the documentation can be understood that way. The paragraph in which the explanation of the \ggroupname syntax appears does not mention the repl argument by name, and neither does the preceding paragraph. The paragraph before the preceding paragraph is about the pattern argument, not the repl argument, and it consists entirely of the words, The pattern may be a string or an RE object. So I don't see how the explanation of the \ggroupname syntax can be understood as applying only to the repl argument, even though you have now informed me that that's the case (which is helpful to know -- thanks!). Indeed, the paragraph that explains the \ggroupname syntax *still* appears to me to be discussing the pattern argument. And it even mentions the ?Pname syntax, which can only appear in a pattern, not in a repl, in the very same sentence as the \ggroupname syntax, even though those two syntactic features appear in *different* expression languages, and no single expression language has both of them. So there is no clear indication that it is discussing two different expression languages. Indeed, another syntactic feature, \groupnumber, also discussed in the same paragraph, *is* found in both expression languages, so it's even more confusing to a person who knows that both ?Pgroupname and \groupnumber appear in the pattern expression language. There is nothing in the documentation that would inform a person (such as myself) that the \ggroupname syntax is not also part of the pattern expression language, just as the other two features are. (And why isn't \ggroupname part of the pattern language, anyway, or at least some way to refer to a match made in a previous *named* group? It would be very convenient to be able to do that, particularly when using a dynamically-created regexp to parse strings delimited with a choice of delimiters that must match at both ends.) In other words, this documentation could be beneficially improved. -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS
Trent Nelson added the comment: Just noticed that the Solaris 10 slave is failing in the same way: == FAIL: test_utime (test.test_os.StatAttributeTests) -- Traceback (most recent call last): File /home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_os.py, line 332, in test_utime self._test_utime(support.TESTFN, getattr, utime, 10) File /home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_os.py, line 318, in _test_utime self.assertEqual(attr(st0, st_mtime), attr(st1, st_mtime)) AssertionError: 1347752941.275297 != 1347752941.275296 Note that /home/cpython on this slave is backed by UFS, not ZFS. (It's accessible to committers via sb-s10.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15945] memoryview + bytes fails
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15796] Fix readline() docstrings
Roundup Robot added the comment: New changeset 210a189544c3 by Ezio Melotti in branch '2.7': #15796: Fix \n in readline docstring. http://hg.python.org/cpython/rev/210a189544c3 New changeset 6386e1f4f1fd by Ezio Melotti in branch '3.2': #15796: Fix \n in readline docstring. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/6386e1f4f1fd New changeset 3a880d640981 by Ezio Melotti in branch 'default': #15796: merge with 3.2. http://hg.python.org/cpython/rev/3a880d640981 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15796] Fix readline() docstrings
Ezio Melotti added the comment: Pong, thanks for the patch! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4711] Wide literals in the table of contents overflow in documentation
Ezio Melotti added the comment: I experimented a bit more with text-overflow: ellipsis; but didn't obtain anything good. With word-wrap: break-word; I had better luck, and even if breaking long words might not be the most elegant solution, it looks better than the overflowing text and doesn't hide any content (like text-overflow does). Georg, what do you think? -- keywords: +patch stage: needs patch - patch review versions: +Python 3.3 -Python 2.6, Python 3.1 Added file: http://bugs.python.org/file27212/issue4711.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4711] Wide literals in the table of contents overflow in documentation
Changes by Ezio Melotti ezio.melo...@gmail.com: Added file: http://bugs.python.org/file27213/issue4711.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
