[issue6078] freeze.py doesn't work

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

The problem is that the warnings module's init function does not adhere
to the standard Python naming scheme for extension modules: it's called
_PyWarnings_Init rather than init_warnings. This C helper module was
added to Python 2.6.

OTOH, warnings is a builtin module which always gets imported, so the
import mechanism bypasses the normal scan for such functions.

In order to get freeze to work, it should be enough to add '_warnings'
to the list never in makeconfig.py of the freeze tool.

--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6083] Reference counting bug in setrlimit

[Bill McCloskey]

New submission from Bill McCloskey :

The code for resource_setrlimit in Modules/resource.c does not handle
reference counting properly. The following Python code segfaults for me
on Ubuntu 8.10 in Python 2.5.2 and also a custom-built 2.6.1.

--
import resource

l = [0, 0]

class MyNum:
def __int__(self):
l[1] = 20
return 10

def __del__(self):
print 'byebye', self

l[0] = MyNum()
l[1] = MyNum()
resource.setrlimit(resource.RLIMIT_CPU, l)
--

The problem is that setrlimit gets its arguments by calling:
   PyArg_ParseTuple(args, "i(OO):setrlimit", 
&resource, &curobj, &maxobj)
The references curobj and maxobj are borrowed. The second argument can
be passed as a mutable list rather than a tuple, so it's possible to
update the list in the middle of setrlimit, causing maxobj to be
destroyed before setrlimit is done with it.

I've attached a patch that INCREFs both variables immediately after
parsing them to avoid this problem.

In my opinion it seems dangerous to allow format strings with the 'O'
specifier appearing in parentheses. You normally expect that objects
returned from PyArg_ParseTuple are pretty safe, but the fact that the
inner sequence may be mutable violates this assumption. Might it make
sense to ban this use case? I only found one other instance of it in the
Python source tree, inside ctypes. This one may also be a crashing
bug--I didn't look at it carefully enough.

--
components: Extension Modules
files: python-bug-01.patch
keywords: patch
messages: 88181
nosy: billm
severity: normal
status: open
title: Reference counting bug in setrlimit
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14040/python-bug-01.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6084] documentation of zip function is error

[bones7456]

New submission from bones7456 :

http://docs.python.org/library/functions.html?highlight=zip#zip

In this page, the example is error:

Python 2.6.2 (r262:71600, Apr 24 2009, 10:04:30) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2, 3]
>>> y = [4, 5, 6]
>>> zipped = zip(x, y)
>>> zipped
[(1, 4), (2, 5), (3, 6)]
>>> x2, y2 = zip(*zipped)
>>> x == x2, y == y2
(False, False)

The last line is "(False, False)", not True.

--
assignee: georg.brandl
components: Documentation
messages: 88182
nosy: bones7456, georg.brandl
severity: normal
status: open
title: documentation of zip function is error
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6084] documentation of zip function is error

[bones7456]

bones7456  added the comment:

>>> type(x)

>>> type(x2)


It cann't be equal...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6084] documentation of zip function is error

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r72822.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Ned Deily]

Ned Deily  added the comment:

Reopening as RELEASE BLOCKER.

r71936 does indeed install pydoc and idle with a 3 suffix.  However, it 
also removed the 2to3 and smtp.py scripts previously installed by 
setup.py without providing any replacements for them, versioned or not.

Section 25.4.1 of the 3.1 Standard Library docs state "2to3 will usually 
be installed with the Python interpreter as a script. It is also located 
in the Tools/scripts directory of the Python root."

