[issue41354] filecmp.cmp documentation does not match actual code
Scott added the comment: I suggest changing the documentation rather than the code. The mix up is in the wording. Documentation below "If shallow is true, files with identical os.stat() signatures are taken to be equal. Otherwise, the contents of the files are compared." The "Otherwise" appears to be referencing the "If shallow is true" cause, when it should be referring to the equality of the _sig()s. Proposed Change "If shallow is true, files with identical os.stat() signatures are taken to be equal. If they are not equal, the contents of the files are compared." -- nosy: +FreeSandwiches ___ Python tracker <https://bugs.python.org/issue41354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32966] Python 3.6.4 - 0x80070643 - Fatal Error during installation
New submission from Scott : Installing Python 3.6.4, Windows 10 64bit, exits installer and dumps the following error code to log. [18B8:4394][2018-02-27T15:41:06]i399: Apply complete, result: 0x80070643, restart: None, ba requested restart: No 0x80070643 - Fatal Error during installation Attempted Command line installation as Administrator, installation standard methods as Administrator -- components: Installation files: Python 3.6.4 (64-bit)_20180227154057.log messages: 313027 nosy: exceltw priority: normal severity: normal status: open title: Python 3.6.4 - 0x80070643 - Fatal Error during installation type: crash versions: Python 3.6 Added file: https://bugs.python.org/file47464/Python 3.6.4 (64-bit)_20180227154057.log ___ Python tracker <https://bugs.python.org/issue32966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
sys.settrace closure interaction bug
The code below exhibits different behavior depending on whether it invokes sys.settrace ('-t' option) or not. This means that (in a more complicated case) debugging the code (which uses sys.settrace) makes it fail. Any ideas?
""" Demonstrace that tracing messes up curried class definitions """
# Some simple command line parsing: -t or --trace means trace, nothing means don't trace
import sysdef usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]' sys.exit( 1 )
if 1 == len( sys.argv ):
passelif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace': def trace ( frame, event, arg ):
# print frame, event, arg
return trace sys.settrace( trace )
else: usage( )
else: usage( )
# The test: define a class factory with a curried member function
def the_factory( parm1 ):
class the_class( object ): def curried( self ): return parm1
return the_class
x = the_factory( 42 )y = x( )
try: x.parm1
print "Failure: x (the manufactured class) has attribute parm1?!"
except AttributeError: print "Success with the manufactured class!"
try:
y.parm1 print "Failure: y (the instance) has attribute parm1?!"
except AttributeError: print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment:
I messed up while generating cross-2.5.1.patch last time.
Added a hackish way to set "disabled_module_list" in setup.py from
corresponding environment variable.
Added file: http://bugs.python.org/file8628/cross-2.5.1.patch
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1597850>
_diff --exclude=configure -urN Python-2.5.1/configure.in Python-2.5.1-hacked/configure.in
--- Python-2.5.1/configure.in 2007-03-12 18:50:51.0 +0800
+++ Python-2.5.1-hacked/configure.in 2007-10-27 14:31:18.0 +0800
@@ -9,6 +9,11 @@
AC_CONFIG_SRCDIR([Include/object.h])
AC_CONFIG_HEADER(pyconfig.h)
+# find compiler while respecting --host setting
+AC_CANONICAL_HOST()
+AC_CHECK_TOOLS(CC,gcc cc)
+AC_CHECK_TOOLS(CXX,g++ c++)
+
dnl This is for stuff that absolutely must end up in pyconfig.h.
dnl Please use pyport.h instead, if possible.
AH_TOP([
@@ -163,8 +168,8 @@
# Set name for machine-dependent library files
AC_SUBST(MACHDEP)
AC_MSG_CHECKING(MACHDEP)
-if test -z "$MACHDEP"
-then
+if test -z "$MACHDEP"; then
+if test "$cross_compiling" = "no"; then
ac_sys_system=`uname -s`
if test "$ac_sys_system" = "AIX" -o "$ac_sys_system" = "Monterey64" \
-o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
@@ -172,6 +177,23 @@
else
ac_sys_release=`uname -r`
fi
+else
+ m=`$CC -dumpmachine`
+ changequote(<<, >>)#dnl
+ ac_sys_system=`expr "$m" : "[^-]*-\([^-]*\)"`
+ changequote([, ])#dnl
+
+
+ case $ac_sys_system in
+ cygwin*) ac_sys_system=`echo $ac_sys_system | sed s/cygwin/CYGWIN/g `;;
+ darwin*) ac_sys_system=`echo $ac_sys_system | sed s/darwin/Darwin/g `;;
+ freebsd*) ac_sys_system=`echo $ac_sys_system | sed s/freebsd/FreeBSD/g `;;
+ linux*) ac_sys_system=`echo $ac_sys_system | sed s/linux/Linux/g `;;
+ esac
+
+
+fi
+
ac_md_system=`echo $ac_sys_system |
tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
ac_md_release=`echo $ac_sys_release |
@@ -419,8 +441,8 @@
if test -z "$CXX"
then
case "$CC" in
-gcc)AC_PATH_PROG(CXX, [g++], [g++], [notfound]) ;;
-cc) AC_PATH_PROG(CXX, [c++], [c++], [notfound]) ;;
+gcc)AC_CHECK_TOOL(CXX, [g++], [notfound]) ;;
+cc) AC_CHECK_TOOL(CXX, [c++], [notfound]) ;;
esac
if test "$CXX" = "notfound"
then
@@ -429,7 +451,7 @@
fi
if test -z "$CXX"
then
- AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
+ AC_CHECK_TOOLS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
if test "$CXX" = "notfound"
then
CXX=""
@@ -480,9 +502,11 @@
then
AC_MSG_RESULT(yes)
BUILDEXEEXT=.exe
+case_sensitive=no
else
- AC_MSG_RESULT(no)
- BUILDEXEEXT=$EXEEXT
+AC_MSG_RESULT(no)
+BUILDEXEEXT=$EXEEXT
+case_sensitive=yes
fi
rmdir CaseSensitiveTestDir
@@ -681,9 +705,9 @@
AC_MSG_RESULT($LDLIBRARY)
-AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, ar aal, ar)
+# find tools while respecting --host setting
+AC_CHECK_TOOL(RANLIB,ranlib)
+AC_CHECK_TOOLS(AR,ar aal,ar)
AC_SUBST(SVNVERSION)
AC_CHECK_PROG(SVNVERSION, svnversion, found, not-found)
@@ -801,7 +825,7 @@
AC_TRY_RUN([int main() { return 0; }],
ac_cv_no_strict_aliasing_ok=yes,
ac_cv_no_strict_aliasing_ok=no,
- ac_cv_no_strict_aliasing_ok=no)
+ ac_cv_no_strict_aliasing_ok=yes)
CC="$ac_save_cc"
AC_MSG_RESULT($ac_cv_no_strict_aliasing_ok)
if test $ac_cv_no_strict_aliasing_ok = yes
@@ -3345,30 +3369,19 @@
AC_MSG_RESULT(no)
)
-AC_MSG_CHECKING(for /dev/ptmx)
-
-if test -r /dev/ptmx
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTMX, 1,
- [Define if we have /dev/ptmx.])
-else
- AC_MSG_RESULT(no)
-fi
-
-AC_MSG_CHECKING(for /dev/ptc)
-
-if test -r /dev/ptc
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTC, 1,
- [Define if we have /dev/ptc.])
-else
- AC_MSG_RESULT(no)
-fi
+AC_CHECK_FILE(/dev/ptmx,
+ [AC_DEFINE(HAVE_DEV_PTMX, 1,
+ [Define if we have /dev/ptmx.])],
+ [])
+
+AC_CHECK_FILE(/dev/ptc,
+ [AC_DEFINE(HAVE_DEV_PTC, 1,
+ [Define if we have /dev/ptc.])],
+ [])
AC_MSG_CHECKING(for %zd printf() format support)
-AC_TRY_RUN([#include
+AC_CACHE_VAL(ac_cv_printf_zd_format,
+ AC_TRY_RUN([#include
#include
#include
@@ -3400,7 +3413,7 @@
}],
[AC_MSG_RESULT(yes)
AC_DEFINE(PY_FORMAT_SIZE_T, "z", [Define to printf format modifier for Py_ssize_t])],
- AC_MSG_RESULT(no))
+ AC_MSG_RESULT(no)))
AC_CHECK_TYPE(socklen_t,,
AC_DEFINE(socklen_t,int,
@@ -3430,6 +3443,63 @@
done
AC_MSG_RESULT(done)
+# Cross compiling
+AC_SUBST(cross_compiling)
+
+if test "$cross_compiling" = "yes"; then
+
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment:
Grumble, uploaded wrong version of patch.
Added file: http://bugs.python.org/file8629/cross-2.5.1.patch
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1597850>
_diff -urN --exclude configure --exclude 'config.*' Python-2.5.1/configure.in Python-2.5.1-hacked/configure.in
--- Python-2.5.1/configure.in 2007-03-12 18:50:51.0 +0800
+++ Python-2.5.1-hacked/configure.in 2007-10-27 16:46:39.0 +0800
@@ -9,6 +9,11 @@
AC_CONFIG_SRCDIR([Include/object.h])
AC_CONFIG_HEADER(pyconfig.h)
+# find compiler while respecting --host setting
+AC_CANONICAL_HOST()
+AC_CHECK_TOOLS(CC,gcc cc)
+AC_CHECK_TOOLS(CXX,g++ c++)
+
dnl This is for stuff that absolutely must end up in pyconfig.h.
dnl Please use pyport.h instead, if possible.
AH_TOP([
@@ -163,8 +168,8 @@
# Set name for machine-dependent library files
AC_SUBST(MACHDEP)
AC_MSG_CHECKING(MACHDEP)
-if test -z "$MACHDEP"
-then
+if test -z "$MACHDEP"; then
+if test "$cross_compiling" = "no"; then
ac_sys_system=`uname -s`
if test "$ac_sys_system" = "AIX" -o "$ac_sys_system" = "Monterey64" \
-o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
@@ -172,6 +177,23 @@
else
ac_sys_release=`uname -r`
fi
+else
+ m=`$CC -dumpmachine`
+ changequote(<<, >>)#dnl
+ ac_sys_system=`expr "$m" : "[^-]*-\([^-]*\)"`
+ changequote([, ])#dnl
+
+
+ case $ac_sys_system in
+ cygwin*) ac_sys_system=`echo $ac_sys_system | sed s/cygwin/CYGWIN/g `;;
+ darwin*) ac_sys_system=`echo $ac_sys_system | sed s/darwin/Darwin/g `;;
+ freebsd*) ac_sys_system=`echo $ac_sys_system | sed s/freebsd/FreeBSD/g `;;
+ linux*) ac_sys_system=`echo $ac_sys_system | sed s/linux/Linux/g `;;
+ esac
+
+
+fi
+
ac_md_system=`echo $ac_sys_system |
tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
ac_md_release=`echo $ac_sys_release |
@@ -419,8 +441,8 @@
if test -z "$CXX"
then
case "$CC" in
-gcc)AC_PATH_PROG(CXX, [g++], [g++], [notfound]) ;;
-cc) AC_PATH_PROG(CXX, [c++], [c++], [notfound]) ;;
+gcc)AC_CHECK_TOOL(CXX, [g++], [notfound]) ;;
+cc) AC_CHECK_TOOL(CXX, [c++], [notfound]) ;;
esac
if test "$CXX" = "notfound"
then
@@ -429,7 +451,7 @@
fi
if test -z "$CXX"
then
- AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
+ AC_CHECK_TOOLS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
if test "$CXX" = "notfound"
then
CXX=""
@@ -480,9 +502,11 @@
then
AC_MSG_RESULT(yes)
BUILDEXEEXT=.exe
+case_sensitive=no
else
- AC_MSG_RESULT(no)
- BUILDEXEEXT=$EXEEXT
+AC_MSG_RESULT(no)
+BUILDEXEEXT=$EXEEXT
+case_sensitive=yes
fi
rmdir CaseSensitiveTestDir
@@ -681,9 +705,9 @@
AC_MSG_RESULT($LDLIBRARY)
-AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, ar aal, ar)
+# find tools while respecting --host setting
+AC_CHECK_TOOL(RANLIB,ranlib)
+AC_CHECK_TOOLS(AR,ar aal,ar)
AC_SUBST(SVNVERSION)
AC_CHECK_PROG(SVNVERSION, svnversion, found, not-found)
@@ -801,7 +825,7 @@
AC_TRY_RUN([int main() { return 0; }],
ac_cv_no_strict_aliasing_ok=yes,
ac_cv_no_strict_aliasing_ok=no,
- ac_cv_no_strict_aliasing_ok=no)
+ ac_cv_no_strict_aliasing_ok=yes)
CC="$ac_save_cc"
AC_MSG_RESULT($ac_cv_no_strict_aliasing_ok)
if test $ac_cv_no_strict_aliasing_ok = yes
@@ -3345,30 +3369,19 @@
AC_MSG_RESULT(no)
)
-AC_MSG_CHECKING(for /dev/ptmx)
-
-if test -r /dev/ptmx
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTMX, 1,
- [Define if we have /dev/ptmx.])
-else
- AC_MSG_RESULT(no)
-fi
-
-AC_MSG_CHECKING(for /dev/ptc)
-
-if test -r /dev/ptc
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTC, 1,
- [Define if we have /dev/ptc.])
-else
- AC_MSG_RESULT(no)
-fi
+AC_CHECK_FILE(/dev/ptmx,
+ [AC_DEFINE(HAVE_DEV_PTMX, 1,
+ [Define if we have /dev/ptmx.])],
+ [])
+
+AC_CHECK_FILE(/dev/ptc,
+ [AC_DEFINE(HAVE_DEV_PTC, 1,
+ [Define if we have /dev/ptc.])],
+ [])
AC_MSG_CHECKING(for %zd printf() format support)
-AC_TRY_RUN([#include
+AC_CACHE_VAL(ac_cv_printf_zd_format,
+ AC_TRY_RUN([#include
#include
#include
@@ -3400,7 +3413,7 @@
}],
[AC_MSG_RESULT(yes)
AC_DEFINE(PY_FORMAT_SIZE_T, "z", [Define to printf format modifier for Py_ssize_t])],
- AC_MSG_RESULT(no))
+ AC_MSG_RESULT(no)))
AC_CHECK_TYPE(socklen_t,,
AC_DEFINE(socklen_t,int,
@@ -3430,6 +3443,63 @@
done
AC_MSG_RESULT(done)
+# Cross compiling
+AC_SUBST(cross_compiling)
+
+if test "$cross_compiling" = "yes"; then
+AC_MSG_CHECKING(cc for build)
+CC_FOR_BUILD="${CC_FOR_BUILD-cc}"
+else
+CC_FOR_BUILD="
[issue10639] reindent.py should not convert newlines
Scott Dial added the comment: I haven't seen anyone use a side-effect-less statement (a string) as a comment before, but I doubt that is an approved style for the CPython codebase. Please change the string preceeding the spec_line definition into a proper comment. -- nosy: +scott.dial ___ Python tracker <http://bugs.python.org/issue10639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10432] concurrent.futures.as_completed() spins waiting for futures to complete
New submission from Scott Dial : The code in as_completed() waits on a FIRST_COMPLETED event, which means that after the first future completes, it will no longer wait at all. The proposed patch adds a _AsCompletedWaiter and uses a lock to swap out the finished list and reset the event. This is a difficult problem to create a test case for without adding intrusive code to as_completed() to count how many times it loops or create a mock Event object that counts it, so I have not proposed a test. -- components: Library (Lib) files: futures-r86476.patch keywords: patch messages: 121280 nosy: scott.dial priority: normal severity: normal status: open title: concurrent.futures.as_completed() spins waiting for futures to complete type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file19615/futures-r86476.patch ___ Python tracker <http://bugs.python.org/issue10432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10432] concurrent.futures.as_completed() spins waiting for futures to complete
Scott Dial added the comment: Good catch. I suppose it was inevitable when I transferred my changes into a SVN checkout that I missed something. Nevertheless, your changeset in r86491 matches my own. Thanks! -- ___ Python tracker <http://bugs.python.org/issue10432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11414] Add import fix for email.Message
New submission from Scott Kitterman : email.Message was dropped in python3. from email.Message import Message now fails. Changing email.Message to email.message seems to be all that's needed. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 130179 nosy: kitterma priority: normal severity: normal status: open title: Add import fix for email.Message ___ Python tracker <http://bugs.python.org/issue11414> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11414] Add import fix for email.Message
Scott Kitterman added the comment: Agreed, but email.Message was never marked deprecated so there's likely old code out there that's never been updated (which is how I ran into this). This would be, I think, a very low risk transformation to apply. -- ___ Python tracker <http://bugs.python.org/issue11414> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial added the comment: I've updated the patch to apply to the current tip. (This patch was an opportunity for me to update to an Hg workflow.) Alexander, I disagree with you about the tests. The unittests use the exact same pattern/model that testIteration uses. I find your complaint that a unittest, which does test the feature under question, is not good enough, despite the prevailing unittests being designed in the same manner, to be absurd. Practicality beats purity -- a test that works is better than no test at all. By rejecting unittests on the merits of its coding style, you are creating a double-standard for people like me (outside of the core committers), which eventually wears out my interest in helping you get this improvement into your project. I have been chased around this obstacle course before. For example, issue5949, when I was asked to provide unittests for a module that had *none*, for a 3-line patch that nobody disagreed it being correct. I had a vested interest in jumping through the obstacles of getting that patch in, but here I am again being blocked from making a 3-line patch, except this time, purely for stylistic reasons. -- Added file: http://bugs.python.org/file21060/issue1706039-py3k.patch ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11450] Py_GetBuildInfo() truncates when there are many hg tags
New submission from Scott Dial : I'm not sure if it's intended to be a supported workflow, but I personally have come to like using "mq" for projects where I am an outsider submitting small changes as patches. However, this appears to be a broken workflow due to way getbuildinfo module choose to limit the buildinfo string to 50 characters: $ hg qnew dummy-patch $ echo "/* dummy change */" >> Modules/getbuildinfo.c $ ./python -c 'import sys; print(sys.version)' 3.3a0 (dummy-patch qbase qtip tip:191f047a07b4+, Mar 9 ) [GCC 4.4.5] This breaks the platform module and therefore breaks the regrtest code, which makes it a show-stopper for using mq to manage your workflow. Is there any reason that length of buildinfo can't be chosen at compile-time based on the sizeof(HGTAG)? -- components: Build messages: 130432 nosy: scott.dial priority: normal severity: normal status: open title: Py_GetBuildInfo() truncates when there are many hg tags type: feature request ___ Python tracker <http://bugs.python.org/issue11450> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial added the comment: I'm well aware of the limited use of Py_UniversalNewlineFgets() in py3k, but it remains the case that it is a public API that fails to work correctly under the conditions specified by the reporter, and Alexander confirmed the original patch fixed the issue. AFAICT, there no longer are any test cases (beyond the indirect testing of the dependent code) for Py_UniversalNewlineFgets(). One of the issues with applying the patch to tip was due to commenting out some code in it: /* if ( c == EOF && skipnextlf ) newlinetypes |= NEWLINE_CR; */ For issue8914, which really should've just deleted those two lines, but there was not such an extensive review of that change. The unittests have there own merit. The file object API is supposed to behave in the manner that the tests exercise them. There are currently no tests that would inform us if any change broke this documented behavior. If you want to split the patch in two to treat them as independent items, then fine. Otherwise, close the issue as WONTFIX due to obsolescence. -- ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11492] email.header.Header doesn't fold headers
New submission from Scott Kitterman : Header folding is very different (non-existent as far as I've found so far) in Python3. Here's a short example: #!/usr/bin/python # -*- coding: ISO-8859-1 from email.header import Header hdrin = 'Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT)' print(Header(hdrin)) With python2.6 the output is: Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) With python3.1 or 3.2 the output is one line: Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) This makes it very difficult to write header processing code that works for both Python2 and Python3 even if one can fold headers at all in Python3. -- components: None messages: 130793 nosy: kitterma priority: normal severity: normal status: open title: email.header.Header doesn't fold headers ___ Python tracker <http://bugs.python.org/issue11492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11500] Fixes failing urllib2 proxy tests on OSX
New submission from Scott Wilson : Fixes a bug in the os x proxy bypass code for fully qualified IP addresses in the proxy exception list. Tests that fail on os x without this patch: test_urllib2.HandlerTests.test_proxy_https test_urllib2.HandlerTests.test_proxy_https_proxy_authorization Will create a separate issue to improve test coverage in this area. -- assignee: ronaldoussoren components: Macintosh files: proxy_bypass_osx.diff keywords: patch messages: 130841 nosy: ronaldoussoren, rswilson priority: normal severity: normal status: open title: Fixes failing urllib2 proxy tests on OSX versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file21120/proxy_bypass_osx.diff ___ Python tracker <http://bugs.python.org/issue11500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11500] Fixes failing urllib2 proxy tests on OSX
Changes by Scott Wilson : -- nosy: +orsenthil -ronaldoussoren type: -> behavior ___ Python tracker <http://bugs.python.org/issue11500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11500] Fixes failing urllib2 proxy tests on OSX
Scott Wilson added the comment: This patch adds test coverage to the osx proxy bypass code and includes the previous one line patch. Also adds a test for the proxy_no=* case. -- Added file: http://bugs.python.org/file21134/proxy_bypass_osx_w_tests.diff ___ Python tracker <http://bugs.python.org/issue11500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11511] Proposal for exposing proxy bypass settings in ProxyHandler
New submission from Scott Wilson : Several proxy tests in test_urllib2_localnet were failing for me on osx due to spurious interference of my configured proxy settings. Attaching a patch that proposes exposing the proxy bypass settings in the same manner as the proxies when constructing ProxyHandler. An alternate solution to just fix the tests would be to monkeypatch urllib.request.proxy_bypass = urllib.request.proxy_bypass_environment in test_urllib2_localnet to avoid interference from mac/windows settings. -- components: Library (Lib) files: proxy_bypass_override.diff keywords: patch messages: 130919 nosy: orsenthil, rswilson priority: normal severity: normal status: open title: Proposal for exposing proxy bypass settings in ProxyHandler type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file21148/proxy_bypass_override.diff ___ Python tracker <http://bugs.python.org/issue11511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Scott Dial added the comment: Antoine Pitrou wrote: > It would be nice if it were enabled by default for fatal errors (and asserts > perhaps?). I feel like a broken record. This code hardcodes fd=2 as a write target on crash, which is not safe thing to do at all. You can argue that adopters of Python 3.3 should have to deal with that fact, but it's obscure and there is no way to warn anyone about it except by putting a NEWS item, and if the PyCapsule discussion on python-dev have taught us anything: even well meaning programmers miss these things all the time. I have stated this repeatedly on the other issues for this same discussion. I think creating a completely new issue for this same topic has segmented the discussion unfortunately. I wrote a much longer and more thoughtful explanation of why faulthandler writes to the wrong "thing" here: http://bugs.python.org/msg124381 AFAICT, Victor has addressed my issue by giving programmers yet another interface to configure (that they may or may not be aware of). So, the only way this acceptable to me is if it's off by default and a programmer who wants this functionality opts-in and has taken care to make sure it does the right thing. My suggestion that faulthandler needs to find a way to be coupled to "sys.stderr" still stands. -- nosy: +scott.dial ___ Python tracker <http://bugs.python.org/issue11393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11492] email.header.Header doesn't fold headers
Scott Kitterman added the comment: Not so fast ... I may have done this wrong, but I get: print(Header(hdrin,maxlinelen=78)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) all in one line with python3.2, so maxlinelen doesn't appear to do anything. With python2.7 it seems to when invoked that way: Python 2.7.1+ (r271:86832, Mar 24 2011, 00:39:14) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.header import Header >>> hdrin = 'Received: from mailout00.controlledmail.com >>> (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com >>> (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar >>> 2011 23:46:05 -0400 (EDT)' >>> print(Header(hdrin)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) >>> print(Header(hdrin, maxlinelen=30)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for ; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) -- resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue11492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment: I just hit the same issue. This seems to work: Modified:Lib/tarfile.py === ---Lib/tarfile.py 2011-04-26 20:36:33 UTC (rev 49502) +++Lib/tarfile.py 2011-04-26 21:01:24 UTC (rev 49503) @@ -2239,6 +2239,8 @@ if hasattr(os, "symlink") and hasattr(os, "link"): # For systems that support symbolic and hard links. if tarinfo.issym(): +if os.path.exists(targetpath): +os.unlink(targetpath) os.symlink(tarinfo.linkname, targetpath) else: # See extract(). -- nosy: +Scott.Leerssen ___ Python tracker <http://bugs.python.org/issue10761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment:
It happens on RedHat and CentOS 5, but I suspect it would happen on any Unix
variant. Here's a test that exacerbates the issue:
#
# test_tarfile.py
#
# Description:
# tests for python tarfile module
#
# $Id$
#
import os
import shutil
import tarfile
import tempfile
def test_tar_overwrites_symlink():
d = tempfile.mkdtemp()
try:
new_dir_name = os.path.join(d, 'newdir')
archive_name = os.path.join(d, 'newdir.tar')
os.mkdir(new_dir_name)
source_file_name = os.path.join(new_dir_name, 'source')
target_link_name = os.path.join(new_dir_name, 'symlink')
with open(source_file_name, 'w') as f:
f.write('something\n')
os.symlink(source_file_name, target_link_name)
with tarfile.open(archive_name, 'w') as tar:
for f in [source_file_name, target_link_name]:
tar.add(f, arcname=os.path.basename(f))
# this should not raise OSError: [Errno 17] File exists
with tarfile.open(archive_name, 'r') as tar:
tar.extractall(path=new_dir_name)
finally:
shutil.rmtree(d)
--
___
Python tracker
<http://bugs.python.org/issue10761>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment: It turns out that my fix was at least one byte short of complete. If the target pathname is a broken symlink, os.path.exists() returns False, and the OSError is raised. I should have used os.path.lexists(). Also, I believe the same problem exists for the hardlink case a few lines below. -- ___ Python tracker <http://bugs.python.org/issue10761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment: here is a diff of a better fix based on the previous patch: Index: tarfile.py === --- tarfile.py (revision 49758) +++ tarfile.py (working copy) @@ -2239,12 +2239,14 @@ if hasattr(os, "symlink") and hasattr(os, "link"): # For systems that support symbolic and hard links. if tarinfo.issym(): -if os.path.exists(targetpath): +if os.path.lexists(targetpath): os.unlink(targetpath) os.symlink(tarinfo.linkname, targetpath) else: # See extract(). if os.path.exists(tarinfo._link_target): +if os.path.lexists(targetpath): +os.unlink(targetpath) os.link(tarinfo._link_target, targetpath) else: self._extract_member(self._find_link_target(tarinfo), targetpath) -- ___ Python tracker <http://bugs.python.org/issue10761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment:
tests that verify the bug/fix:
def test_extractall_broken_symlinks(self):
# Test if extractall works properly when tarfile contains symlinks
tempdir = os.path.join(TEMPDIR, "testsymlinks")
temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
os.mkdir(tempdir)
try:
source_file = os.path.join(tempdir,'source')
target_file = os.path.join(tempdir,'symlink')
with open(source_file,'w') as f:
f.write('something\n')
os.symlink(source_file, target_file)
tar = tarfile.open(temparchive,'w')
tar.add(target_file, arcname=os.path.basename(target_file))
tar.close()
# remove the real file
os.unlink(source_file)
# Let's extract it to the location which contains the symlink
tar = tarfile.open(temparchive,'r')
# this should not raise OSError: [Errno 17] File exists
try:
tar.extractall(path=tempdir)
except OSError:
self.fail("extractall failed with broken symlinked files")
finally:
tar.close()
finally:
os.unlink(temparchive)
shutil.rmtree(TEMPDIR)
def test_extractall_hardlinks(self):
# Test if extractall works properly when tarfile contains symlinks
TEMPDIR = tempfile.mkdtemp()
tempdir = os.path.join(TEMPDIR, "testsymlinks")
temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
os.mkdir(tempdir)
try:
source_file = os.path.join(tempdir,'source')
target_file = os.path.join(tempdir,'symlink')
with open(source_file,'w') as f:
f.write('something\n')
os.link(source_file, target_file)
tar = tarfile.open(temparchive,'w')
tar.add(source_file, arcname=os.path.basename(source_file))
tar.add(target_file, arcname=os.path.basename(target_file))
tar.close()
# Let's extract it to the location which contains the symlink
tar = tarfile.open(temparchive,'r')
# this should not raise OSError: [Errno 17] File exists
try:
tar.extractall(path=tempdir)
except OSError:
self.fail("extractall failed with linked files")
finally:
tar.close()
finally:
os.unlink(temparchive)
shutil.rmtree(TEMPDIR)
--
___
Python tracker
<http://bugs.python.org/issue10761>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10761] tarfile.extractall fails to overwrite symlinks
Scott Leerssen added the comment: oops... I left some of my local edits in those tests. be sure to fix the TEMPDIR use if you add these into the tarfile tests. -- ___ Python tracker <http://bugs.python.org/issue10761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12088] tarfile.extractall fails to overwrite unresolved symlinks and hard links
New submission from Scott Leerssen : I'm opening this as a continuation of issue10761 since it was closed as fixed, and there's a bit more work to do there. The fix for issue10761 was incomplete. It did not handle the case where the symlink being overwritten did not resolve to another file (i.e. a "broken" link). It also did not address the same issues with hard links. The comments starting at http://bugs.python.org/issue10761#msg135924 detail the updates needed to complete this fix. -- components: Library (Lib) messages: 136091 nosy: Scott.Leerssen priority: normal severity: normal status: open title: tarfile.extractall fails to overwrite unresolved symlinks and hard links type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12088> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12144] cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
New submission from Scott Wimer : When cookielib.CookieJar().make_cookies is used to extract cookies from a urllib2 response, it crashes when it encounters a 'Set-Cookie' header entry that has an 'expires' attribute. This crash occurs because the expires time is evaluated against the '_now' attribute of the CookieJar instance -- an attribute which is not set unless CookieJar().extract_cookies() was called previously. Attached is a script that triggers this bug. -- components: Library (Lib) files: cookielib-crash.py messages: 136497 nosy: Scott.Wimer priority: normal severity: normal status: open title: cookielib.CookieJar.make_cookies fails for cookies with 'expires' set type: crash versions: Python 2.6 Added file: http://bugs.python.org/file22054/cookielib-crash.py ___ Python tracker <http://bugs.python.org/issue12144> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12144] cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
Scott Wimer added the comment: The actual error is triggered by line 1507 in '_cookie_from_cookie_tuple()'. An easy fix is to move the setting of '_now' on line 1636 into the 'make_cookies()' method. That addresses this problem and doesn't look like it would introduce any negative side effects. -- ___ Python tracker <http://bugs.python.org/issue12144> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12144] cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
Scott Wimer added the comment: Forgot to include the patch. Oops. -- keywords: +patch Added file: http://bugs.python.org/file22055/cookielib-crash.patch ___ Python tracker <http://bugs.python.org/issue12144> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10430] _sha.sha().digest() method is endian-sensitive. and hexdigest()
Scott Dial added the comment:
Got a test case that demonstrates a failure? Looks like it works to me...
$ uname -ip
sparc SUNW,Sun-Fire-280R
$ python -c 'import sys; print sys.byteorder'
big
$ python -c 'import sha; print sha.new(open("test", "rb").read()).hexdigest()'
851faf3199d27200abf2750c14ae6451696216a9
$ sha1sum -b test
851faf3199d27200abf2750c14ae6451696216a9 *test
# uname -ip
AMD Sempron(tm) Processor 2800+ AuthenticAMD
# python -c 'import sys; print sys.byteorder'
little
# python -c 'import sha; print sha.new(open("test", "rb").read()).hexdigest()'
851faf3199d27200abf2750c14ae6451696216a9
# sha1sum -b /tmp/test
851faf3199d27200abf2750c14ae6451696216a9 *test
I think your code analysis is wrong. Perhaps you missed the call to
longReverse(), which does endianness byte-swapping, at the beginning of the
sha_transform() that specifically is commented: "When run on a little-endian
CPU we need to perform byte reversal on an array of longwords."
--
nosy: +scott.dial
___
Python tracker
<http://bugs.python.org/issue10430>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial added the comment: The patch includes unittests; the issue is that the tests pass without the changes. That is an entirely different state to be in. The tests should be committed unless somebody wants to object to the behavior that they are testing (although I believe this behavior is already codified in documentation). If the tests start failing on someone's platform, then you have a patch already waiting to be applied. Nevertheless, I don't see the harm in the patch as-is, because it is a quite innocuous change to Py_UniversalNewlineFgets(), unless (again) you want to argue about the correctness of that change despite no test failing. -- ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial added the comment: FYI, in v10, +#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0])) +static fault_handler_t fault_handlers[4]; , should use "NFAULT_SIGNALS" instead of "4". However, this bit of code bothers me a lot: +const int fd = 2; /* should be fileno(stderr) */ To assume that fd=2 is the write place to be writing bytes is assuming quite a bit about the state of the application. It is not unusual at all to close 0,1,2 when writing daemons, which frees them up to be assigned to *anything*. For all you know, fd=2 currently is a network socket that you will be throwing gibberish at, or worse it could be a block device that you are writing gibberish on. The closest discussion I could find on this subject was on the libstdc++ mailing-list with regard to their verbose termination code: http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02388.html AFAICT, their conclusion was that the only reasonable solution was to write to the stderr FILE since it was the only thing that is guaranteed to make sense always (even though it may fail). Their situation is different in that they are handling a C++ exception, so they don't have to stick to async-safe functions, but absent that extra difficulty, I believe the reasoning is the same. The analogous situation exists in Python, in that sys.stderr(*) represents where the application programmer expects "stderr" writing to go. I think you need to arrange to know what the fd number for that object is or this patch is unacceptable in the vein of "wrote garbage to my harddrive and destroyed my data" sort. I'm not sure there is a safe way to know what the fileno for "sys.stderr" is because it can be anything, including an object whose fileno changes over time. However, I think it would be fair to support only built-in io types that are obviously safe, since you could cache the fileno() value at assignment to use in your fault handler. (*) Or perhaps __stderr__ if stderr is None or an unsupported type? -- nosy: +scott.dial ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
New submission from Scott Urban : The python sqlite module automatically commits open transactions when it encounters a DDL statement. This is unnecessary; DDL is transactional in my testing (see attached). Attached patch addresses the issue. Patch is against 2.6.1, but looking at Trunk in svn, it seems like the patch is needed and would apply. One issue I could foresee is that this behavior might depend on the sqlite version in use (I'm on 3.6.10). Patch also allows pragma statement. -- components: Library (Lib) files: pysql-transactions.2.diff keywords: patch messages: 124392 nosy: scott.urban priority: normal severity: normal status: open title: sqlite3 module should allow DDL statements in transactions type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file20118/pysql-transactions.2.diff ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Scott Urban added the comment: Here are some tests. -- Added file: http://bugs.python.org/file20119/test_sqlite_ddl.py ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial added the comment: On 12/20/2010 8:30 AM, STINNER Victor wrote: > Write into a closed file descriptor just does nothing. Closed file > descriptors > are not a problem. My issue not with a closed file descriptor, it is with an open file descriptor that is not what you think it is. >> For all you know, fd=2 currently is a network socket that you >> will be throwing gibberish at, or worse it could be a block device that >> you are writing gibberish on. > > The GNU libc has also a fault handler (source code: debug/segfault.c). It > uses > the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is > set (value stored in "fname" variable): open the specified file. The GNU libc segfault handler is *opt-in* via the SEGFAULT_SIGNALS environment variable. I do not know of a system where SEGFAULT_SIGNALS is a part of the default environment. I suspect the only time anyone uses that variable and code is if they are using the "catchsegv" tool, which comes with glibc. In any case, that developer should be aware of the implication of closing fd 2. > The FILE* type cannot be used because fprintf(), fputs(), ... are not signal- > safe. My point was that in C++, they have an object that an application developer more readily associates with "stderr" than fd 2. That writing to "stderr" leads to a write to fd 2 is incidental, because it's possible that "stderr" does *not* lead to a write to fd 2 and that writing to fd 2 would be a bad thing to do blindly. For instance, you can call freopen(path, mode, stderr) and fd 2 will end up closed and another fd will be the target of stderr. I don't believe POSIX guarantees that open() will not re-use fd 2. > The problem is to detect that stderr file descriptor changes (eg. closed, > duplicated, reopened, etc.). I don't think that it's possible to detect such > changes (with a portable function). When I said that, I hadn't fully investigated the intricacies of the io types. I was unaware that you could assign to "sys.stderr.buffer.raw" and change out the target fd. I assumed a BufferedWriter could not have the target stream changed out from beneath it. So, I don't have a solution to the problem of knowing the correct (if any) file descriptor to write to. If the argument is made that fd 2 is the right place for most Python applications, then there needs to be a programmatic way to disable this feature and/or tell it where to write, so that programs that daemonize can do the right thing. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Scott Urban added the comment: I find the way that the sqlite3 module handles transactions pretty surprising in general, but I agree that someone who got used to DDL not rolling back could in theory find this patch surprising. We will apply this patch to our python build because having DDL covered by a transactions is convenient for certain tasks. If anyone can think of a problem with this simple patch, I'd like to hear it. Thanks Scott -- ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial added the comment: On 12/22/2010 8:52 PM, STINNER Victor wrote: > Amaury asked for a sys.setsegfaultenabled() option: I think that the command > line option and the environment variable are enough. I really think you should think of it as a choice the developer of an application makes instead of a choice an application user makes. A setsegfaultenabled() could just be another step of initializing the application akin to setting up the logging module, for instance. In that situation, a function call has a much lower barrier for use than a CLI option or environment variable where you'd have to create a wrapper script. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial added the comment: On 12/22/2010 10:35 PM, STINNER Victor wrote: > Why do you think so? Can you give me an use case of > sys.setsegfaultenabled()? To feed back your own argument on python-dev: > How do you know that you application will crash? The idea is to give > informations to the user when an application crashs: the user can use > the backtrace or send it to the developer. Segmentation faults are > usually not (easilly) reproductible :-( So even if you enable the > fault handler, you may not be able to replay the crash. Or even > worse, the fault may not occurs at all when you enable the fault > handler... (Heisenbugs!) > After the discussion on python-dev, I don't think that the fault handler > should be enabled by default, but only for a single run. I agree that it should be disabled by default because of the potential do bad things if the application was not wrote with it in mind. But an application developer would be in a much better position to decide what the default should be for their application if they believe they will be able to get more useful bug reports from their users by enabling it. I thought that was your position, but if you no longer believe that, then I will not push for it. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8548] Building on CygWin 1.7: PATH_MAX redefined
Scott Rostrup added the comment: I just encountered this error in python 3.1.3 on cygwin 1.7. I used the same fix as jbinder. Old Modules/main.c (line 13): #if defined(MS_WINDOWS) || defined(__CYGWIN__) #include #ifdef HAVE_FCNTL_H #include #define PATH_MAX MAXPATHLEN #endif #endif I guess now cygwin is defining PATH_MAX, one possible fix with ifndef: #if defined(MS_WINDOWS) || defined(__CYGWIN__) #include #ifdef HAVE_FCNTL_H #include #ifndef #define PATH_MAX MAXPATHLEN #endif #endif #endif This compiled and worked for me and it appears jbinder as well. -- nosy: +Scott.Rostrup Added file: http://bugs.python.org/file20155/py_cygwin_build-3.1.3 ___ Python tracker <http://bugs.python.org/issue8548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10899] No function type annotations in the standard library
Scott Dial added the comment: Raymond Hettinger wrote: > I think those annotations should be replaced with comments. In your revisions, you didn't do anything but blow away the annotations despite what you said here, which is an unfortunate loss of information for implementers and users of those interfaces. -- nosy: +scott.dial ___ Python tracker <http://bugs.python.org/issue10899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
New submission from Scott M : New to Python; be gentle if I've simply missed something. i'M running on Windows XP, using a recently downloaded 2.7.1. I'm running by hitting F5 in IDLE. The attached .py creates 2 threads, one which updates a Tkinter label 10 times a second forever, and one which sleeps for a second and then thrashes the CPU for ~4 seconds, forever. I wrote this to see how Python dealt with CPU-pig threads, and was pleased to see both threads got to run in a decently interleaved way, even in the face of a tight loop. But at a random point, one of the threads (which one varies) stops running. The other continues fine. The problem manifests in less then 5 minutes (often less than 1). At least once, but not ever time, the thread that stopped gave a traceback: Exception in thread Thread-1: Traceback (most recent call last): File "D:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "F:\Python27\MyProjects\e.py", line 24, in run print "evil!" #<--- point 1 File "D:\Python27\lib\idlelib\rpc.py", line 595, in __call__ value = self.sockio.remotecall(self.oid, self.name, args, kwargs) File "D:\Python27\lib\idlelib\rpc.py", line 211, in remotecall return self.asyncreturn(seq) File "D:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn response = self.getresponse(seq, wait=0.05) File "D:\Python27\lib\idlelib\rpc.py", line 280, in getresponse response = self._getresponse(myseq, wait) File "D:\Python27\lib\idlelib\rpc.py", line 305, in _getresponse cvar = self.cvars[myseq] KeyError: 8680 BUT in some cases there wasn't a traceback (the last time there wasn't, it was BThread that had stopped running; the label was no longer updating.) If you comment out the print at point 2, or point 1, it seems to work fine, at least for as long as I cared to watch it. Also, I've noticed that if I close the app's window, that at least one thread keeps running and writing to the Python shell console. (One generally dies because the Tkinter label has gone away). They are both marked as daemonic; shouldn't they stop more or less instantly? -- components: Interpreter Core files: e.py messages: 126282 nosy: PythonInTheGrass priority: normal severity: normal status: open title: thread hang, possibly related to print type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file20409/e.py ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: It hasn't failed yet when run "straight". Here's the issue, though. I'm going to be introducing Python as the scripting language of choice, to a bunch of people who are less than fluent in programming. Because debugging is not an obvious concept to them, they are going to hunt for problems by sticking in print statements everywhere, and the environment is inherently multithreaded, so it's hard for me to imagine they won't experience this bug. I hit it in my very first multithreaded experiment. And I can't possibly ask them not to use IDLE - without syntax coloring and a friendly editor to show them which line is wrong, they will never get off the ground. It would be tolerable if there was at least a traceback, but if threads vanish silently, they will not realize it's a environment problem; they will either assume that they did something inexplicably wrong and that "scripting is too hard", or it will get around that I provided a "broken" solution. So even if it's "just the IDE", it's still life and death for this project. "Won't fix" probably means I have to abandon Python. -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10909] thread hang, possibly related to print
Scott M added the comment: Moving to 3.x means redoing large swaths of the extension I just wrote. It's only a couple thousand lines, but it was my first extension and it cost me a week of my life in Google, and it does a lot with strings. I haven't pulled down the source code for Python's internals yet, but from the one trace back I did get in the failing thread test app, the problem was inside print and it looked like it was inside the mechanism where print gets redirected. I hope the problem isn't anything as fundamental as the GIL, because that throws the stability of all of 2.7 into question (and it's been solid in all my tests; I do a lot with threads in my extension, all going after the GIL and diving into Python code.) -- ___ Python tracker <http://bugs.python.org/issue10909> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
New submission from Scott M :
Running on dual core Windows XP.
The function should draw a parabolicish shape for each click on launch. But if
you click Launch over and over, very fast, you get bizarre crashes instead:
Python.exe has encoutered a problem, yadda. tcl85.dll. It rarely takes many
clicks.
Apologies for the coding style; this has been hacked down from a larger app.
In the console window:
Exception in thread Thread-5:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 100, in arrival_122
self.label.config(text= str(message[0])+ " " + str(message[1]))
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure
return self._configure('configure', cnf, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name "source C:/Python27/tcl/tk8.5/menu.tcl"
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
self.app.arrival_122((self.target, y, z))
File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 125, in arrival_122
self.graph.create_line(self.trackCoordinates[tn], new_yz)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: invalid command name "line"
Also saw:
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad option "665.44997": must be addtag, bbox, bind, canvasx,
canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus,
gettags, icursor, index, insert, itemcget, itemconfigure, lower, move,
postscript, raise, scale, scan, select, type, xview, or yview
--
components: Tkinter
files: TkinterCrash.py
messages: 127201
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: Crash, 2.7.1, Tkinter and threads and line drawing
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20549/TkinterCrash.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: To make this more interesting, I'm trying to push for adoption of Python at a scripting tool where I work, and I uncovered this crasher in example code I was about to hand out, under the heading of "look how easy Python is". For obvious reasons I'm holding off on handing out the example; I won't get far selling Python if it crashes when drawing lines... if this is a result of something boneheaded I did, please slap me upside the head ASAP. Conversely if there's a quick fix possible, that will speed Python adoption where I work... thanks. -- ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment:
OK, now all calls to Tkinter are funneled to a single thread, through a queue.
(Technically there are two threads in Tkinter - one is parked in .mainloop(),
the other makes a call to Canvas.create_line and a call to Label.config.)
Different crash, but still a crash. This one seems to be mostly consistent; see
below and new attached code.
If you're going to tell me that Tkinter simply can never be called by any
thread other than the one animating mainloop - in other words, Tkinter calls
are only safe within Tkinter callbacks like a Button's command function - then
please suggest an alternative library that is sturdier. There's nothing I can
do about the fact that multiple threads produce independent data that has to go
onto a single graph.
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
ValueError: invalid literal for int() with base 10: 'None'
But once I got:
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "C:\Documents and
Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash2.py", line 68, in run
self.graph.create_line(element[0], element[1], element[2], element[3])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: can not find channel named "Nonefile13cad48"
--
Added file: http://bugs.python.org/file20576/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
Scott M added the comment: Alright. More digging turned up the Tkinter "after" function, aka WM_TIMER for Windowy people like me, and that plus a nonblocking queue get() gets all my drawing operations back into the mainLoop() thread. Voilà, no more crashes. Let me suggest that page one, sentence one of any Tkinter documentation should begin "Tkinter is not thread safe", with a link to an example of after() and nonblocking get(). I've changed the component to Documentation. This would save a few days for poor sods like me -- I'm used to low level Windows C++ GUI work, where any thread can call any SDK function at any time, and Windows sorts it all out. Having to force everything into a single thread, and then poll for my data (*GAG*), is something I thought died in the 80's. Is anyone looking at thread safe GUI libraries? -- assignee: -> docs@python components: +Documentation -Tkinter nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue11029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe. This is a bug.
New submission from Scott M : The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use. I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic. Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency. -- components: Tkinter messages: 127604 nosy: PythonInTheGrass priority: normal severity: normal status: open title: Tkinter is not thread safe. This is a bug. type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe (and that's... bad)
Scott M added the comment: I don't have an opinion on 1252236. I'm not certain it would help. I have an extension that runs a bunch of (alien) threads into Python code. The threads deliver information for all sorts of real world events, asynchronously. Multiple threads are used, because people occasionally want to do blocking operations in these alien threads, but still want to be able to handle other incoming information at full speed, with the other threads. If any of these threads attempts to update a Tkinter widgit - and this is the first thing I tried to do - then tkinter will except or crash in some horrible way, sooner or later. The attached .py (in Python 2.7.1) does it without any extensions. Click on Launch quickly 10-15 times; if it doesn't crash, kill and restart. It rarely takes more than 4-5 runs to get a traceback, or occasionally python itself just crashes. Bottom line, one thread in .mainloop() and another thread calling virtually any Tkinter function, even something as simple as .after(), is an invitation a crash. -- title: Tkinter is not thread safe -> Tkinter is not thread safe (and that's... bad) Added file: http://bugs.python.org/file20630/TkinterCrash2.py ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: I'll look into making the crash easier to reproduce this coming week. Is Tkinter's thread safety new? Because after I started getting crashes, I did my due diligence in Google and found a number of people writing about how it was necessary to use a Queue and Tkinter's after() timer, to draw from multiple threads. And in experiments in 2.7.1 on Windows, it turned out that it wasn't just the drawing calls from a thread other than the mainloop() thread, that invited a crash; even just trying to set an .after() timer from a different thread caused tracebacks, randomly. At any rate this is less of an issue now, for me at least. I'm putting together a small graphic library for my coworkers. It will have a tiny fraction of Tkinter's capabilities, it will be Windows-only and won't even have native Windows look and feel; but it will be completely, rock-solid, idiot-proof thread safe - any operation (including widget deletes), any thread, any time, with no polling or timers needed. My coworkers are not technical and will get instantly lost if I have to describe queues and timers just to draw a line on a screen. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment:
The new version runs 40 parabolas, then quits. I usually have to run this
version 20 times or so to get the crash, so be patient. In general if it's
going to crash it does so in the first 6 or so parabolas. Caveat: creates up to
40 threads, so a bit of a CPU pig. You may want to change the 40 in
(self.tracks > 40) to 8.
Here's one crash. I got this by double clicking the .py file from Windows
explorer, but I can get them with F5 in IDLE too.
---
UpdateStringProc should not be invoked for type cmdName
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Exception in thread Thread-6:
Traceback (most recent call last):
File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
self.run()
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 47, in run
self.deliverToQueue((self.target, z, y))
File "H:\PMT2\MyProjects\TkinterCrash2.py", line 129, in arrival_122
new_yz[1])
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
return self._create('line', args, kw)
File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
*(args + self._options(cnf, kw
TclError: bad screen distance "create"
--
versions: +Python 2.7 -Python 3.3
Added file: http://bugs.python.org/file20684/TkinterCrash2.py
___
Python tracker
<http://bugs.python.org/issue11077>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Scott M added the comment: If it helps, over the many iterations of this test code, there have been two kinds of issues: 1. pythonw.exe crashes with the Windows variant of a SEGV. No traceback, just a crash. These are rare. 2. Evidence of confusion over which string the code should be looking at, and it's always down in the create function of Tkinter. Variations of this confusion have been Int() complaining that it can't translate "None", strings like ".667748474.7464" not being recognized as parameter names... all of it sounds like Tkinter has somehow managed to be looking at the wrong string. Even when the only Tkinter call I do outside the mainloop thread is .after(), the crashes would happen when I went to draw a line. My (trivial) experience in extending Python makes me wonder if some reference count, somewhere, didn’t get mismanaged. The only times I ever got a hard crash out pythonw.exe in my own projects is when I mishandled a count. As a side note, if Tkinter is intended to be thread safe, the documentation should say so. Clearly, and in the first paragraph. Once I started having problems, I started Googling, and everything I read lead me to conclude that neither Tkinter nor wx were even intended to be thread safe, so I've started to write my own GUI code. This is a project I might have skipped if it has been clear that Tkinter is at least intended to be thread safe. -- ___ Python tracker <http://bugs.python.org/issue11077> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Scott Tsai : -- nosy: +scott.tsai versions: -3rd party, Python 3.3 ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Scott Tsai added the comment: I touched the version field by mistake while trying to add myself to the nosy list. My sincere apologies for the SPAM to all involved. -- versions: +3rd party, Python 3.3 ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by Scott Tsai : -- nosy: +scott.tsai ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: The attached patch builds on Mike's work. The core of the problem is that the Request object did not know what was going on. This means that it was not possible for get_authorization() to work for proxy-auth and www-auth. I change Request to know which of the four types of connection it represents. There are new methods on Request that return the right information based on the connection type. To understand how to make this work I needed to instrument the code. There is now a set_debuglevel on the OpenerDirector object that turns on debug in all the handlers and the director. I have added more debug messages to help understand this code. This code now passes the 72 test cases I run. I'll attach the code I used to test as a follow up to this. -- nosy: +b.a.scott Added file: http://bugs.python.org/file20821/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: Attached is the code I used to test these changes. See the README.txt file for details include the results of a test run. -- Added file: http://bugs.python.org/file20822/urllib2_tests.tar.gz ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Barry Scott added the comment: I left out some white space changes to match the style of the std lib code. Re posting with white space cleanup. -- Added file: http://bugs.python.org/file20824/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7291] urllib2 cannot handle https with proxy requiring auth
Changes by Barry Scott : Removed file: http://bugs.python.org/file20821/http_proxy_https.patch ___ Python tracker <http://bugs.python.org/issue7291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1775025] zipfile: Allow reading duplicate filenames
Scott Dial <[EMAIL PROTECTED]> added the comment: In the patch you commented "why is 'filepos' computed next? It's never referenced." The answer is that back at r54152 (#1121142) the method was rewrote removing any reference to 'filepos', but the patch author failed to remove that line. Please remove it. -- nosy: +scottdial _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1775025> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial <[EMAIL PROTECTED]> added the comment: I don't believe this is a valid bug. Can you provide a case where it does in fact grow? This issue has previously been addressed in #1685563, and was carried over to the new code as well. Some lines after the path is appended to, there is a call to normalize_and_reduce_paths(...), which removes duplicates almost exactly like you wrote it. -- nosy: +scottdial ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial <[EMAIL PROTECTED]> added the comment: The path gets changed everytime a MSVCCompiler is instantiated. I've seen the same problem with PATH before with PyPy. I agree this is a bug, but I don't see how it can be fixed. The problem exists inside of vcvarsall.bat if I understand this correctly. Furthermore, I don't understand how an exception could actually be thrown; the vc_env values are sourced from the environment after running vcvarsall.bat, so how could they be too long? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial <[EMAIL PROTECTED]> added the comment: This patch shouldn't have been applied as it is. The definition of "removeDuplicates" is both poorly-named, not exactly correct, and redundant (as there is already a "normalize_and_reduce_paths") for performing this fix on PATH. Jim, you acknowledged already that: """The normalize_and_reduce_paths() function needs to be performed on INCLUDE and LIBPATH in addition to the exec path. i.e. os.environ['lib'] and os.environ['include'].""" So, I don't understand how that got missed. I've attached a patch that removes the extra code. Added file: http://bugs.python.org/file11351/msvc9compiler_path.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8032] Add gdb7 hooks to make it easier to debug Python
Changes by Scott Tsai : -- nosy: +scott.tsai ___ Python tracker <http://bugs.python.org/issue8032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8636] enumerate() test cases do not cover optional start argument
New submission from Scott Dial : The issue2831 patch test cases are not actually being run by test_enumerate and they were broken tests anyways. This patch fixes the brokenness. -- components: Interpreter Core, Tests files: test_enumerate.patch keywords: patch messages: 105147 nosy: scott.dial priority: normal severity: normal status: open title: enumerate() test cases do not cover optional start argument type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file17237/test_enumerate.patch ___ Python tracker <http://bugs.python.org/issue8636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Scott Dial added the comment: Created issue8636 for the broken test cases. -- ___ Python tracker <http://bugs.python.org/issue2831> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment: John, set "ac_cv_printf_zd_format". In general, read the configure.in source. On Dec 10, 2007 1:17 PM, John Stowers <[EMAIL PROTECTED]> wrote: > > John Stowers added the comment: > > Sorry, I should have clarified further in my last comment. Looking over > the configure script I don't recognize the %zd test as one that could be > circumvented by supplying a config.cache file with the appropriate values. > > How do I escape this limitation? > > > _ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1597850> > _ > _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
New submission from Scott Moser:
I'm running into a problem with imaplib where it is unable to download a
message. The example code at
http://www.python.org/doc/current/lib/imap4-example.html easily
demonstrates the problem.
#!/usr/bin/python
import getpass, imaplib
M = imaplib.IMAP4("my.imap.host.tld")
M.login(getpass.getuser(), getpass.getpass())
M.debug = 5
M.select("msg-test")
typ, data = M.search(None, 'ALL')
for num in data[0].split():
typ, data = M.fetch(num, '(RFC822)')
print 'Message %s\n%s\n' % (num, data[0][1])
M.close()
M.logout()
The majority of the messages transfer correctly, but some do not. I've
put 3 messages in the 'msg-test' folder, and one of them causes the
error below.
Traceback (most recent call last):
File "test.py", line 9, in
typ, data = M.fetch(num, '(RFC822)')
File "/usr/lib/python2.5/imaplib.py", line 437, in fetch
typ, dat = self._simple_command(name, message_set, message_parts)
File "/usr/lib/python2.5/imaplib.py", line 1055, in _simple_command
return self._command_complete(name, self._command(name, *args))
File "/usr/lib/python2.5/imaplib.py", line 887, in _command_complete
raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: FETCH => unexpected response: ')'
imaplib.py has a comment in _get_tagged_response:
# Some have reported "unexpected response" exceptions.
# Note that ignoring them here causes loops.
# Instead, send me details of the unexpected response and
# I'll update the code in `_get_response()'.
I can not provide access to the imap host, but I can help debug wherever
possible.
The most recent log messages are in the file attachment.
--
components: Library (Lib)
files: imaplib-debug.txt
messages: 58482
nosy: smoser
severity: normal
status: open
title: unexpected response in imaplib
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8929/imaplib-debug.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1598>
__ 34:14.41 > DPAP7 FETCH 4 (RFC822)
34:14.46 < * 4 FETCH (RFC822 {3721}
34:14.46 matched r'\* (?P\d+) (?P[A-Z-]+)( (?P.*))?'
=> ('4', 'FETCH', ' (RFC822 {3721}', '(RFC822 {3721}')
34:14.46 matched r'.*{(?P\d+)}$' => ('3721',)
34:14.46 read literal size 3721
34:14.55 untagged_responses[FETCH] 0 += ["('4 (RFC822 {3721}', '...3883 bytes
total..')"]
34:14.55 < r questions.
34:14.55 untagged_responses[FETCH] 1 += ["r questions. "]
34:14.55 < )
34:14.55 last 10 IMAP4 interactions:
34:08.94 < * 4 EXISTS
34:08.94 < * 0 RECENT
34:08.94 < * OK [UIDVALIDITY 25] UIDs valid
34:08.94 < * OK [UIDNEXT 6] Predicted next UID
34:08.94 < * FLAGS (\Flagged \Seen \Answered \Deleted \Draft)
34:08.94 < * OK [PERMANENTFLAGS (\Flagged \Seen \Answered \Deleted \Draft
\*)] Permanent flags
34:08.94 < DPAP2 OK [READ-WRITE] SELECT completed
34:08.94 > DPAP3 SEARCH ALL
34:08.99 < * SEARCH 1 2 3 4
34:08.99 < DPAP3 OK SEARCH completed
the string 'r questions. ' above is the last part of the message.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: I want to clarify that the proposed change would break: operator.attrgetter(foo)(bar) == getattr(bar, foo) Which is the documented intent of the operator module: "This module exports a set of functions implemented in C corresponding to the intrinsic operators of Python." Unless, you are proposing getattr grow this functionality as well. IOW, should PyObject_GetAttr* perform this recursion? If so, should PyObject_HasAttr*, PyObject_DelAttr*, PyObject_SetAttr* do this as well? At the moment, it is possible to have foo's (as in above) that contain dots despite the inability to spell that in python's dereferencing syntax. However, I don't know that anybody does that. -- nosy: +scottdial __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1826> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: The attached patch provides for the functionality requested. I've updated the docstring of attrgetter related to this new feature and have updated test_operator accordingly. Added file: http://bugs.python.org/file9169/getattrchaser.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1826> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: Mea culpa, the original patch I attached here has an obvious duplication of code in test_operator.py. I've attached an updated patch to make life easier on the commiter. Added file: http://bugs.python.org/file9175/getattrchaser.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1826> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
Scott Moser <[EMAIL PROTECTED]> added the comment: I can recreate this at the moment with the attached mail. I downloaded the mail using alpine's "Export". I don't know what other way I would have to get it. I have replaced many company names with XYZ and such, simply to anonymize the message somewhat. Added file: http://bugs.python.org/file9727/failed-mail.txt __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1598> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
Scott Moser <[EMAIL PROTECTED]> added the comment: This is the stderr from the test case above. Only modification is the mailbox is 'my-test'. Added file: http://bugs.python.org/file9728/failed-errorlog.txt __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1598> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
Scott Moser <[EMAIL PROTECTED]> added the comment: > Can you provide the message or messages which cause the problem > when they are put in the IMAP server? See attached above > Can you also provide information on what IMAP server software > and version is being used? Its a lotus notes server. Just those 2 words are quite likely to make you think "server bug". The only reason I have to not think that is that the only other imap client i've tested (alpine and pine) works fine. So if indeed it is a server bug, its one that alpine has worked around. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1598> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
New submission from Scott Dial <[EMAIL PROTECTED]>: Georg Brandel suggested enumerate() should have the ability to start on an arbitrary number (instead of always starting at 0). I suggest such a parameter should be keyword-only. Attached is a patch to add such a feature along with added test cases. Documentation still needs to be updated, but I wasn't sure how best to handle that anyways. I wasn't sure how best to handle a keyword-only argument, so I'd be interested to know if there is a better way. -- components: Interpreter Core files: enumerate.diff keywords: patch messages: 66705 nosy: scottdial severity: normal status: open title: Adding start to enumerate() type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10299/enumerate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10300/enumerate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10299/enumerate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10300/enumerate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10301/enumerate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Scott Dial <[EMAIL PROTECTED]> added the comment: As it stands, enumerate() already takes a "sequence" keyword as an alternative to the first positional argument (although this seems to be completely undocumented). So, as you say, METH_O is a no go. I agree with you in that my original complaint with the positional argument was that enumerate(iterable, start) was "backwards." My other argument was that a large number of these iterator utility functions are foo(*iterable) and upon seeing enumerate(foo, bar), a reader might be inclined to assume it was equivalent to enumerate(chain(foo, bar)). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2831> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4115] split() method
New submission from Terry Scott <[EMAIL PROTECTED]>:
x = "Four score and seven"
x.split() => ["Four", "score", "and", "seven"]
x.split(" ") => ["Four", "score", " ", "and", "seven"]
Probably not a big deal but it seems that it should be consistent. One
of my students spotted it.
--
components: Windows
messages: 74701
nosy: terry.scott
severity: normal
status: open
title: split() method
type: behavior
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4115>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4115] split() method
Terry Scott <[EMAIL PROTECTED]> added the comment: Benjamin, Thanks. The documentation cleared this up for me. Thanks. Terry On Mon, 13 Oct 2008, Benjamin Peterson wrote: > > Changes by Benjamin Peterson <[EMAIL PROTECTED]>: > > > -- > resolution: -> invalid > status: open -> closed > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4115> > ___ > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4115] split() method
Terry Scott <[EMAIL PROTECTED]> added the comment: Tim, Duh, thanks sorry I didn't check the documentation. Thanks. Terry On Mon, 13 Oct 2008, Tim Gordon wrote: > > Tim Gordon <[EMAIL PROTECTED]> added the comment: > > This is the intended behaviour. See > http://www.python.org/doc/2.5.2/lib/string-methods.html for details. > > -- > nosy: +QuantumTim > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4115> > ___ > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
New submission from scott sadler <[EMAIL PROTECTED]>: Calling a function created by _functools.partial as a method raises an exception: "TypeError: method_new() takes exactly n non-keyword arguments (0 given)" Where method_new is the function passed into partial() and n is the number of arguments it expects. This does not happen when using a python version of partial(). Strangely, in the circumstance that I originally encountered the bug, there was one instance that I was doing this and it _DID WORK_. The function being passed into partial() was the same as in the place where it was failing. The only significant difference that I could see was that the input function to partial() was being imported, rather than being defined in the same namespace as it was used I was unable to reproduce it in my test case (attatched). Tested on 2.6 and 2.5.2 -- components: Extension Modules files: partialbug.py messages: 75928 nosy: ssadler severity: normal status: open title: Can't use _functools.partial() created function as method type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file12017/partialbug.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4331> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
scott sadler <[EMAIL PROTECTED]> added the comment: A short update, I believe that the reason that it was working in one instance was because of some abstractions by a base class (Django model, get_absolute_url). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4331> ___ ___ 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
New submission from Scott Dial : There is a problem with the table contents with respect to literals that cannot be word-wrapped. I see this issue here: http://docs.python.org/dev/2.6/library/multiprocessing.html The line in the table of contents that reads "The multiprocessing.dummy module" is broken in that the literal "multiprocessing.sharedctypes" overflows into the right-hand side. It also ends up underneath the contents on the right, which makes it extra hard to know what that entry was about. This instance may be browser specific, but I think it brings up a more general question of what should be done with such long literals and how overflow should be handled. And perhaps even whether it is wise to have set the width of that div to such a narrow and specific value (230px). I've attached a screenshot from Firefox 2.0.0.20/Win32 in case it is not as reproducible as I would expect. -- assignee: georg.brandl components: Documentation files: multiprocessing.png messages: 78151 nosy: georg.brandl, scottdial severity: normal status: open title: Wide literals in the table of contents overflow in documentation type: behavior Added file: http://bugs.python.org/file12416/multiprocessing.png ___ Python tracker <http://bugs.python.org/issue4711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial added the comment: I believe the original patch is overreaching. I believe the changes to fileobject.c should've been much simpler, just as the title describes (adding clearerr() just before performing reads on the FILE handles). I've attached a much simpler patch that I believe corrects the issue, but I don't have an OS X platform to try it on. -- nosy: +scottdial Added file: http://bugs.python.org/file12425/fileobject.diff ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial added the comment: They differ because in Py_UniversalNewlineFgets() there is a call to FLOCKFILE(), and it seemed appropriate to ensure that clearerr() was called after locking the FILE stream. I certainly pondered over whether it made a difference to do it before or after, and it would seem to me that if we are bothering to lock the FILE stream then we would care to ensure that the first GETC() after locking reaps the benefit of having called clearerr(). In the cases that we fall into fread and fgets, we may actually need to be doing: FLOCKFILE(stream) clearerr(stream); result = fgets(buf, n, stream); FUNLOCKFILE(stream); return result; One nitpick is that the testcase was appended to the StdoutTests class instead of OtherFileTests class, which would seem more appropriate. ___ Python tracker <http://bugs.python.org/issue1706039> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4919] 2.6.1 build issues on solaris with SunStudio 12
New submission from scott wedel : The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm instead of just -lm Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE and _AS_STRING because those macros use the ',' operator to stuff an assert before the pointer lookup. When I remove the assert portion of those macros then they compile fine. The assertions in those macros appear a bit silly because some places they are used already have prior assertions and I don't see the point of the macro which appears to be to crash due to an assertion one statement prior to the null pointer reference causing a crash. The configure process also appeared to make a few mistakes such as not finding uid_t because that is in and not in the presumed header file. If configure were to include the standard header files AND the file that it expects to find the definition then it would be better at finding what is defined. I don't know why Sun does that. -- components: Build messages: 79654 nosy: taverngeek severity: normal status: open title: 2.6.1 build issues on solaris with SunStudio 12 versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4933] Patch to add preliminary support for Haiku
New submission from Scott McCreary : This patch adds preliminary support for Haiku. We still have to hand tweak a few other files to get things to build. We have further patches to get python-2.5.4 to build, but it's failing some of the regression tests so we're leaving those parts out of this submitted patch. For more details on the progress of the Haiku port check here: http://ports.haiku-files.org/wiki/dev-lang/python/2.5.4 -- components: Build files: python-2.5.4-haiku-2.diff keywords: patch messages: 79753 nosy: scottmc severity: normal status: open title: Patch to add preliminary support for Haiku versions: Python 2.5 Added file: http://bugs.python.org/file12721/python-2.5.4-haiku-2.diff ___ Python tracker <http://bugs.python.org/issue4933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4933] Patch to add preliminary support for Haiku
Scott McCreary added the comment: On Tue, Jan 13, 2009 at 10:27 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > Python 2.5 branch is now frozen: only security fixes are accepted. You > should work on 2.6 or better on Python trunk for faster integration of > your patches ;-) Your patch looks good. > > -- > nosy: +haypo > > ___ 2.6.x is next on my list, then we'll focus on 3.x.x. Probably have a patch cleaned and ready to post within a few days here. Martin v. Löwis added the comment: What is the purpose of this patch? I.e. why are you submitting it to this bug tracker? "This patch adds preliminary support for Haiku." In case you were wondering what Haiku was, it is the open source replacement for BeOS, see haiku-os.org for more background. As for part two of your question, is there somewhere else I should be posting patches? If so direct me and I'll post them there. -scottmc ___ Python tracker <http://bugs.python.org/issue4933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4933] Patch to add preliminary support for Haiku
Scott McCreary added the comment: On Tue, Jan 13, 2009 at 10:38 PM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> I don't have any particular interest in BeOS variants, but this comes as >> a surprise given that http://python.org/about/ proclaims that "Python >> runs everywhere." >> >> Maybe Haiku could become a supported platform instead of more or less >> defunct BeOS? > > Maybe this can be discussed on python-dev, but there is a standing BDFL > pronouncement on this matter. It used to be the policy to accept patches > for any operating system, but this policy is reverted now. > I just joined that list, and will move further discussion of this there, that is once I have a clean patch that can be applied to the 2.6.x branch. One of Haiku's goals was to improve on POSIX compliance, so in many ports that we've done (over 100 now) we've actually had to un-workaround former BeOS workarounds. So we'd be fine with removing any BeOS cruft that we come across during a potential Haiku port/fork. >> As far as I can tell there is no current BeOS port >> maintainer, but there is some crud left over from the better times. If >> Haiku community can step in and clean up BeOS crud by either removing it >> or making sure it works on modern BeOS variants, this can only be a good >> thing. > > No. The cost is too high, and there are more important issues to > resolve. Of course, the Haiku community can provide there fork of Python > if they want to (and they also get official blessing for forking if they > want to). > I disagree about the cost being too high, as long as our patches are clean I don't see an issue here, if anything we might find things that are broken in python that weren't uncovered previously, I think it's a win-win. I don't think there's going to be a whole lot that needs to be patched to get it working on Haiku, we've got a mostly working 2.5.2 binary already, but it's failing a few of the regression tests, so we are looking into why on those and have left those patches out of what was submitted, as we wouldn't want to have to undo one of our previous patches. -scottmc ___ Python tracker <http://bugs.python.org/issue4933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38565] Expose the value passed of typed passed to functools.lru_cache
New submission from Scott Sanderson : In some circumstances, it's useful to be able in inspect the parameters with which an instance of functools.lru_cache was instantiated. It's currently possible to recover the cache's maxsize via the .cache_info() method, but there's no way to recover the value passed for `typed`, which controls whether the lru_cache's cache is partitioned by input type. This came up in the context of cloudpickle, a library that tries to extend pickle to support more types (in particular, interactively-defined functions and classes) for use-cases like cluster computing. It's currently not possible to pickle an lru-cache decorated function that's defined in __main__ (which includes, e.g. a Jupyter Notebook). We can **almost** fix this with a pure library solution (see https://github.com/cloudpipe/cloudpickle/pull/309), but we're currently blocked by the fact that there's no way to recover the value that was passed for `typed`. Exposing a .typed attribute on the extension type for lru_cached functions fixes this For more discussion, see the above linked PR, along with https://github.com/cloudpipe/cloudpickle/issues/178. -- components: Library (Lib) messages: 355226 nosy: Scott Sanderson2 priority: normal severity: normal status: open title: Expose the value passed of typed passed to functools.lru_cache type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43975] Incorrect MIME type returned for .js files Windows 10.
New submission from Scott Means : This isn't *technically* a bug in Python, but it really presents like one. I like to run the http.server for quick-and-dirty web development, but today Chrome refused to load any of my .js files because the server is returning a MIME type of 'text/plain'. I downloaded server.py and played with it for a while, and realized that mimetypes.guess_type() is returning 'text/plain' for .js files. So then I read further into the code and realized that mimetypes is harvesting MIME types from the Windows registry. And for some reason, at least on my machine, HKEY_CLASSES_ROOT\.js\Content Type was 'text/plain'. Changing it to 'application/javascript' fixed my issue, but I'm guessing that a lot of Python devs won't bother to dig this deep. I don't know what an appropriate fix would be, other than to probably trust the built-in MIME types over the ones harvested from Windows. -- components: Library (Lib) messages: 392294 nosy: smeans priority: normal severity: normal status: open title: Incorrect MIME type returned for .js files Windows 10. type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16801] Preserve original representation for integers / floats in docstrings
Scott Stevens added the comment: I'm now seeing docs.python.org has regressed. For 3.9, calls present their defaults in octal, in 3.10 (beta), they're presented in decimal. https://docs.python.org/3.10/library/pathlib.html#pathlib.Path.touch https://docs.python.org/3.10/library/os.html#os.mkdir Not sure if this is the right issue to be mentioning it on; if not, please let me know so I can file another issue. -- nosy: +Scott Stevens ___ Python tracker <https://bugs.python.org/issue16801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43513] venv: recreate symlinks on --upgrade
Change by Scott Macpherson : -- nosy: +macpherson.scott ___ Python tracker <https://bugs.python.org/issue43513> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42670] Missing word in itertools.product
New submission from Scott Noyes : -Accordingly, it only useful with finite inputs. +Accordingly, it is only useful with finite inputs. -- assignee: docs@python components: Documentation messages: 383257 nosy: docs@python, snoyes priority: normal severity: normal status: open title: Missing word in itertools.product type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42706] random.uniform 2x slower than inline implementation
New submission from Scott Norton :
The library function random.uniform takes about twice as long as a manual
inline implementation (Python 3.9.1).
>>> import timeit
>>> timeit.timeit('3 + (8 - 3) * random.random()', 'import random')
0.154088729228
>>> timeit.timeit('a + (b - a) * random.random()', 'import random\na = 3\nb =
>>> 8')
0.17950458899986188
>>> timeit.timeit('random.uniform(3, 8)', 'import random') # does the
>>> call/return really add that much overhead?
0.3114541869894
--
components: C API
messages: 383532
nosy: Scott Norton
priority: normal
severity: normal
status: open
title: random.uniform 2x slower than inline implementation
type: performance
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42706>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
Change by Scott Talbert : -- nosy: +swt2c ___ Python tracker <https://bugs.python.org/issue43115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
