[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
paul j3 added the comment: I need to make one correction to my last post: '-x 1 2 -w 3 4 5 6', # w:3, x:[1,2], y:4, z:[5,6] + # w:3, x:[1], y:2, z:[4,5,6] - The second solution is only possible if 'z' is not consumed when 'y' is being processed. In current version, if consume_positionals() is called with a 'AO' pattern, 'y' will match the first 'A', and 'z' will match ''. That means '4 5 6' will be left over. It's only when I use the patch in http://bugs.python.org/issue14191#msg187051 (argparse doesn't allow optionals within positionals) that the processing 'z' is delayed, so it can get [4,5,6]. So at least with the 4 arguments in this example, bethard's idea only seems to make a difference in the case of '-w 1 -x 2 3 4 5', where 'y' lays claim to the last string, and '-x' gets the rest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9338 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17973] '+=' on a list inside tuple both succeeds and raises an exception
New submission from Andy Chugunov: At the same time append() succeeds silently, while simple '+' fails. Here's an example: a = ([1],) a[0].append(2) a ([1, 2],) a[0] += [3] Traceback (most recent call last): File pyshell#47, line 1, in module a[0] += [3] TypeError: 'tuple' object does not support item assignment a ([1, 2, 3],) a[0] = a[0] + [4] Traceback (most recent call last): File pyshell#49, line 1, in module a[0] = a[0] + [4] TypeError: 'tuple' object does not support item assignment a ([1, 2, 3],) Looks like a self-contradictory behavior. Unfortunately, I'm not yet advanced enough to figure out where the problem might be and submit a fix. Tested with v3.3.1 on Windows 7 (64-bit), and v3.2.3 and v2.7.3 on Debian 7 (also 64-bit). -- messages: 189201 nosy: andy.chugunov priority: normal severity: normal status: open title: '+=' on a list inside tuple both succeeds and raises an exception type: behavior versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17973] '+=' on a list inside tuple both succeeds and raises an exception
Changes by Ronald Oussoren ronaldousso...@mac.com: -- assignee: - ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17973] '+=' on a list inside tuple both succeeds and raises an exception
Ronald Oussoren added the comment: This is a side effect to the way the in place operators work. Basically a[0] += [3] is evaluated as: a[0] = a[0].__iadd__([3]) The call to __iadd__ succeeds, which is why the list is updated, but you get an exception when the interpreter tries to update item 0 of the tuple. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17973] '+=' on a list inside tuple both succeeds and raises an exception
Ronald Oussoren added the comment: I'm closing this issue as rejected because the current behavior is intentional, although it is confusing (IMO). -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17973] '+=' on a list inside tuple both succeeds and raises an exception
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Ronald Oussoren added the comment: The RVM issue is wrong, ML still includes OpenSSL. Apple has deprecated the use of the system install of OpenSSL, but the library and include files are still there. There are two paths for avoiding the deprecated library: either ship your own build of OpenSSL, or (and that's probably what Apple would prefer) use the Apple specific frameworks (common crypto and/or security transforms). The latter has the advantage of using the security infrastructure, such as the CA chain, as provided by Apple, but would require significant code changes in Python, might take even more work to get to work properly on OSX 10.6 or earlier (and cannot work on 10.4), and might cause problems with scripts that use os.fork() because a number of core Apple frameworks won't work properly in the child process and cause a hard crash when they were initialized in the parent and then used in a child. All in all it would be better to ship a recent version of OpenSSL with the binary installers on OSX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
Kiyoshi Aman added the comment: I would instead suggest a cidr or netmask kwarg, rather than accepting a tuple as first argument. -- nosy: +Kiyoshi.Aman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16531 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Kristján Valur Jónsson added the comment: Catching regressions is what we have the regression tests for. If it is not in caught by the regression tests, then it is not a regression, by definition. Bug fix mode is for fixing bugs, IMHO. Yes, I have patched my local version. The reason I am here having this discussion is that I want to contribute to help others that are using 2.7 for multiprocessing. Others will have the same problem, and probably have, already. Anyway, I cannot easily reproduce the problem, it happens regularly in a live production environment. My patch is a conjecture based patch. But I actually had a different thought about how to handle this. The particular manifestation of this error occurs because an exception state is being cleared from the system dict. The dict contains a frame and there is where the connection object is being held. The problem can be avoided, by clearing the exception right at the start of the PyInterpreterState_Clear(), thus flushing out most side effects right at the start. I'll prepare a patch for you to review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17950] Dynamic classes contain non-breakable reference cycles
Kristján Valur Jónsson added the comment:
Thanks Guido.
The current patch provides the property you ask for. I will see if I can make
the fiddling of the internal tuple less magical.
I have one other question for you: The standard mro puts the class in the
0th position.
But apparently, there is a mechanism for a custom mro, by calling an mro()
function on the type (as far as I understand).
However, the order of objects in the returned tuple is not verified, only the
types of the objects therein (this is in mro_internal())
Yet there is code that manually skips the 0th element, e.g. this code
/* Initialize tp_dict properly */
bases = type-tp_mro;
assert(bases != NULL);
assert(PyTuple_Check(bases));
n = PyTuple_GET_SIZE(bases);
for (i = 1; i n; i++) {
PyObject *b = PyTuple_GET_ITEM(bases, i);
if (PyType_Check(b))
inherit_slots(type, (PyTypeObject *)b);
}
(from PyType_Ready())
I'm not familiar with the mro() function. What kind of black magic is it
supposed to provide? And how can we make sure that its free-form return value
is reconciled with the 1-based loop above?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Richard Oudkerk added the comment: Kristjan, could you confirm whether joining the pool explicitly before shutdown (in the way I suggested earlier) fixes the problem. I think it should -- at shutdown you won't switch to a thread if it has already been joined. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Antoine Pitrou added the comment: Catching regressions is what we have the regression tests for. If it is not in caught by the regression tests, then it is not a regression, by definition. Call it what you want :-) The bottom line is that we'll release a 2.7.5 soon because of breakage introduced in 2.7.4. Whether or not it's a regression according to some platonic definition isn't very important here. The problem can be avoided, by clearing the exception right at the start of the PyInterpreterState_Clear(), thus flushing out most side effects right at the start. I'll prepare a patch for you to review. I think this kind of stuff is too tricky to risk breaking 2.7 once again with it. If 3.x has the same issue, then a patch is helpful, otherwise not IMHO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1772673] Replacing char* with const char*
Serhiy Storchaka added the comment:
In C++ we may overload functions for backward compatibility:
PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *,
const char *, const char * const *, ...);
PyAPI_FUNC(int) PyArg_VaParseTupleAndKeywords(PyObject *, PyObject *,
const char *, const char * const *, va_list va);
...
#ifdef __cplusplus
inline int
PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *keywords,
const char *format, char * const *kwlist, ...)
{
int retval;
va_list va;
va_start(va, kwlist);
retval = PyArg_ParseTupleAndKeywords(args, keywords, format,
(const char * const *)kwlist, va_start);
va_end(va);
return retval;
}
#endif
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1772673
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Charles-François Natali added the comment: Catching regressions is what we have the regression tests for. If it is not in caught by the regression tests, then it is not a regression, by definition. You do realize this sentence doesn't make sense, do you? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
New submission from Antoine Pitrou: Attached patch migrates unittest to argparse. This doesn't make discover handling much saner, given the awful way it's originally implemented. -- components: Library (Lib) files: unittest_argparse.patch keywords: patch messages: 189212 nosy: ezio.melotti, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: Migrate unittest to argparse type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30256/unittest_argparse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Michael Foord added the comment: What's the benefit of this change? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Antoine Pitrou added the comment: I don't think Serhiy's patch should be blocked by a larger issue. I suppose you could rebase easily over his changes. -- versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Antoine Pitrou added the comment: I was considering making it possible to customize command-line options, as requested by Guido, and it's better to expose the modern API rather than the more obsolete one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc
A.M. Kuchling added the comment: Kaleb Robertson's changes look good. Larry, do you want to go ahead and commit this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16024 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Michael Foord added the comment: Ok, feel free to reimplement discovery command line handling if it can be done in a compatible-but-less-horrible way. Anyway, the patch looks fine and a couple of minor cleanups in there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Serhiy Storchaka added the comment: I don't see much sense in this modernization, while the code does not use the capabilities of argparse (and even optparse). Why USAGE_AS_MAIN/USAGE_FROM_MODULE/etc exist, why help is not generated automatically? Why -v/-q store boolean flags instead of changing the numerical level of verbosity? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Kristján Valur Jónsson added the comment: Richard, I'll review implement your change. It is a bit tricky to test this, since I can only tell after a few days if the particular (rare) problem has been fixed. The crash is a rare one but consistently happens with some probability we use multiprocessing to perform certain batch processing. About regressions: The term means that problems, previously fixed, become broken again. All fixes should reasonably have appropriate tests in the regression test suite. I don't know what particular regressions you have been battling since 2.7.4. I hope they are all testable by now. I only know that there is a exit problem with multiprocessing that statistically happens and is problemematic. It caused use to stop using multiprocessing and parallel jobs until I could diagnose the problem. I have suggested several fixes to this particular problem. I have two favorites, which would also help in the general case: 1) calling sys.exc_clear() at the beginning of the python finalize part, to throw out any lingering traceback and frame objects. This will cause side effects such as gil-twiddling to happen early, and without consequence. sys.exc_clear() is a safe api and used throughout the code, an extra call just prior to exit should be a very safe operation. 2) Turn off multi-threading at the start of python exit, by setting interpreter_lock to NULL. Again, this is a no-brainer, since the NULL value is already well defined and works well. It will cause all subsequent GIL releases to be no-ops. I personally favor the second one. It makes no sense to allow other threads to run after finalization has started and forcing them to stay dead is only prudent. 2.7 is not frozen, and it is in bug fix mode. If a solid bug fix to an actual problem is proposed, we should embrace it, and deal with any eventual fallout appropriate as the price of doing business. 2.7 is a product that is alive and well, used by millions of people and thousands of businesses and will remain so for quite some time. I know that most of the core devs have moved on to greener pastures, but I for one would like to stay loyal to this workhorse of a product and continue to make necessary improvements to it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Michael Foord added the comment: Test discovery and new options (buffer, failfast etc) were bolted onto an old and ugly design. Yes the code could use an overhaul and rebuilding from scratch - but doing that whilst remaining fully compatible with all the existing usage patterns is difficult. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17969] multiprocessing crash on exit
Kristján Valur Jónsson added the comment: Richard, reading the multiprocessing.py code, it appears that your suggestion of closign and joining the Pool() object should also do the trick. Doing that will certainly also fix this particular case. I'll implement that in our local application code. I'm still not happy that 2.7 has a potential exit crash if a daemon thread is left hanging :( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17955] Minor updates to Functional HOWTO
A.M. Kuchling added the comment: Updated version of the patch: * uses 'r' instead of 'N'. * removes the old outline and some notes at the end. * minor rewriting. -- Added file: http://bugs.python.org/file30257/functional.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17975] libpython3.so conflicts between $VERSIONs
New submission from Patrick Welche: I currently have python 2.7 and 3.2 installed concurrently. I just tried to install 3.3 as well, but a file conflicts between 3.2 and 3.3. It is libpython3.so. Given that we go out of our way e.g. with $(INSTALL_DATA) Misc/python.pc $(DESTDIR)$(LIBPC)/python-$(VERSION).pc to avoid clashes, what should be done about PY3LIBRARY? -- components: Build messages: 189223 nosy: prlw1 priority: normal severity: normal status: open title: libpython3.so conflicts between $VERSIONs type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Guido van Rossum added the comment: Would you mind doing the backport then? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17970] Mutlithread XML parsing cause segfault
Christian Heimes added the comment: In my opinion it's fine to document Python's XML parser as not thread-safe and leave locking to the user. Any fancy locking or tracking is going to make it slower for users. Any it takes a lot of effort to implement the feature, too. lxml offers a faster XML parser with multi-threading support. -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
New submission from Jaakko Moisio:
file.write doesn't sometimes raise IOError when it should, e.g. writing to
/dev/full in line buffered mode:
jaakko@jm-laptop:~$ python
Python 2.7.5+ (2.7:a32a3b79f5e8, May 14 2013, 14:20:11)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
f=open('/dev/full','w',1)
f.write('hello\n')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 28] No space left on device
f.close()
f=open('/dev/full','w',1)
f.write('hello')
f.write('\n')
f.close()
# No IOError!
...
The current implementation of file.write relies on comparing the return value
of fwrite to the expected number of bytes written to detect errors. I haven't
dug deep enough into the C standard to know for sure if fwrite return value ==
expected should always imply no error, but in my example it clearly doesn't (I
assume my glibc and fwrite aren't broken though). However using ferror to
detect the error works fine and IOError was raised as expected.
Python3 and io module use different implementation where this is no longer an
issue. For us still using Python 2.7 I suggest the attached simple patch to fix
the issue.
--
components: Interpreter Core
files: fileobject-fix.patch
keywords: patch
messages: 189226
nosy: jasujm
priority: normal
severity: normal
status: open
title: file.write doesn't raise IOError when it should
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30258/fileobject-fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17922] Crash in clear_weakref
Jan Safranek added the comment: On 05/09/2013 09:07 AM, Jan Safranek wrote: Jan Safranek added the comment: On 05/07/2013 05:32 PM, Antoine Pitrou wrote: Jan, one possibility would be for Pegasus to stop unloading Python, it seems. It is always possibility. Actually, Pegasus plugin is just a shared object (.so) and the .so is linked with Python. Pegasus calls dlopen() and dlclose() on it. After dlclose(), the plugin is removed from memory. Unfortunately, libpython2.7.so stays loaded, at least /proc/XXX/mems says so. If there was a way to unload libpython2.7.so from memory too... libpython2.7.so is not unloaded because python extensions, e.g. /usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so was dlopenened by Python and it was not dlclosed - glibc does not unload it. It seems that Py_Finalize() does not even close opened shared objects. Isn't it a bug? Jan -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value
New submission from Barry A. Warsaw: The docs[1] say: .. function:: urlopen(url, data=None[, timeout], *, cafile=None, capath=None, cadefault=True) The code[2] says: def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, *, cafile=None, capath=None, cadefault=False): Obviously, the code cannot be changed in a stable release, and whether the default should be changed for 3.4 is a separate discussion. For now, the docs should be fixed to reflect the code. [1] Doc/library/urllib.request.rst [2] Lib/urllib/request.py -- assignee: barry components: Documentation messages: 189228 nosy: barry priority: normal severity: normal status: open title: urllib.request.urlopen() cadefault argument is documented with wrong default value type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value
Roundup Robot added the comment: New changeset e2288953e9f1 by Barry Warsaw in branch '3.3': - Issue #17977: The documentation for the cadefault argument's default value http://hg.python.org/cpython/rev/e2288953e9f1 New changeset 85ecc4761a6c by Barry Warsaw in branch 'default': - Issue #17977: The documentation for the cadefault argument's default value http://hg.python.org/cpython/rev/85ecc4761a6c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value
Changes by Barry A. Warsaw ba...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17936] O(n**2) behaviour when adding/removing classes
Kristján Valur Jónsson added the comment: Yes, thanks for pointing that out, Antoine, I have made the change locally. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17950] Dynamic classes contain non-breakable reference cycles
Armin Rigo added the comment: Well, adding weak references left and right to break cycles is going to subtly change or break people's code and hasn't been done so far, but that's only my opinion. Anyway, I want to correct what you say about tp_subclasses: yes, tp_subclasses is a list of weakrefs, but the reason is not (as I think you mean) to avoid cycles. The reason is simply that if it were strong references, then all classes ever created would stay alive. -- nosy: +arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17970] Mutlithread XML parsing cause segfault
Amaury Forgeot d'Arc added the comment: In my opinion it's not fine to let Python crash. The implementation could be similar to the one in bufferedio.c, it's quite lightweight. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Charles-François Natali added the comment:
I assume my glibc and fwrite aren't broken though
Actually, it's a glibc bug when the last character is a '\n':
$ python -c f = open('/dev/full', 'w', 1); f.write('hello'); f.close()
Traceback (most recent call last):
File string, line 1, in module
IOError: [Errno 28] No space left on device
Normal.
Now, you add a trailing newline:
$ strace -e write python -c f = open('/dev/full', 'w', 1); f.write('hello');
f.write('\n'); f.close()
write(3, hello\n, 6) = -1 ENOSPC (No space left on device)
write() still returns ENOSPC, but it gets ignored by fwrite().
I've had a quick look at the source, and I think the culprit is here:
http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c#l1270
1336 if (do_write)
1337 {
1338 count = new_do_write (f, s, do_write);
1339 to_do -= count;
1340 if (count do_write)
1341 return n - to_do;
1342 }
It looks like there's a check missing here for count 0.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Meador Inge added the comment: I don't think Serhiy's patch should be blocked by a larger issue. I suppose you could rebase easily over his changes. Where rebase=undo, sure. The changes for issue3132 are pretty extensive (the basic data structures are changed). And as mentioned in msg165892, msg188840, and msg125617 I have already proposed and implemented this optimization many months back. If we feel that this optimization is really critical, then I agree let's not hold it up and I will just work around it with my patch for issue3132. I don't see it as that critical, but I understand that the PEP 3118 changes are dragging on and this optimization might be important for some now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Serhiy Storchaka added the comment: Indeed, fwrite() can return expected number of items and set errno. Here is a simple example on C. An output is: setvbuf 0 0 fwrite 5 0 fwrite 1 28 fwrite 1 28 On writing \n fwrite returns 1 and set errno to ENOSPC. -- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file30259/fullwrite.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Antoine Pitrou added the comment: Ok, feel free to reimplement discovery command line handling if it can be done in a compatible-but-less-horrible way. I don't think it's possible. Best way forward would be to provide a pytest utility that does discovery automatically, and leave python -m unittest as the lesser, undocumented option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Charles-François Natali added the comment: Indeed, fwrite() can return expected number of items and set errno. Here is a simple example on C. An output is: Yeah, who's volunteering to report it to the glibc? That's not a python bug, but I feel bad ignoring it. Note that ferror() isn't reliable (not on my box at least), so we have to use errno directly. And of course keep the check that the value returned by fwrite matches. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17950] Dynamic classes contain non-breakable reference cycles
Guido van Rossum added the comment: Kristjan, it seems you're in over your head. :-) The mro() function is documented here: http://docs.python.org/3/library/stdtypes.html?highlight=mro#class.mro It exists to be called instead of using __mro__ directly; a metaclass can then override what it returns. (Though I don't know if anyone has ever done this.) The code you quote is in PyType_Ready() and skips bases[0] because bases[0] has already been used as the basic template for the C-level layout of the instances. This particular loop adds additional slots to the layout and (most importantly) verifies that no bases are in conflict with the layout enforced by bases[0]. (This is required because we don't actually implement virtual slots at this level -- the C-level layout can only extend the first base class's layout.) BTW, Armin is also right about the reason for using weak references in the __subclasses__ list. As for replacing references with weak references, I would be much more concerned if you were proposing this for e.g. bound methods or instances, but that doesn't mean I'm completely unconcerned... In addition to worrying about breaking (obscure) code that might depend on those references, I worry that it is trying to optimize for an unusual case (dynamically created classes in a world where you don't want to call gc.collect()) but slowing down the common case (access of the class from the descriptor every time a descriptor is used). Specifically about your patch, I'm pretty sure there are some calls in there that don't expect a NULL pointer, as d_type is never NULL; but adding the weak reference makes it possible that your macro will return a NULL pointer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Antoine Pitrou added the comment: Le mardi 14 mai 2013 à 16:37 +, Meador Inge a écrit : If we feel that this optimization is really critical, then I agree let's not hold it up and I will just work around it with my patch for issue3132. I don't see it as that critical, but I understand that the PEP 3118 changes are dragging on and this optimization might be important for some now. Are you sure the PEP 3118 changes will land in 3.4? It would be a pity to lose a simple improvement because it was deferred to a bigger change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Antoine Pitrou added the comment: Yuck. We can of course workaround this (the glibc is commonly used :-)). Why is ferror() not reliable? -- priority: normal - low stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Charles-François Natali added the comment: Why is ferror() not reliable? Because the glibc doesn't check the errno return code after the write() syscall, and thus doesn't set the file's stream error flag (ferror() just checks this flag). That's what I saw from the code. I was a little surprised when Jaako says that ferror() is enough to detect this, so I modified Serhiy code to print ferror(), and actually ferror() reports an error for subsequent writes, not for the first one (probably because the error goes unnoticed only when the buffer is in a particular state). So in short, errno is the only reliable way to check for errors :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17807] Generator cleanup without tp_del
Roundup Robot added the comment: New changeset edefd3450834 by Antoine Pitrou in branch 'default': Backout c89febab4648 following private feedback by Guido. http://hg.python.org/cpython/rev/edefd3450834 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17807] Generator cleanup without tp_del
Antoine Pitrou added the comment: After getting some private feedback from Guido, I'm convinced this patch isn't ready for consumption. Objects visible from the frame when it is finalized can be in a weird, incomplete state (Guido reports failing to get the __class__ of an object, for instance). I'm keeping the issue open for now and will try to find further ways to solve the underlying problem. -- resolution: fixed - stage: committed/rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Ronald Oussoren added the comment: The one difference between the system openssl and a separately compiled one is that the former can use the CA root from the KeyChain (and uses a private API to do that, as noted earlier). I just stumbled across a utility that can sync the KeyChain to an OpenSSL CA file: https://svn.macports.org/repository/macports/trunk/dports/security/certsync/files/certsync.m, and a blog message at http://landonf.bikemonkey.org/code/macosx/certsync.20130514.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17922] Crash in clear_weakref
Antoine Pitrou added the comment: Le mardi 14 mai 2013 à 15:28 +, Jan Safranek a écrit : libpython2.7.so is not unloaded because python extensions, e.g. /usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so was dlopenened by Python and it was not dlclosed - glibc does not unload it. It seems that Py_Finalize() does not even close opened shared objects. Isn't it a bug? What do you call shared objects in this context? .so files? Indeed they are not closed, because usually extension modules are not reload-safe: therefore, their basic structures are kept eternally once initialized. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Jaakko Moisio added the comment: Thank you for your comments. I was a little surprised when Jaako says that ferror() is enough to detect this, so I modified Serhiy code to print ferror(), and actually ferror() reports an error for subsequent writes, not for the first one (probably because the error goes unnoticed only when the buffer is in a particular state). Strange. I too modified Serchiy's code and my version of glibc (2.15) set the error flag at the same fwrite call as errno was set: setvbuf 0 0 0 fwrite 5 0 0 fwrite 1 28 1 fwrite 1 28 1 (the last column being the return value of ferror after each fwrite call) I've trusted ferror until now but I'm not an expert on the subject. It's a good point that errno is set by the underlying system call and is thus more reliable. So would checking errno be sufficient (in addition to checking that the lengths agree)? It can only serve to make file_write more robust. -- Added file: http://bugs.python.org/file30260/fileobject-fix2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17950] Dynamic classes contain non-breakable reference cycles
Kristján Valur Jónsson added the comment: Armin: Of course you are right. This is what weak references are for, in a gc world, although their convenience to avoid cycles and enable reference counting to work always makes me forget. I have another ongoing issue regarding tp_subclasses, btw, in issue #17936. Guido: Yes, it is complicated. The reason I am doing this is because I'm working to incorporate these changes in our stackless 2.7 branch. I figured this might be useful to Python at large, hence this submission. relying on gc is not an option when using python in a performance sensitive environment. there are a few places in the core that cause cycles and I'm always keen to try to remove those. Of course we can avoid the dynamic creation of classes, which is perhaps somewhat exotic. But it is a simpler problem than the reference cylcle inherent in recursive closures. I had a crack at that a week ago and ran in to a wall, so I thought I'd set myself an easier target :) Thanks for clarifying mro(). What I was driving at was that without mro(), then type == type-tp_mro[0]. and knowing this, it is easy to put a None in tp_mro[0]. With a custom mro(), this restriction is no longer valid. But my patch deals with this by verifying the assumption. So, there is no big problem there. I hear you worry a bit about performance for descriptors. Performance is indeed a valid concern, but Im not sure that an extra C indirection will show up on any readings, given that the next thing that happens is typically the creation of a bound method or the like, with all the stuff that entails. I am not too worried about possibly returning NULL. That's a technical detail that is fixable. A much better question is whether this is worth doing at all because the practice I'm trying to optimize is probably a rare practice as you point out. When do you truly need to create throwaway classes? Most places that do are simply defining classes in a function scope as a means of name scoping, not realizing that each function invocation will create a unique metaclass instance and cost a non-trivial amount of cpu. So, after this interesting sojourn into the bowels of typeobject.c, and these most enlightening discussions with you (Armin, Guido, Antoine) I don't think I'll pursue this any further. Cheers! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17950] Dynamic classes contain non-breakable reference cycles
Guido van Rossum added the comment: Good call. I think it's perfectly fine for you to do this in your custom 2.7 branch. It feels too fragile to adopt the same approach for Python 3.4 though. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Meador Inge added the comment: Are you sure the PEP 3118 changes will land in 3.4? It would be a pity to lose a simple improvement because it was deferred to a bigger change. No, I am not sure. That is why I said that I understand if others felt this bug was critical to fix now since the PEP 3118 changes were dragging on. In that case I will just rework my patch. I am not trying to stand in the way of this patch. I just wanted folks to be aware that this approach was implemented in the PEP 3118 work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times
New submission from Romulo A. Ceccon:
I have patched (see attachment) Python 2.7.4 (as available for download at
python.org/download) to disable initialization of Unicode (an embeded system
requirement) and now it segfaults with the following program:
#include Python.h
int main(int argc, char** argv)
{
int i;
Py_NoSiteFlag = 1;
Py_SetProgramName(argv[0]);
for (i = 0; i 3; i++)
{
printf(run no. %d\n, i);
Py_Initialize();
Py_Finalize();
}
return 0;
}
The problem appears to be related with the reference count of the empty tuple.
I've also applied the following patch in Objects/tupleobject.c to help diagnose
the problem:
@@ -928,6 +928,8 @@ PyTuple_Fini(void)
#if PyTuple_MAXSAVESIZE 0
/* empty tuples are used all over the place and applications may
* rely on the fact that an empty tuple is a singleton. */
+printf(free_list[0]-ob_refcnt before XDECREF: %d\n,
+free_list[0]-ob_refcnt);
Py_XDECREF(free_list[0]);
free_list[0] = NULL;
*Without* the patch for Python/pythonrun.c the program produces the following
results under Ubuntu 13.04 x64:
run no. 0
free_list[0]-ob_refcnt before XDECREF: 58
run no. 1
free_list[0]-ob_refcnt before XDECREF: 57
run no. 2
free_list[0]-ob_refcnt before XDECREF: 57
Note the strange ref count of the empty tuple (free_list[0]). Now, *with* the
patch, the application will not hold so many references to the empty tuple and
the finalization code ends up trying to deallocate it (what, from my limited
understading of the code, is not supposed to happen):
run no. 0
free_list[0]-ob_refcnt before XDECREF: 2
run no. 1
free_list[0]-ob_refcnt before XDECREF: 1
Segmentation fault (core dumped)
The actual patch I'm using is much more complicated. This is just the minimal
patch able to reproduce the problem. I tried undefining Py_USING_UNICODE but
then the build doesn't succeed.
--
components: Interpreter Core
files: pythonrun.c.patch
keywords: patch
messages: 189250
nosy: Romulo A. Ceccon
priority: normal
severity: normal
status: open
title: Python crashes if Py_Initialize/Py_Finalize are called multiple times
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file30261/pythonrun.c.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17978
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Charles-François Natali added the comment:
Strange. I too modified Serchiy's code and my version of glibc (2.15) set the
error flag at the same fwrite call as errno was set:
setvbuf 0 0 0
fwrite 5 0 0
fwrite 1 28 1
fwrite 1 28 1
(the last column being the return value of ferror after each fwrite call)
Hum, you're right, I just re-ran the test, and I'm finding the same
thing as you (I must have been dreaming).
I just re-checked the glibc code, and indeed the write() error is
checked, and the error flag is set:
http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c#l1255
1241 _IO_ssize_t
1242 _IO_new_file_write (f, data, n)
[...]
1251 count = (__builtin_expect (f-_flags2
1252 _IO_FLAGS2_NOTCANCEL, 0)
1253? write_not_cancel (f-_fileno, data, to_do)
1254: write (f-_fileno, data, to_do));
1255 if (count 0)
1256 {
1257 f-_flags |= _IO_ERR_SEEN;
1258 break;
1259 }
But then this value is returned, and depending on the position in the
buffer, this -1 ends up being incremented to what's left to write, and
can result in returning exactly the same size that was requested.
That's definitely a bug, and a bad one since you can get silent
corruption (fclose() won't even return an error in most cases).
Anyway, this means that ferror() should be enough - in addition to
checking that the returned value matches.
I've trusted ferror until now but I'm not an expert on the subject. It's a
good point that errno is set by the underlying system call and is thus more
reliable. So would checking errno be sufficient (in addition to checking that
the lengths agree)? It can only serve to make file_write more robust.
Yeah, would you like to write a patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16611] multiple problems with Cookie.py
Éric Araujo added the comment: I have just been bitten by a bug (haven’t checked if it’s covered by the added tests) where Cookies uses string.translate incorrectly: File /usr/lib/python2.7/Cookie.py, line 323, in _quote if == translate(str, idmap, LegalChars): File /usr/lib/python2.7/string.py, line 493, in translate return s.translate(table, deletions) TypeError: translate() takes exactly one argument (2 given) The state of the Cookie module is quite embarrassing. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17976] file.write doesn't raise IOError when it should
Jaakko Moisio added the comment: Yeah, would you like to write a patch? Yes. It's fileobject-fix3.patch attached to this issue record. -- Added file: http://bugs.python.org/file30262/fileobject-fix3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Serhiy Storchaka added the comment: Here is a patch which reimplement discovery command line handling in a i-hope-in-compatible-but-less-horrible way (and fixes some bugs). It is horrible still, but I doubt how many changes can I do without breaking compatibility. If _do_discovery() used only in tests, I can clean the code more. I suppose discovery mode doesn't make sense when unittest.main() is called from a test module (i.e. ./python Lib/test/test_bisect.py discover). At least USAGE_FROM_MODULE did not mention this mode. -- Added file: http://bugs.python.org/file30263/unittest_argparse_less_horrible.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17979] Cannot build 2.7 with --enable-unicode=no
New submission from Amaury Forgeot d'Arc: python2.7 can't be compiled with --enable-unicode=no Because of a crash in the re module. It's a regression from 2.7.3. $ ./python -c 'import re; re.compile(([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*))' Traceback (most recent call last): File string, line 1, in module File /home/amauryfa/python/cpython2.7/Lib/re.py, line 190, in compile return _compile(pattern, flags) File /home/amauryfa/python/cpython2.7/Lib/re.py, line 240, in _compile p = sre_compile.compile(pattern, flags) File /home/amauryfa/python/cpython2.7/Lib/sre_compile.py, line 533, in compile groupindex, indexgroup RuntimeError: invalid SRE code The cause is in sre.h: when Py_USING_UNICODE is false, SRE_CODE is defined as unsigned long instead of unsigned short! When this is fixed, the following modules did not compile: _io _json _sqlite3 _ssl _testcapi Which modules are supposed to work without unicode? -- assignee: serhiy.storchaka messages: 189255 nosy: amaury.forgeotdarc, serhiy.storchaka priority: normal severity: normal status: open title: Cannot build 2.7 with --enable-unicode=no versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times
Amaury Forgeot d'Arc added the comment: The official way to build without unicode is ./configure --enable-unicode=no But see issue17979. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17978 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value
Senthil Kumaran added the comment: OMG. That's a glaring mistake. Thanks for fixing it. -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Terry J. Reedy added the comment:
Attached is a 3.3 patch that I *believe* is ready to commit and push.
With my Win7 repository build, I tested running one test from a file (after if
__name__ == '__main__':) or command line ('python_d -m idlelib.PathBrowser');
all idle tests with an interactive interpreter (console or idle shell, see
@template.txt for input); all idle tests from the command line ('python_d -m
test.test_idle'); and idle tests as part of the CPython suite (python_d -m
test). I also tested versions of all but the two batch-mode tests in my 3.3.1
installation.
From what i know, I do not believe there should be much issue with the
framework working on non-Windows systems. But I would not mind verification. I
presume this patch will work as is with 3.4, but ditto. 2.7 may need one tweak
noted below. (Testing with 2.7 is difficult for me at the moment.) Nick: yes
to your 2.7 plan. PEP 343 changes things.
Once applied to all three branches I think this patch is enough to close this
issue and 'get the ball rolling'. Mock, gui testing, and any other big problems
should be separate issues.
The patch adds
Itest/__init__.py (merges doc example, part of previous __init__.py)
Itest/@template (for both test_x.py and startup from x.py)
Itest/test_calltips.py (with first 2 of many tests)
Itest/test_pathbrowser.py (revised, with 1 test, see note below)
test/test_idle.py (revised skeleton of previous __init__.py)
and revises
CallTips.py
PathBrowser.py
to run the corresponding tests when run as '__main__'.
Question: Unittest supports skipping individual test methods and even whole
classes of tests How about skipping (possibly conditionally) an entire file --
especially test_idle, which has no classes, or and test_xxx with multiple
classes?
For multiple reasons related to the fact that Idle and idlelib *are* special,
as recognized by PEP 343, I want to keep the individual test files in an
idlelib subdirectory. as with tkinter tests. (I changed the name from 'test',
so that 'import test' will a always import Lib/test.)
* Once in idlelib, changing to Itest is easier than to ../test/test_idle. With
62 .py files in idlelib, we will be opening pairs of files a lot.
* Copying code and test files to another directory, such as an installation
idlelib/, will be easier. I will be doing that to run with new features and
test things in the installation environment.
* PEP343 makes most of idlelib/* a private arena. Test/* is a public tree
mainly for the buildbots. Tests put there are supposed to pass. In brief, I
personally feel much more comfortable mucking around in a private arena with a
small public window that can selectively open and closed as needed.
* We need an Itest directory anyway for things that do not belong in test/*.
@template is an example, and I have in mind a couple of non-buildbot test
scripts. We may also want an idle-specific support module, as tkinter has.
* Once people install Python so it runs, some still have problems running Idle.
They ask a class instructor or someone else; post here, python-list,
stackoverflow, or elsewhere; or give up. Sometimes the problem is with tkinter,
sometimes with idle, sometimes with their knowledge. A good diagnosis script
should save support time and user frustration. Both tkinter and idle tests
should be available for this. The Windows installer makes the 17 mb of test/*
optional.
Other changes from the previous patch:
* Use unittest.main to run tests.
* Guard test_idle execution with tkinter import, as it is _tkinter, not idlelib
that might not be built. I left the guard for idlelib since someone who deletes
idlelib/* might forget to delete test/test_idle.
* Exceptions raised outside of self.assertXyz (and self.fail) calls are
regarded as an error in the test code rather than a failure of the code tested
(26.3.4. Organizing test code). So, there being no 'assertNotRaises' context
manager, I added try:...except ...: self.fail() to test_pathbrowser.py so a
failure will be reported as such and not as an error. If there is a better way
to do this, let me know.
Since 3.x chains exceptions and prints the original traceback, no message
argument is needed with self.fail to explain the failure. For 2.7, I believe
one should be added.
Note: to empirically test that a test fails properly, it must be run with code
that does not work properly. This is a problem with writing tests after the
fact for code that works properly.
I checked all 62 idlelib/*.py files for a test to see what we have to work
with: the answer is 'not much'. Less than half the files have a test. All but 2
that do bring up a window and require a human to key, click, and look according
to a script that is not provided. (This is not to say that the existing code
will not be helpful for some gui tests.) One of the 2 remaining text tests
prints multiple pages (a config file) for a person to check. By coincidence,
the only automated tests
[issue7965] Problem with urlparse in Windows XP after a drag and drop
Christopher Bare added the comment: I see Senthil's point, but this tripped me up. -- nosy: +Christopher.Bare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7965 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times
Romulo A. Ceccon added the comment: I've made some further investigation on this issue. Here's the output and the stack trace using --with-pydebug (and the attached patch applied): run no. 0 [8766 refs] free_list[0]-ob_refcnt before XDECREF: 2 run no. 1 [8844 refs] free_list[0]-ob_refcnt before XDECREF: 1 Fatal Python error: PyThreadState_Get: no current thread Aborted (core dumped) Thread 1 (Thread 0x77fed700 (LWP 32572)): #0 0x77131425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77134b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x004086f4 in Py_FatalError ( msg=0x5a0378 PyThreadState_Get: no current thread) at Python/pythonrun.c:1631 #3 0x0054120c in PyThreadState_Get () at Python/pystate.c:330 #4 0x0049a13b in tupledealloc (op=0x84e3a0) at Objects/tupleobject.c:218 #5 0x0047adf1 in _Py_Dealloc (op=0x84e3a0) at Objects/object.c:2262 #6 0x0049bba9 in PyTuple_Fini () at Objects/tupleobject.c:933 #7 0x0040519b in Py_Finalize () at Python/pythonrun.c:466 #8 0x004047b6 in main () A build of Python 2.7.3 using the same steps *does not* crash, although it shows the same curious behavior for free_list[0]-ob_refcnt: [8676 refs] free_list[0]-ob_refcnt before XDECREF: 2 run no. 1 [8754 refs] free_list[0]-ob_refcnt before XDECREF: 1 run no. 2 [8832 refs] free_list[0]-ob_refcnt before XDECREF: 1 I have no idea why it behaves like that, but it seems that the default configuration with Unicode enabled is covering some bug (because of the additional references held). Regarding the official way to disable Unicode, I cannot build Python using --enable-unicode=no on Ubuntu 13.04. In 2.7.4, 2.7.3, 2.7.2 and 2.6.8 ./configure aborts with: checking what type to use for unicode... configure: error: invalid value for --enable-unicode. Use either ucs2 or ucs4 (lowercase). I'm afraid I'm missing something really obvious. With 2.5.6 I'm able to get past the configure part but then it fails when building the modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17978 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Todd Rovito added the comment: Terry I think you have a typo you mean PEP434 (http://www.python.org/dev/peps/pep-0434/) where PEP343 exists. Can you please confirm? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Terry J. Reedy added the comment: Yes, of course. Thanks for correcting. 434, 434, 434,... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Ethan Furman added the comment: Got the pickle issues worked out. Added super to the metaclass' __new__. Checking for illegal names of members and raising ValueError if any are found (I know, I know, safety checks! But such an enum is broken from the getgo so I see no reason to allow those names through). Thanks everyone for the excellent feed back. I really appreciate it. Hopefully we're almost done! :) -- assignee: - ethan.furman Added file: http://bugs.python.org/file30265/pep-0435.06.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Ezio Melotti added the comment: A few comments about the patch: 1) I would prefer a more explicit idle_test instead of Itest (assuming I means idle); 2) having idle_test in Lib/test would be better if possible (see #10572); 3) the tests should only be in idle_test, and not in the if __name__ == '__main__': of the files; 4) I'm not sure the @template file is necessary. It could be documented somewhere else though (see e.g. http://docs.python.org/3/library/test.html#writing-unit-tests-for-the-test-package). IOW putting all tests in a separate dir is a good thing, and the dir could either be in Lib/test or in Lib/idlelib. All the tests should be inside this dir, except for Lib/test/test_idle.py that should be the entry point used to run all the tests in idle_test (see e.g. the tests for ctypes, email, and json). Individual tests in idle_test can be run on their own, and they should use the if __name__ == '__main__': unittest.main() idiom. Question: Unittest supports skipping individual test methods and even whole classes of tests How about skipping (possibly conditionally) an entire file -- especially test_idle, which has no classes, or and test_xxx with multiple classes? You can raise unittest.SkipTest or use support.import_module(). This works fine if you run the tests through regrtest, but be aware that unittest itself only sees this as a skip from 3.4 (see #16935). * Exceptions raised outside of self.assertXyz (and self.fail) calls are regarded as an error in the test code rather than a failure of the code tested (26.3.4. Organizing test code). So, there being no 'assertNotRaises' context manager, I added try:...except ...: self.fail() to test_pathbrowser.py so a failure will be reported as such and not as an error. If there is a better way to do this, let me know. If it's supposed to work the try/except is not necessary IMHO. By this logic every line of code should be wrapped in a try/except :) Since 3.x chains exceptions and prints the original traceback, no message argument is needed with self.fail to explain the failure. For 2.7, I believe one should be added. If you still want to keep the try/except, I would provide a meaningful failure message in any case. Note: to empirically test that a test fails properly, it must be run with code that does not work properly. This is a problem with writing tests after the fact for code that works properly. It's not difficult to break the code to test that test works though :) I checked all 62 idlelib/*.py files for a test to see what we have to work with: the answer is 'not much'. Less than half the files have a test. If possible I think these should all be moved to idle_test. You can also add an additional resource to regrtest to skip the ones that require manual intervention. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17955] Minor updates to Functional HOWTO
Ezio Melotti added the comment: LGTM. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Roundup Robot added the comment: New changeset 2b4b289c1abb by Benjamin Peterson in branch '3.3': when arguments are cells clear the locals slot (backport of #17927) http://hg.python.org/cpython/rev/2b4b289c1abb -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Changes by Benjamin Peterson benja...@python.org: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Todd Rovito added the comment: Terry, On my Mac with hg revert -a and hg pull -u the patch fails to apply on CallTips.py and PathBrowser.py under the latest version of Python 3.4. Here is the output when I try to apply the patch: rovitotv-pc:py34 rovitotv$ hg import --no-commit /Volumes/SecurePython3/source/15392idletests.diff applying /Volumes/SecurePython3/source/15392idletests.diff patching file Lib/idlelib/CallTips.py Hunk #1 FAILED at 263 1 out of 1 hunks FAILED -- saving rejects to file Lib/idlelib/CallTips.py.rej patching file Lib/idlelib/Itest/@template.txt patching file Lib/idlelib/Itest/__init__.py patching file Lib/idlelib/Itest/test_calltips.py patching file Lib/idlelib/Itest/test_pathbrowser.py patching file Lib/idlelib/PathBrowser.py Hunk #1 FAILED at 94 1 out of 1 hunks FAILED -- saving rejects to file Lib/idlelib/PathBrowser.py.rej patching file Lib/test/test_idle.py adding Lib/idlelib/Itest/@template.txt adding Lib/idlelib/Itest/__init__.py adding Lib/idlelib/Itest/test_calltips.py adding Lib/idlelib/Itest/test_pathbrowser.py adding Lib/test/test_idle.py abort: patch failed to apply I even tried using the tr command to remove the ^M characters from the .diff file and that still didn't allow me to apply the patch. Maybe it is my setup??? It is late here so I am going to bed but will play with it some more tomorrow. Thanks for your hard work, the patch looks like a good start. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Ezio Melotti added the comment: Have you tried applying it to 3.3? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15392] Create a unittest framework for IDLE
Terry J. Reedy added the comment: Todd, the last two commits, both rather trivial, I merged from 3.3 to 3.4 would not apply for no reason I could see. I wonder is there is something wrong with the repository. I wrote about the problem on the committer's list a few days ago, but got no response yet. It probably fell thru the cracks. I will try applying to 3.4 on windows tomorrow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