In the case of the OSX installer, as it stands now with r71936, there is 
no longer a 2to3 script in the framework bin directory and Tools/scripts 
is not installed.  So what's a user to do?  Is this also an issue for 
the Windows installers?  What about Linux/Unix distributions?  (For the 
OSX installer, I've also documented the problem in Issue5272).

This raises the issues of what is a sensible way to handle potential 
multiple versions of 2to3. Perhaps this has been discussed and decided 
elsewhere?  If not ...:

I see two scenarios of interest -

1. If a user has installed 2.6 (or newer 2.x), a 2to3 is already 
installed. But installing 3.x will(for 3.0)/should(for 3.1) install a 
3.x 2to3 script.  Should it supersede, co-exist with, or defer to the 
2.x version?

2. If a user is moving from 2.5 or earlier, to 3.x, the 3.x installation 
needs to unconditionally provide 2to3.

In the case of the interpreter, the reason for renaming to python3 is 
clear: python2 and python3 expect different input, produce different 
output, and need to co-exist.  In the case of 2to3, however, there 
shouldn't be any fundamental differences between the versions provided 
with a py2 or a py3 install other than bug fixes and potential new 
features, right?

If so, since the output of 2to3 is python3, one could make the case that 
the py3 installed 2to3 should take precedence over a py2 one, at least 
by default.  If there is the potential need for the user to be able to 
choose which 2to3 to use, then a user-friendly solution would be to have 
py2 and py3 install them as something like 2to3-2 and 2to3-3, 
respectively, and a 2to3 which would prefer 2to3-3 but fall back to 
2to3-2.  Otherwise, the py3k version could always just install as 2to3-3 
and it would be up to the user to know (with documentation help) about 
the potential two versions, since the py2 2to3 version is already out of 
the bag and in the field.  Or the py3 install could unilaterally 
supersede a py2 version, with the limitation that a new 2.6.x (re-
)install would likely cause a 2to3 revert, something that could be fixed 
in 2.7.

In any case, if this hasn't already happened, I think a decision needs 
to be made on how the 2to3 conflict should be handled so that at least 
*one* version of 2to3 is always available, ensuring that the solution 
makes sense for all of the major platforms, and making sure it gets 
implemented *and* properly documented prior to 3.1 release and, if 
necessary, the 2.7 release.

I'm less concerned about the removal of the smtpd.py script as I suspect 
it is little used and I don't know how it is handled by the all of the 
platforms (the OSX installer has provided it in bin up until now).  Does 
the smtpd script even appear in the documentation anywhere?  
Nevertheless, if it hasn't already happened, the impact of its removal 
should be assessed on the major platforms and, if it remains removed, at 
least that should be documented in What's New.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5272] OS X installer: fix makefile target changed for 3.x

[Ned Deily]

Ned Deily  added the comment:

With the decision to have references to py3k scripts always contain a 
"3", I agree that "make fullinstall" is no longer appropriate.

With r72723 and current py3k, however, there are still some issues.  
Compare ls -l bin from 2.6.2, 3.0.1, and current py3k:

$ cd /Library/Frameworks/Python.framework/Versions
$ ls -l 2.6/bin
total 264
-rwxrwxr-x  1 root  admin150 Apr 16 00:28 2to3*
lrwxr-xr-x  1 root  admin  7 May 21 23:57 idle@ -> idle2.6
-rwxrwxr-x  1 root  admin138 Apr 16 00:28 idle2.6*
lrwxr-xr-x  1 root  admin  8 May 21 23:57 pydoc@ -> pydoc2.6
-rwxrwxr-x  1 root  admin123 Apr 16 00:28 pydoc2.6*
lrwxr-xr-x  1 root  admin  9 May 21 23:57 python@ -> python2.6
lrwxr-xr-x  1 root  admin 16 May 21 23:57 python-config@ -> 
python2.6-config
-rwxrwxr-x  1 root  admin  33688 Apr 16 00:30 python2.6*
-rwxrwxr-x  1 root  admin   1463 Apr 16 00:29 python2.6-config*
lrwxr-xr-x  1 root  admin 10 May 21 23:57 pythonw@ -> pythonw2.6
-rwxrwxr-x  1 root  admin  33688 Apr 16 00:30 pythonw2.6*
lrwxr-xr-x  1 root  admin 11 May 21 23:57 smtpd.py@ -> smtpd2.6.py
-rwxrwxr-x  1 root  admin  18093 Apr 16 00:28 smtpd2.6.py*

$ ls -l 3.0/bin
total 248
-rwxrwxr-x  1 root  admin150 Feb 14 10:04 2to3*
lrwxr-xr-x  1 root  admin  7 May 21 23:58 idle@ -> idle3.0
-rwxrwxr-x  1 root  admin138 Feb 14 10:04 idle3.0*
lrwxr-xr-x  1 root  admin  8 May 21 23:58 pydoc@ -> pydoc3.0
-rwxrwxr-x  1 root  admin123 Feb 14 10:04 pydoc3.0*
lrwxr-xr-x  1 root  admin  9 May 21 23:58 python@ -> python3.0
lrwxr-xr-x  1 root  admin 16 May 21 23:58 python-config@ -> 
python3.0-config
-rwxrwxr-x  1 root  admin  29560 Feb 14 10:05 python3.0*
-rwxrwxr-x  1 root  admin   1440 Feb 14 10:05 python3.0-config*
lrwxr-xr-x  1 root  admin 10 May 21 23:58 pythonw@ -> pythonw3.0
-rwxrwxr-x  1 root  admin  29560 Feb 14 10:05 pythonw3.0*
lrwxr-xr-x  1 root  admin 11 May 21 23:58 smtpd.py@ -> smtpd3.0.py
-rwxrwxr-x  1 root  admin  18119 Feb 14 10:04 smtpd3.0.py*

$ ls -l 3.1/bin
total 272
lrwxr-xr-x  1 root  admin  7 May 21 19:10 idle3@ -> idle3.1
-rwxrwxr-x  1 root  admin138 May 21 18:51 idle3.1*
lrwxr-xr-x  1 root  admin  8 May 21 19:10 pydoc3@ -> pydoc3.1
-rwxrwxr-x  1 root  admin123 May 21 18:51 pydoc3.1*
-rwxrwxr-x  1 root  admin  34220 May 21 18:51 python*
lrwxr-xr-x  1 root  admin 16 May 21 19:10 python-config@ -> 
python3.1-config
lrwxr-xr-x  1 root  admin  9 May 21 19:10 python3@ -> python3.1
lrwxr-xr-x  1 root  admin 16 May 21 19:10 python3-config@ -> 
python3.1-config
-rwxrwxr-x  1 root  admin  29560 May 21 18:51 python3.1*
-rwxrwxr-x  1 root  admin   1440 May 21 18:51 python3.1-config*
lrwxr-xr-x  1 root  admin 10 May 21 19:10 pythonw3@ -> pythonw3.1
-rwxrwxr-x  1 root  admin  29560 May 21 18:51 pythonw3.1*

Issues:

1. In py3k bin, there is a "python" binary rather than the symlink that 
was there before.  That appears to be the unstripped binary of the 
interpreter (before it is stripped installed into the fw app bundle). 
Presumably the symlink install used to implicitly remove the binary; now 
an explicit rm is needed?

2. There is still a symlink to python-config.

3. There is no longer *any* 2to3 script, versioned or not. r71936  
(setup.py) is the culprit here (Issue5756, which I'm reopening to ensure 
this issue is examined for all platforms).  With regard to the OSX 
installer, since Tools/scripts isn't installed, there needs to be a 
script of some kind in bin.  As discussed in Issue5756, it should be 
decided how to resolve conflicts between a py2 2to3 and a py3 one.

4. There is no longer any smtpd.py or smtpd3.x.py script/link installed, 
also due to r71936 (setup.py) and to r72723 (Mac/Makefile.in).  I don't 
see this as a huge issue since I doubt that script is used much at all.  
But, at the least, a NEWS/What's New and/or README item about its 
removal in 3.1 is in order.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Ned: the 2to3 is not installed anymore by the main makefiles, I don't know 
why.

I'm actually happy that smtpd.py isn't installed anymore, this always 
looked more like an example that a real tool to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

[Wentao Han]

New submission from Wentao Han :

The invocation of socket.getfqdn to get FQDN of the host may delay for 
several seconds on some platforms when no appropriate host name is found. 
This causes lag when using SimpleXMLRPCServer and other class derived from 
BaseHTTPServer for every request.

--
components: Library (Lib)
messages: 88188
nosy: aerodonkey
severity: normal
status: open
title: Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag
type: performance
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6086] Correct minor typos in doanddont.rst and urllib2.rst howto documents.

[Vikram U Shenoy]

New submission from Vikram U Shenoy :

Attached are two patches (for trunk and py3k):

* Correct a trivial typo in doanddont.rst

* Correct a mistake in urllib2.rst, where URLError was being used
instead of the HTTPError, in case the urllib2.urlopen() was raising an
exception.

--
assignee: georg.brandl
components: Documentation
messages: 88189
nosy: georg.brandl, vshenoy
severity: normal
status: open
title: Correct minor typos in doanddont.rst and urllib2.rst howto documents.
versions: Python 2.6, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6086] Correct minor typos in doanddont.rst and urllib2.rst howto documents.

[Vikram U Shenoy]

Changes by Vikram U Shenoy :


--
keywords: +patch
Added file: http://bugs.python.org/file14041/doc_typo_trunk_may_22_2009.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6086] Correct minor typos in doanddont.rst and urllib2.rst howto documents.

[Vikram U Shenoy]

Changes by Vikram U Shenoy :


Added file: http://bugs.python.org/file14042/doc_typo_py3k_may_22_2009.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Ned Deily]

Ned Deily  added the comment:

Ronald, no changes were made to the makefiles, just to setup.py in 
r71400 and r71936 (which also renamed idle and pydoc):

[...]
Modified: python/branches/py3k/setup.py

==
--- python/branches/py3k/setup.py   (original)
+++ python/branches/py3k/setup.py   Sat Apr 25 23:11:45 2009
@@ -1652,13 +1652,7 @@
   # called unless there's at least one extension module 
defined.
   ext_modules=[Extension('_struct', ['_struct.c'])],
 
-  # Scripts to install
-  # Commented out because we don't want them to override the 
2.x
-  # ones. See #1590.
-  scripts = []
-  #scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
-  #   'Tools/scripts/2to3',
-  #   'Lib/smtpd.py']
+  scripts = ["Tools/scripts/pydoc3", "Tools/scripts/idle3"]
 )
 
 # --install-platlib

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6086] Correct minor typos in doanddont.rst and urllib2.rst howto documents.

[Georg Brandl]

Georg Brandl  added the comment:

Committed in trunk r72830 and py3k r72831. Thanks!

--
resolution:  -> accepted
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Ned Deily]

Ned Deily  added the comment:

Sorry, my assertion "no changes were made to the makefiles" is not quite 
correct.  r71372 did change the altinstall target for Issue1590, the 
precipitator of this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build

[Vinay Sajip]

New submission from Vinay Sajip :

When used with a build from source (i.e. non-installed) of Python,
get_python_lib gives the result (on Linux)

[prefix]/lib/python[version]

Shouldn't this be [prefix]/Lib?

Note that get_python_inc() returns "Include". That's because it makes
use of the "python_build" flag which is set for builds from source.

--
assignee: tarek
components: Distutils
keywords: easy
messages: 88194
nosy: tarek, vsajip
priority: normal
severity: normal
status: open
title: distutils.sysconfig.get_python_lib gives surprising result when used 
with a Python build
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6088] Python3.0.1.1 is not available when system locale is zh_TW.eucTW

[Leeon]

New submission from Leeon :

Python3.0.1 is not available when system locale is zh_TW.eucTW

Expected result: python3.0 interpreter should works fine.
Actual result: python3.0 interpreter can not execute any statement or
ran python program.

Steps to reproduce this bug:
1. Login HP-UX with a locale 'zh_TW.eucTW'.
2. Install ActivePython-3.0.1.1-hpux11.00-parisc.tar.gz on a HP-UX 11.11
machine.
3. Start the python3.0 interpreter.
4. Try some python statements like following, there was not any reaction:
import locale
locale.getlocale()
help()
exit()
5. Try to run a python program like following, but it was not run.
python3.0 foo.py

Notes:
1. This error does not occur when the system locale is 'zh_TW.big5'.
2. This error was also found on linux build.

--
components: Interpreter Core
messages: 88195
nosy: leeon
severity: normal
status: open
title: Python3.0.1.1 is not available when system locale is zh_TW.eucTW
type: crash
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6042] Document and slightly simplify lnotab tracing

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure why you changed PyCode_CheckLineNumber to
_PyCode_CheckLineNumber. Other than that, I suppose you know what you're
doing :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6088] Python3.0.1.1 is not available when system locale is zh_TW.eucTW

[R. David Murray]

R. David Murray  added the comment:

I can't reproduce this on trunk (or 3.0 maint) on Gentoo Linux:

~/python/py3k>./python
Python 3.1b1+ (py3k:72816, May 21 2009, 22:01:55) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[50411 refs]
>>> locale.getlocale()
('zh_TW', 'eucTW')
[50423 refs]
>>> help()

Welcome to Python 3.1!  This is the online help utility.

[...]

>>> locale.setlocale(locale.LC_ALL, '')
'zh_TW.eucTW'
[50462 refs]
>>> help()

Welcome to Python 3.1!  This is the online help utility.

[...]

Leon: you say ActivePython, which is a vendor distribution.  I think you
should report this bug to them, unless you can reproduce it using the
python.org python.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6089] str.format raises SystemError

[Mark Florisson]

New submission from Mark Florisson :

>>> '{0[0](10)}'.format([None])
Traceback (most recent call last):
  File "", line 1, in 
SystemError: error return without exception set

--
components: Interpreter Core
messages: 88198
nosy: eggy
severity: normal
status: open
title: str.format raises SystemError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6042] Document and slightly simplify lnotab tracing

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

I had two reasons to change PyCode_CheckLineNumber to
_PyCode_CheckLineNumber: First, its behavior is changing without its
signature changing. Without a name change, that could break users
silently (if there are any codesearch missed). Second, I think it's an
internal function which we should feel free to change again if it makes
the implementation cleaner. In order to let people change it at will, it
should start with "_Py".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6079] SyntaxError in xmlrpc.client examples

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r72832.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6090] zipfile DeprecationWarning Python 2.6.2

[Ivan Bykov]

New submission from Ivan Bykov :

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit 
(Intel)] on win32
IDLE 2.6.2  
>>> import zipfile
>>> new = zipfile.ZipFile('C:\\x', 'w', zipfile.ZIP_DEFLATED)
>>> zi = zipfile.ZipInfo('test',(1,2,3,4,5,6))
>>> new.writestr(zi,'fgh')

Warning (from warnings module):
  File "H:\programs\python\lib\zipfile.py", line 1105
self.fp.write(zinfo.FileHeader())
DeprecationWarning: struct integer overflow masking is deprecated

Warning (from warnings module):
  File "H:\programs\python\lib\zipfile.py", line 1105
self.fp.write(zinfo.FileHeader())
DeprecationWarning: 'H' format requires 0 <= number <= 65535
>>>

--
components: Extension Modules
messages: 88201
nosy: ivb
severity: normal
status: open
title: zipfile DeprecationWarning Python 2.6.2
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6089] str.format raises SystemError

[R. David Murray]

R. David Murray  added the comment:

trunk and py3k debug build gives this:

>>> '{0[0](10)}'.format([None])
python: Objects/stringlib/string_format.h:379: FieldNameIterator_next:
Assertion `0' failed.
zsh: abort  ./python

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6089] str.format raises SystemError

[R. David Murray]

Changes by R. David Murray :


--
priority:  -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6089] str.format raises SystemError

[R. David Murray]

Changes by R. David Murray :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6078] freeze.py doesn't work

[Georg Brandl]

Georg Brandl  added the comment:

Added in r72833.

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6083] Reference counting bug in setrlimit

[Georg Brandl]

Georg Brandl  added the comment:

That is a good point.  IMHO we'll be fine with a warning in the docs,
and fixing our own two instances.  Martin, what do you think?

--
assignee:  -> loewis
nosy: +georg.brandl, loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6089] str.format raises SystemError

[Eric Smith]

Eric Smith  added the comment:

Any character after a ']' other than '.' or '[' triggers this bug:

>>> '{0[0]x}'.format([None])
Assertion failed: (0), function FieldNameIterator_next, file
Objects/stringlib/string_format.h, line 379.

I'll fix it this weekend.

--
assignee:  -> eric.smith
versions:  -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows

[Robert Cronk]

Robert Cronk  added the comment:

I have had this problem with 2.6.1 on windows from multiple _threads_ 
instead of multiple processes.  Is that not supported either?  If not, 
what is the workaround for logging from multiple threads?  Shouldn't it 
be easy to use a semaphore within the logging code to make it thread 
safe at least?  I have had this problem on multiple PC's with multiple 
versions of python, and multiple versions of windows.

--
nosy: +rcronk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6081] str.format_from_mapping()

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I would certainly like to, but unfortunately at present I am unable to.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable

[Joe Amenta]

Joe Amenta  added the comment:

Python writes compiled files with the same file permissions as the
source module.  In your specific example:

$ python2.6 -c 'import module'

This will produce module.pyc with the same attributes as module.py

While I am not familiar with modifying C stat structs, I can say that in
trunk/Python/import.c, somewhere after line 977 but before line 1014,
the stat struct "st" must be examined for S_IXUSR, S_IXGRP, and S_IXOTH
and have those bits removed in order to never produce a compiled module
with "x" in the stat.  I would assign low priority to this issue, as it
has little impact on the behavior of Python, even though it might cause
unintended consequences to a user trying to execute the bytecode, if the
user interprets the "x" to mean that it is executable by the system.

--
nosy: +joe.amenta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

Perhaps Gregory has some idea about how this can most easily be
resolved, since I think he did the work on #3745 which introduced this
change in behavior.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I don't think it matters which version of 2to3 is used. It has a same
function.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable

[Oleg Broytmann]

Oleg Broytmann  added the comment:

I will try to look at import.c, though I must say I am a bad C
programmer. I have switched to Python after ten years of Pascal.

Low priority is ok.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Gregory P. Smith]

Gregory P. Smith  added the comment:

to confirm, this is only a problem in 2.7 trunk right?

if so, i won't rush a fix.

but yes fallback code for legacy types or adding buffer api support to 
array would work.

--
assignee:  -> gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows

[Vinay Sajip]

Vinay Sajip  added the comment:

This exact problem? Single process, multiple threads, one single handler
for a given file? Can you post an example which demonstrates your issue?

Multiple threads *are* supported by the logging package, as mentioned in
the documentation. If you can post a an example here, I'll take a look
at it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4749] Issue with RotatingFileHandler logging handler on Windows

[Robert Cronk]

Robert Cronk  added the comment:

I will go through the code and make sure I am not mistaken, but I do 
believe I have a single process, multiple threads, and only one handler 
for this file and I'm getting the same types of error messages shown on 
this page.  I'm probably doing something wrong.  I'll post what I find 
soon.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6091] Curses segfaulting in FreeBSD/amd64

[Jack Miller]

New submission from Jack Miller :

I have some code that gets a Pycurses window object, grabs the standard
ncurses WINDOW* out of it and proceeds to use that as usual. Works great
on Linux. Segfaults on FreeBSD/amd64.

static PyObject * mvw(PyObject *self, PyObject *args)
{
PyObject *window;
WINDOW *win;
int y, x, width, rep_len, end_len, ret;
char *message, *rep, *end;

const char *m_enc, *r_enc, *e_enc;
if(!PyArg_ParseTuple(args, "Oiiietetet", 
&window, &y, &x, &width, &m_enc, &message,
&r_enc, &rep, &e_enc, &end))
return NULL;

if (window != Py_None)
win = ((PyCursesWindowObject *)window)->win;
else
win = NULL;
...

Very simple. After this runs, `win` should be a standard curses window.
As noted, this works just fine in Linux regardless of architecture and
I'm sure that I'm passing a correct object type. (Tangentially, the
window check macro in py_curses.h -- PyCursesWindow_Check(v) -- also
segfaults, but I haven't tested that on Linux).

The subsequent `win` is non-NULL, but when I attempt to actually use it,
even for a simple `mvwaddch(win, 0, 0, '?');`, the program segfaults on
FreeBSD.

Other Notes: If I just use curses from Python (i.e. without a C
extension), it works as expected. I've attached this basic, working
test. This leads me to believe that the ncurses library is ok, and that
the majority of the curses binding is probably ok.

Also, I'm not sure if there is a better (more pythonic) way to get to
the WINDOW object, I just looked at the struct in py_curses.h to grab it
and it worked, so I didn't give it a second thought until now. I also
don't know how to verify that the pointer points to a curses WINDOW, but
I do know that the pointer address looks ok.

I can whip up a non-working test case on request, but I'm not sure the
best way to include the extension. The full source for the extension and
the program using it at codezen.org/canto ( particularly: 
http://codezen.org/cgi-bin/gitweb.cgi?p=canto.git;a=blob;f=canto/widecurse.c;h=d8a259a66c85f5fa87d52045a643fc81beec8017;hb=HEAD
)

I'm running FreeBSD 8-CURRENT, but the code doesn't work on 7.2-STABLE
either. This is Python 2.5.4 and pyncurses 0.3 both built from source
out of ports as of May 20th.

--
components: Extension Modules
messages: 88220
nosy: themoken
severity: normal
status: open
title: Curses segfaulting in FreeBSD/amd64
type: crash
versions: Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4066] smtplib SMTP_SSL._get_socket doesn't return a value

[R. David Murray]

R. David Murray  added the comment:

Applied to trunk in r72835, with some test fixes after (to skip the test
if SSL isn't installed).  Applied to py3k in r72836, ditto on fixes.  I
also backported the fix and test to 26-maint and 30-maint.

--
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5761] add file name to py3k IO objects repr()

[R. David Murray]

R. David Murray  added the comment:

Antoine, by "reused for f's repr" do you mean adding 'name=' into
the existing repr (probably before the encoding)?

Benjamin, by "bytes" do you mean BytesIO objects?  Would it be
acceptible to give them a 'name' attribute set to 'None'?

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5761] add file name to py3k IO objects repr()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine, by "reused for f's repr" do you mean adding 'name=' into
> the existing repr (probably before the encoding)?

Exactly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6092] Changed Shortcuts don't show up in menu

[jamesie]

New submission from jamesie :

After having changed the key binding for run-module to C-r it still says
F5 in the menu and in the general section of configuration.
Check Module has the same behaviour.
Seen with Debian Lenny's IDLE 1.2.2 on Python 2.5.2 and with IDLE 3.1b1
on Python 3.1b1.

--
components: IDLE
messages: 88224
nosy: gpolo, jamesie
severity: normal
status: open
title: Changed Shortcuts don't show up in menu
versions: Python 2.5, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com