[issue9809] Wrong Registery Entries on win64

[GreY FoX]

New submission from GreY FoX :

Priority:  3 Keywords:  6

well python on installation on win64 adds the following registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help\Main Python 
Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



but to be found by the programs searching for it it should be:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help\Main Python 
Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



this would fix the installer of the setuptools
thanks

--
components: Installation
messages: 115929
nosy: GreYFoX
priority: normal
severity: normal
status: open
title: Wrong Registery Entries on win64
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue1757072] Zipfile robustness

[Alan McIntyre]

Alan McIntyre  added the comment:

Maybe ZipFile should have an option to handle archives in a non-strict mode, in 
which it would raise warnings or just completely ignore a small set of minor 
violations of the spec.  That way people that want behavior that's in 
compliance with the spec will have it (by default), but those that need to 
handle ZIP files that bend the rules can still choose to use the Python 
standard libraries to get their work done.

If there's any interest in this I can work up a patch, tests, and documentation.

--

___
Python tracker 

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

[issue9808] Implement os.getlogin on Windows

[R. David Murray]

Changes by R. David Murray :


--
nosy: +brian.curtin, tim.golden

___
Python tracker 

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

[issue9808] Implement os.getlogin on Windows

[Jon Anglin]

New submission from Jon Anglin :

This is a feature request to implement the os.getlogin function on Windows 
systems.  This may not be a widely used function, but implementing on Windows 
will bring Python on Windows one step closer to Python on Unix (like) systems.  
The os_getlogin.diff file contains my proposed patch to add this functionality 
for Windows.

--
components: Library (Lib), Windows
files: os_getlogin.diff
keywords: patch
messages: 115927
nosy: janglin
priority: normal
severity: normal
status: open
title: Implement os.getlogin on Windows
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18808/os_getlogin.diff

___
Python tracker 

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

[issue9805] Documentation on old-style formatting of dicts is overly restrictive

[Eric Smith]

Eric Smith  added the comment:

I think this might be a dupe of issue 1467929.

--

___
Python tracker 

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

[issue9807] deriving configuration information for different builds with the same prefix

[R. David Murray]

Changes by R. David Murray :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue9806] no need to try loading posix extensions without SOABI

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I guess I'm concerned about any compatibility issues e.g. an extension built 
for 3.1 trying to load into 3.2.  But that'll probably fail anyway.  So I guess 
it's impossible to build a bare .so extension for Python 3.2.

--

___
Python tracker 

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

[issue9805] Documentation on old-style formatting of dicts is overly restrictive

[R. David Murray]

R. David Murray  added the comment:

Python 3.2a2+ (py3k:84613, Sep  7 2010, 19:17:31) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s %(abc)s" % dict(abc=2)
"{'abc': 2} 2"

I did not expect this result.  Looks like a bug to me.

>>> "%s %(abc)s" % (dict(abc=2), 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: format requires a mapping
>>> "%d %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: %d format: a number is required, not dict
>>> "%s %s %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: not enough arguments for format string

So, the only case which "works" (but is arguably buggy) is a single %s mixed in 
with dict lookups.  'may' does not adequately describe this reality.  'must' is 
much closer.  If it weren't a backward incompatible change I'd suggest making a 
single dict (i.e.: non-tuple) argument to % with non-dict-lookup patterns an 
error.  As it is, we'll just live with the quirk, and probably with the bug as 
well.

I'm not sure it is worth explaining all these quirks in the main docs.  Perhaps 
in a footnote?

--
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +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

[issue9807] deriving configuration information for different builds with the same prefix

[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

[issue9807] deriving configuration information for different builds with the same prefix

[Matthias Klose]

Changes by Matthias Klose :


--
nosy: +dmalcolm

___
Python tracker 

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

[issue9807] deriving configuration information for different builds with the same prefix

[Matthias Klose]

New submission from Matthias Klose :

currently, much of the configuration information is fetched by opening the 
config.h and the Makefile for the build. The locations of these files are 
derived from the prefix given at configure time.

If you want to have two distinct builds with the same prefix, but with 
different configuration options, this kind of configuration information is 
unsufficient.  The current use case is a normal build and a debug build, as 
used for the Fedora and Debian/Ubuntu python packages.

Fedora and Debian/Ubuntu carry a patch, adding a sys.pydebug attribute and 
patching "some" things to get the correct information for these builds using 
the same prefix.

This kind of information should not be derived by following some paths names, 
but be contained in the python binary itself, without needing to read the 
Makefile and the config.h files.

Attached is a patch currently applied in Debian/Ubuntu (and some variant for 
Fedora) which introduces a sys.pydebug attribute and derives the correct 
locations for the config.h and Makefile files. It's not meant as a patch ready 
to apply, but to get an idea what is needed to have two different python 
installations with the same prefix.

--
components: Build
files: debug-build.diff
keywords: patch
messages: 115923
nosy: barry, doko
priority: normal
severity: normal
stage: needs patch
status: open
title: deriving configuration information for different builds with the same 
prefix
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18807/debug-build.diff

___
Python tracker 

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

[issue9806] no need to try loading posix extensions without SOABI

[Matthias Klose]

Changes by Matthias Klose :


--
stage:  -> patch review

___
Python tracker 

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

[issue9806] no need to try loading posix extensions without SOABI

[Matthias Klose]

New submission from Matthias Klose :

the SOABI is always defined, no need to try loading an extension without the 
SOABI in its name.

ok to commit?

--
components: Interpreter Core
files: dynload.diff
keywords: patch
messages: 115922
nosy: barry, doko
priority: normal
severity: normal
status: open
title: no need to try loading posix extensions without SOABI
versions: Python 3.2
Added file: http://bugs.python.org/file18806/dynload.diff

___
Python tracker 

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

[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

After creating experimental patch, I could supress dialog
and error message on VS8.0. But it seems there is no way to
suppress error message on VC6. That is,

FAILED (failures=1)
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 182, in 
test_main()
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 143, in test_main
support.run_unittest(CAPITest)
  File "e:\python-dev\py3k\lib\test\support.py", line 1127, in run_unittest
_run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 1110, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalErro
r_infinite_loop
b'Fatal Python error:'
AssertionError: b'Fatal Python error: PyThreadState_Get: no current thread\r\n\r
\nabnormal program termination' != b'Fatal Python error: PyThreadState_Get: no c
urrent thread'

This happens because "abnormal program termination" is output to
stderr. Another capable sink to output error message into is
messagebox, of cause it is not what we want. There is no way to
silent this.

I think there are a few options to take.
* Skip this test on VC6 (And probably VS7.1)
* Check not equality, but if stderr starts with "Fatal Python "

--
nosy: +ocean-city
priority: release blocker -> normal

___
Python tracker 

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

[issue9804] ascii() does not always join surrogate pairs

[STINNER Victor]

STINNER Victor  added the comment:

> >>> s = "'\0\"\n\r\t abcd\x85é\U00012fff\U0001D121xxx\uD800."
> (...)
> (I think I've included everything:
> - normal chars
> - control chars
> - one-byte non-ASCII
> - two-byte non-ASCII (and lone surrogate)
> - printable and non-printable surrogate pairs)
> - single and double quotes)

Add maybe a lone suroggate followed directly by a surrogate pair, eg. 
'\uD800\U0001D121'.

--

___
Python tracker 

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

[issue8655] Problem with getpeercert in the ssl module when retrieving client side certs

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: open -> closed

___
Python tracker 

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

[issue9801] Can not use append/extend to lists in a multiprocessing manager dict

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Similarly:

>>> x = man.list()
>>> x.append({})
>>> x[0]
{}
>>> x[0]['a'] = 5
>>> x[0]
{}

Lots of fun!

--
nosy: +pitrou

___
Python tracker 

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

[issue9801] Can not use append/extend to lists in a multiprocessing manager dict

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> jnoller
nosy: +jnoller
versions: +Python 2.7, 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

[issue9804] ascii() does not always join surrogate pairs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch (lacking tests for now).

--
keywords: +patch
Added file: http://bugs.python.org/file18805/backslashsurrogates.patch

___
Python tracker 

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

[issue9804] ascii() does not always join surrogate pairs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Or perhaps not, since we would like surrogate pairs to be fused in other cases 
(ascii() of other types) as well.

So "backslashreplace" would need to be changed instead:

>>> print("\U00012345".encode('ascii', 'backslashreplace'))
b'\\ud808\\udf45'

Expected result (already works in UCS4 builds):

>>> print("\U00012345".encode('ascii', 'backslashreplace'))
b'\\U00012345'

--

___
Python tracker 

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

[issue9804] ascii() does not always join surrogate pairs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, it would probably be simpler to export a 
_PyUnicode_Repr(PyUnicodeObject *, int only_ascii) function since all the code 
is already there in unicodeobject.c.

--

___
Python tracker 

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

[issue9804] ascii() does not always join surrogate pairs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

How about the following solution:

>>> def a(s):
...s = s.encode('unicode-escape').decode('ascii')
...s = s.replace("'", r"\'")
...return "'" + s + "'"
... 
>>> s = "'\0\"\n\r\t abcd\x85é\U00012fff\U0001D121xxx\uD800."
>>> print(ascii(s)); print(a(s)); print(repr(s))
'\'\x00"\n\r\t abcd\x85\xe9\U00012fff\ud834\udd21xxx\ud800.'
'\'\x00"\n\r\t abcd\x85\xe9\U00012fff\U0001d121xxx\ud800.'
'\'\x00"\n\r\t abcd\x85é\U00012fff𝄡xxx\ud800.'


(I think I've included everything:
- normal chars
- control chars
- one-byte non-ASCII
- two-byte non-ASCII (and lone surrogate)
- printable and non-printable surrogate pairs)
- single and double quotes)

--

___
Python tracker 

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

[issue9805] Documentation on old-style formatting of dicts is overly restrictive

[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

[issue9804] ascii() does not always join surrogate pairs

[STINNER Victor]

STINNER Victor  added the comment:

For unicode, ascii(x) is implemented as repr(x).encode('ascii', 
'backslashreplace').decode('ascii').

repr(x) is "'" + x + "'" for printable characters (eg. U+1D121), and "'U+%08x'" 
% ord(x) for not printable characters (eg. U+12FFF).

About the unexpected output, the problem is that ascii+backslashreplace encodes 
non-BMP printable characters as b'\\u\\u' in narrow builds.

I don't see simple solution to encode non-BMP characters as b'\\U' 
because the principle of error handler is that it escapes non encodable 
characters one by one.

--

___
Python tracker 

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

[issue9757] Add context manager protocol to memoryviews

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> On an eyeball review, the structure of do_release seems a little
> questionable to me. I'd be happier if view.obj and view.buf were
> copied to C locals and then set to NULL at the start of the function
> before any real work is done.

You can't do that, since PyBuffer_Release() needs the information (at
least `obj`, and then the underlying object might rely on `buf` in its
bf_releasebuffer method).

(note, this code is simply factored out from tp_dealloc)

> For the test code, I suggest including:
> - a test where release() is called inside the cm to check that
> __exit__ does not raise ValueError.
> - check getbuffer() correctly raises ValueError
> - tests that the other properties correctly raise ValueError (ndim,
> shape, strides, format, itemsize, suboffsets)

Ok. I was bit too lazy and didn't include all the API.

> (For the properties, perhaps using a list of strings, a loop and
> getattr rather than writing each one out separately)

It's more clever but less practical if there's a failure: you can't know
up front which property failed the test.

> _check_released should perhaps also take a second argument that is
> used for the last two NotEqual checks. That is:

Hmm, why not.

> There's also a minor typo in a comment in the tests: "called at
> second" should be "called a second".

Ah, thanks.

> One other question: should IS_RELEASED use "||" rather than "&&"?
> 
> Is there any case where either of those pointers can be NULL and we
> still want to continue on rather than bailing out with a ValueError?

Well, view.obj can be NULL in case the buffer has been filled by hand by
some C code which simply wants to export a lazy view to some chunk of
memory (the IO lib uses this).

I could simply test for view.buf. I was thinking that maybe NULL could
be a proper data pointer on some platforms, but that would probably be
crazy (since using NULL as "non initialized" or "failed doing something"
is so common in C code).

--

___
Python tracker 

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

[issue9794] socket.create_connection context manager

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Committed in r84639.

--
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

[issue9794] socket.create_connection context manager

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Patch which updates doc is in attachment.

--
Added file: http://bugs.python.org/file18804/socket_ctx_mgr.patch

___
Python tracker 

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

[issue9805] Documentation on old-style formatting of dicts is overly restrictive

[Ken Basye]

Ken Basye  added the comment:

If someone's going to fix this, perhaps they might consider also adding the 
following clarification sentence after 'The mapping key selects the value to be 
formatted from the mapping.'  

The mapping key is interpreted as a string; a key error is raised if the 
dictionary does not have a matching string key. 

I don't think it's worth adding it, but consider this example:
>>> d = {2:2, '2':'two'}
>>> '%(2)s' % d
'two'

--

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Fixed in r84635, r84636, r84638 (3.x) and r84637 (2.7). Also prompted the 
creation of issue9804.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue9129] DoS smtpd module vulnerability

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Reopening. I'll backport this at some point during this week, I hope.

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

___
Python tracker 

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

[issue9805] Documentation on old-style formatting of dicts is overly restrictive

[Ken Basye]

New submission from Ken Basye :

>From http://docs.python.org/library/stdtypes.html#string-formatting-operations 
>:

"When the right argument is a dictionary (or other mapping type), then the 
formats in the string must include a parenthesised mapping key into that 
dictionary inserted immediately after the '%' character."  
(with emphasis on 'must' in the HTML, BTW).  

This isn't correct:  "%s" % dict() is a perfectly legal expression with a 
dictionary as the right argument and no mapping key in the formats.  Indeed, if 
the current doc were correct, there would apparently be no way to format an 
empty dictionary.

How about this one-word fix:

"When the right argument is a dictionary (or other mapping type), then the 
formats in the string may include ..." and so on into the next sentence, and no 
emphasis on 'may'.






P.S. Not sure about the Type of this issue, and it's present in both 2.7 and 
current 3.X doc.

--
assignee: d...@python
components: Documentation
messages: 115907
nosy: Ken.Basye, d...@python
priority: normal
severity: normal
status: open
title: Documentation on old-style formatting of dicts is overly restrictive
versions: Python 2.7

___
Python tracker 

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

[issue9802] Document 'stability' of builtin min() and max()

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: d...@python -> rhettinger

___
Python tracker 

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

[issue9129] DoS smtpd module vulnerability

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

You're right, I'm sorry. I looked at "Versions" field which has 2.6 set but 
it's not correct.

--

___
Python tracker 

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

[issue9804] ascii() does not always join surrogate pairs

[Antoine Pitrou]

New submission from Antoine Pitrou :

This is on an UCS-2 py3k build:

>>> ascii('\U00012FFF')
"'\\U00012fff'"
>>> ascii('\U0001D121')
"'\\ud834\\udd21'"

--
components: Interpreter Core, Unicode
messages: 115905
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ascii() does not always join surrogate pairs
type: behavior
versions: 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

[issue9757] Add context manager protocol to memoryviews

[Nick Coghlan]

Nick Coghlan  added the comment:

One other question: should IS_RELEASED use "||" rather than "&&"?

Is there any case where either of those pointers can be NULL and we still want 
to continue on rather than bailing out with a ValueError?

--

___
Python tracker 

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

[issue9757] Add context manager protocol to memoryviews

[Nick Coghlan]

Nick Coghlan  added the comment:

On an eyeball review, the structure of do_release seems a little questionable 
to me. I'd be happier if view.obj and view.buf were copied to C locals and then 
set to NULL at the start of the function before any real work is done.

I believe the buffer release process can trigger __del__ methods (and possibly 
other Python code), which may currently see the memoryview in a slightly 
inconsistent state when reference cycles are involved. Setting these two 
references to NULL early should keep that from happening (the idea of using C 
locals to avoid this is the same concept as is employed by the Py_CLEAR macro)

For the test code, I suggest including:
- a test where release() is called inside the cm to check that __exit__ does 
not raise ValueError.
- check getbuffer() correctly raises ValueError
- tests that the other properties correctly raise ValueError (ndim, shape, 
strides, format, itemsize, suboffsets)

(For the properties, perhaps using a list of strings, a loop and getattr rather 
than writing each one out separately)

_check_released should perhaps also take a second argument that is used for the 
last two NotEqual checks. That is:

def _check_released(self, m, tp):
  ...
  self.assertNotEqual(m, memoryview(tp()))
  self.assertNotEqual(m, tp())

And then pass in tp as well as m for the respective tests.

There's also a minor typo in a comment in the tests: "called at second" should 
be "called a second".

Other than that, looks good to me.

--

___
Python tracker 

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

[issue2745] Add support for IsWow64Process

[Brian Curtin]

Brian Curtin  added the comment:

os.environ["PROCESSOR_ARCHITEW6432"] will tell you the true underlying 
processor architecture when under WOW. Therefore, if you find that this 
variable exists, you are under WOW.

Example, on my 64-bit machine with a 32-bit compiled Python:

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ["PROCESSOR_ARCHITECTURE"]
'x86'
>>> os.environ["PROCESSOR_ARCHITEW6432"]
'AMD64'

--
nosy: +brian.curtin

___
Python tracker 

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

[issue9129] DoS smtpd module vulnerability

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

No, it isn't in 2.6 branch.

--

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Dave Malcolm]

Dave Malcolm  added the comment:

"I don't think this" was of course a browser misfire; I meant to type "I don't 
think this should block committing this fix"

--

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Dave Malcolm]

Dave Malcolm  added the comment:

One minor quibble with the patch:

In the line:
   while i < field_length:
you're trusting that field_length has a sane value.  If field_str points 
somewhere readable, and field_length is huge (e.g. 0xfff), then gdb could 
sit there for a while reading all that data until it either completes, or hits 
memory that it can't read (leading to a python exception within gdb).

In other places in that code I used safe_range() to limit iterations to a 
safety threshold; I suggest the use of
  safety_limit(field_length)

But this is a minor nit.


I don't think this

--

___
Python tracker 

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

[issue9802] Document 'stability' of builtin min() and max()

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the patch!

Comments:

(1) Shouldn't 'reverse=True' be omitted in the second doc addition?

(2) I'd also suggest adding a brief comment about what this means for distinct, 
but equal, objects;  otherwise it's not really obvious what the point of the 
doc addition is.

(3) As a matter of clarity, perhaps replace "this is" with "max(iterable, 
key=key) is", and similarly for min.

As an aside, I still like Jeffrey Yasskin's suggestion on the python-dev 
mailing list that the sensible definition for max would maintain the invariant 
that max(iterable) be equivalent to sorted(iterable)[-1];  see Alexander 
Stepanov's writings in e.g., 
http://www.cs.rpi.edu/~musser/gsd/notes-on-programming-2006-10-13.pdf for more. 
 But that's (a) another issue, and (b) perhaps not a significant enough benefit 
to be worth changing Python's semantics for.

--
nosy: +jyasskin, mark.dickinson, rhettinger

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Dave Malcolm]

Dave Malcolm  added the comment:

where "works" means: all tests in test_gdb.py were run, and passed.

This was with a --with-pydebug-build in each case

--

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Dave Malcolm]

Dave Malcolm  added the comment:

Tested with UCS4 gdb:
(gdb) python import sys; print hex(sys.maxunicode)
0x10

using latest py3k.

Works with both UCS2 and UCS4 builds of py3k

--

___
Python tracker 

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

[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is a patch for 3.x, tested in the following situations:
- gdb: UCS2, inferior: UCS2
- gdb: UCS2, inferior: UCS4

--
Added file: http://bugs.python.org/file18803/test_gdb2.patch

___
Python tracker 

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

[issue9803] IDLE closes with save while breakpoint open

[James Hutchison]

New submission from James Hutchison :

I have multiple versions of python - 2.6.1 and 3.1.2. 2.6.1 is the primary 
install (i.e., right click on a file and "edit with IDLE" brings up 2.6), and 
was installed first. This issue occurs on 3.1.2, Windows XP 32-bit

If I highlight a breakpoint, run with the debugger, make a change, then save, 
IDLE will close all windows after saving without an error message. If I clear 
the breakpoint and then save, IDLE will not close. Reopening the file reveals 
that the save was successful. I do not need to actually be stopped at a 
highlighted breakpoint for this to occur (i.e. this will occur if I save at the 
beginning before the script has ran). If I run with 2.6.1 I do not see this 
issue. The save difference could be something simple, such as adding a space 
somewhere random.

--
components: IDLE
messages: 115894
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: IDLE closes with save while breakpoint open
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

[issue9054] pyexpat configured with "--with-system-expat" is incompatible with expat 2.0.1

[Matthias Klose]

Matthias Klose  added the comment:

validated with 3.2, the interpreter doesn't crash anymore and all expat tests 
succeed.

should be applied for 2.7, 3.1 and 3.2.

--
nosy: +doko
versions: +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

[issue9802] Document 'stability' of builtin min() and max()

[Matthew Woodcraft]

New submission from Matthew Woodcraft :

In CPython, the builtin max() and min() have the property that if there are 
items with equal keys, the first item is returned. From a quick look at their 
source, I think this is true for Jython and IronPython too.

I propose making this a documented guarantee.

On Python-dev, Raymond Hettinger said:
<<
That seems like a reasonable request. This behavior has been around for a very 
long time is unlikely to change. Elsewhere, we've made efforts to document sort 
stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc).
>>
()

I'm attaching a patch with a concrete suggestion for a change to
functions.rst, modelled on the documentation of heapq.nlargest().

--
assignee: d...@python
components: Documentation
files: maxmin.patch
keywords: patch
messages: 115892
nosy: d...@python, mattheww
priority: normal
severity: normal
status: open
title: Document 'stability' of builtin min() and max()
type: feature request
Added file: http://bugs.python.org/file18802/maxmin.patch

___
Python tracker 

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

[issue9801] Can not use append/extend to lists in a multiprocessing manager dict

[James Hutchison]

New submission from James Hutchison :

tested python 3.1.2

Man = multiprocessing.Manager();
d = man.dict();
d['l'] = list();
d['l'].append("hey");
print(d['l']);
>>> []

using debugger reveals a KeyError. Extend also does not work. Only thing that 
works is += which means you can't insert actual tuples or lists into the list. 
This was all done on a single process

--
components: Library (Lib)
messages: 115891
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Can not use append/extend to lists in a multiprocessing manager dict
type: behavior

___
Python tracker 

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

[issue9757] Add context manager protocol to memoryviews

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a new patch adding the release() method as well.

--
Added file: http://bugs.python.org/file18801/memcontext2.patch

___
Python tracker 

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

[issue9786] Native TLS support for pthreads

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text correctly

[STINNER Victor]

STINNER Victor  added the comment:

> My remark is that utf-8 tend to be applied to all kind of files;
> if someone once decide that non-ascii chars are allowed in (some) 
> string constants, they will be stored in utf-8.

In this case, it will be better to raise an error on non-ascii byte (character) 
in the format string. It's better to raise an error than to interpret utf-8 as 
iso-8859-1 (mojibake!). Since nobody noticed this bug 
(PyFormat_FromString/PyErr_Format expects ISO-8859-1), I suppose that nobody 
uses non-ASCII format string is always ascii.

Python builtin errors are not localised. If an application uses gettext, I 
suppose that the error will be raised in the Python code, not in the C API.

Attached patch changes PyFormat_FromStringV (and so PyFormat_FromString and 
PyErr_Format) to reject non-ascii byte (character) in the format string. I 
added a test and documented the format string encoding (which is now ASCII). 
See also #9738 for the documentation about function argument encoding.

--
keywords: +patch
Added file: http://bugs.python.org/file18800/pyunicode_fromformat_ascii.patch

___
Python tracker 

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

[issue9800] Fast path for small int-indexing of lists and tuples

[Antoine Pitrou]

New submission from Antoine Pitrou :

This is an experiment which turns out to yield little benefits, except on 
micro-benchmarks such as:

$ ./python -m timeit -s "a=[1,2,3]" 
"a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];"

-> before: 100 loops, best of 3: 1.14 usec per loop
-> after: 100 loops, best of 3: 0.759 usec per loop

On IRC, Raymond pointed out that the long representation is not very friendly 
to direct manipulation for small ints, but even then it's not obvious it would 
benefit a lot: a large amount of time is certainly spent accessing the Python 
stack, manipulating reference counts, decoding opcodes and checking array 
bounds.

The conclusion could be that such special-casing is futile when the body of 
code it avoids executing isn't big enough. Also, adding runtime checks has its 
own performance cost (more CPU instructions to execute, possible pipeline 
flushes due to branch misprediction, and pollution of branch prediction caches).

--
components: Interpreter Core
files: evalsubscr.patch
keywords: patch
messages: 115888
nosy: mark.dickinson, pitrou, rhettinger
priority: low
severity: normal
status: open
title: Fast path for small int-indexing of lists and tuples
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18799/evalsubscr.patch

___
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

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

By the way, all traces of 0711-596 on the Web seem to point to IBM compiler 
errata. Apparently xlc tries to support computed gotos (which is originally a 
GCC-specific feature) but doesn't do it very well.

The support for computed gotos is detected automatically by the configure 
script; --without-computed-gotos helps override the detection.

I would close this issue as a compiler bug, especially given that there's a 
configure switch to circumvent it.

--
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue4026] fcntl extension fails to build on AIX 6.1

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Thanks Michael, your new test looks fine to me.

I wanted to test it on my AIX system with branch py3k but I had some other 
issues (issue 9799), but I will test it tomorrow.

--
versions: +Python 2.6, Python 3.3

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Yes it works if I explicitly specify --without-computed-gotos

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Bingo, you got it.
> 
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
> r83900 = OK
> r83950 = OK
> r83985 = OK
> r83986 = ERR
> r84000 = ERR
> r84522 = ERR
> 
> It was commited by some guy named "antoine.pitrou" ;)
> 
> The linker thinks that we have some symbol named "0" or something like that.
> I guess the xlc compiler is not happy with one of the uses of the 
> USE_COMPUTED_GOTOS constant.

So if you configure --without-computed-gotos, does it compile fine?

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Bingo, you got it.

r73580 = OK
r83318 = OK
r83584 = OK
r83800 = OK
r83900 = OK
r83950 = OK
r83985 = OK
r83986 = ERR
r84000 = ERR
r84522 = ERR

It was commited by some guy named "antoine.pitrou" ;)

The linker thinks that we have some symbol named "0" or something like that.
I guess the xlc compiler is not happy with one of the uses of the 
USE_COMPUTED_GOTOS constant.

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mercredi 08 septembre 2010 à 15:28 +, Sébastien Sablé a écrit :
> Sébastien Sablé  added the comment:
> 
> For the moment I have:
> 
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
> 
> r84000 = ERR

Then perhaps r83985 / r83986.

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Sébastien Sablé]

Sébastien Sablé  added the comment:

For the moment I have:

r73580 = OK
r83318 = OK
r83584 = OK
r83800 = OK

r84000 = ERR
r84522 = ERR

--

___
Python tracker 

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

[issue8849] python.exe problem with cvxopt

[R. David Murray]

R. David Murray  added the comment:

cvxopt looks like it includes a C-based extension module.  Have you reported 
the bug to cvxopt?  They are more likely to be able to spot the problem and 
determine if it is a bug in Python or their code.

--
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

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

[Vinay Sajip]

Vinay Sajip  added the comment:

Just plain

./configure

as far as I remember.

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I would suggest trying r80723 and then r80724.

--
nosy: +pitrou

___
Python tracker 

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

[issue9786] Native TLS support for pthreads

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ah, good to hear.

--

___
Python tracker 

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

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Antoine, I wanted to test this improvement (and others) on the branch py3k (I 
was using Python 2.7 and Python 3.1.2 for the moment). But I have some issues 
compiling this branch, even without any patch (see issue 9799).

So you may want to wait for the other issue to be resolved before to commit 
this patch on branch py3k.

--

___
Python tracker 

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

[issue9799] Compilation error for branch py3k on AIX 6

[Sébastien Sablé]

New submission from Sébastien Sablé :

I have the following error when compiling the last rev of branch py3k on an AIX 
6 system:

./Modules/makexp_aix Modules/python.exp . libpython3.2.a;  xlc_r 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
 
-L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib
  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 
-Wl,-bE:Modules/python.exp -lld -o python Modules/python.o libpython3.2.a 
-lintl -ldl-lm  
ld: 0711-596 SEVERE ERROR: Object libpython3.2.a[ceval.o]
An RLD for section 2 (.data) refers to symbol 0,
but the storage class of the symbol is not C_EXT or C_HIDEXT.

Python 3.1.2 or Python 2.7 both compile fine.

I also tried rev 73580 of this branch which compiled fine also.

I will try to find the rev number where this problem started.

--
messages: 115875
nosy: sable
priority: normal
severity: normal
status: open
title: Compilation error for branch py3k on AIX 6
type: compile error
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

[issue9752] MSVC Compiler warning in Python\import.c

[Jon Anglin]

Jon Anglin  added the comment:

How about this: see no-macro.diff
BTW: should I be using the .patch extension or .diff extension?

--
Added file: http://bugs.python.org/file18798/no-macro.diff

___
Python tracker 

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

[issue9798] time.tzset() doesn't properly reset the time.timezone variable

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the link, but I don’t think it’s related :). Look at the sample code 
again, this is just a regular name/variable confusion.

--

___
Python tracker 

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

[issue9798] time.tzset() doesn't properly reset the time.timezone variable

[Brian Curtin]

Brian Curtin  added the comment:

#6478 looks related

--
nosy: +brian.curtin

___
Python tracker 

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

[issue9798] time.tzset() doesn't properly reset the time.timezone variable

[Éric Araujo]

Éric Araujo  added the comment:

More information here: 
http://docs.python.org/tutorial/classes#a-word-about-names-and-objects

--

___
Python tracker 

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

[issue9798] time.tzset() doesn't properly reset the time.timezone variable

[Éric Araujo]

Éric Araujo  added the comment:

The name “timezone” you imported in test-timezone is bound to the object that 
was bound to time.timezone at the time of import. When time.timezone is bound 
to a new object, test-timezone.timezone does not change.

--
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue9752] MSVC Compiler warning in Python\import.c

[Brian Curtin]

Brian Curtin  added the comment:

Thanks for looking into that.

Since we now know that there is no use for the mode parameter on Windows, let's 
just remove the mode related stuff (of course leaving it for other OSes). We 
could then remove the macro and do the #ifdef dance around the mkdir/_mkdir 
call.

--
stage: needs patch -> patch review

___
Python tracker 

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

[issue4026] fcntl extension fails to build on AIX 6.1

[Michael Haubenwallner]

Michael Haubenwallner  added the comment:

Sébastien, while this gives expected results on the AIX box here, it still has 
one subtle problem:
AC_TRY_LINK may fail due to missing declaration in  _or_ due to 
missing implementation in libc.
The subsequent AC_CHECK_LIB won't fail when the implementation is in libbsd but 
the declaration is missing - this is the case on not-so-recent AIX5.3 (and the 
reason python worked there before).

Another minor nit is configure's output when libbsd is needed:
> checking for flock... checking for flock in -lbsd... yes
> yes

Anyway - I've hacked up another variant (with recent autoconf manual at hand), 
which really should cover all known situations now (additionally using 
cache-checks):

AC_CACHE_CHECK([for flock declaration], [ac_cv_flock_decl],
  [AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
  [#include ],
  [void* p = flock]
)],
[ac_cv_flock_decl=yes],
[ac_cv_flock_decl=no]
  )
])
if test "x${ac_cv_flock_decl}" = xyes; then
  AC_CHECK_FUNCS(flock,,
AC_CHECK_LIB(bsd,flock,
  [AC_DEFINE(HAVE_FLOCK)
   AC_DEFINE(FLOCK_NEEDS_LIBBSD, 1, Define if flock needs to be linked with 
bsd library.)
])
  )
fi

Thank you anyway!

--

___
Python tracker 

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

[issue5416] str.replace does strange things when given a negative count

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Reverted the changes in r84626 (release27-maint), r84629(py3k), r84630 
(release31-maint).

- Minor doc clarification included wherein maxreplace is the argument instead 
of maxsplit in py27.

- Also, did not bother to remove -1 in maxreplace. It is used as sentinel value 
for an optional argument. As it is not explicitly documented, the negative 
value for arg should not be relied upon.

--
status: open -> closed

___
Python tracker 

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

[issue9797] wrong assumption in pystate.c

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r84623 (3.x), r84627 (2.7) and r84628 (3.1).

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue941346] AIX shared library fix

[Sébastien Sablé]

Changes by Sébastien Sablé :


Added file: 
http://bugs.python.org/file18797/python312_AIX61_shared_gcc_patchshared.txt.gz

___
Python tracker 

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

[issue941346] AIX shared library fix

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Here are the build logs for Python 3.1.2 modified with this patch and compiled 
with gcc.
The extensions are correctly built.

I also compiled an extension not directly provided in Python source (cx_Oracle) 
and it worked fine also.

--
Added file: 
http://bugs.python.org/file18796/python312_AIX61_static_gcc_patchshared.txt.gz

___
Python tracker 

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

[issue9798] time.tzset() doesn't properly reset the time.timezone variable

[Peter Simons]

New submission from Peter Simons :

Attached are two programs that I would expect to produce the same output, but 
they don't.

$ python --version
Python 2.6.5

$ cat test-timezone-1.py 
import os, time

os.environ["TZ"] = "Europe/Berlin"
time.tzset()
print "time.timezone =", time.timezone

os.environ["TZ"] = "Egypt"
time.tzset()
print "time.timezone =", time.timezone

$ cat test-timezone-2.py 
import os
from time import tzset, timezone

os.environ["TZ"] = "Europe/Berlin"
tzset()
print "timezone =", timezone

os.environ["TZ"] = "Egypt"
tzset()
print "timezone =", timezone

$ python test-timezone-1.py 
time.timezone = -3600
time.timezone = -7200

$ python test-timezone-2.py 
timezone = -3600
timezone = -3600

--
components: Library (Lib)
messages: 115864
nosy: simons
priority: normal
severity: normal
status: open
title: time.tzset() doesn't properly reset the time.timezone variable
type: behavior
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

[issue3871] cross and native build of python for mingw32 with distutils

[Руслан Ижбулатов]

Руслан Ижбулатов  added the comment:

A small correction to previous post: two new compiler-and-linker types, not one.

First - MinGW toolset without MSys, working with normal Windows command 
interpreter, which can be invoked simply by calling "cmd" (or whatever we get 
from %ComSpec%). Obviously, it doesn't work. Well, it works, but only ~5% of 
all software packages will have a makefile that doesn't have to be generated by 
configure script (which we can't run, since this variant of MinGW doesn't have 
bash) and that doesn't call any shell builtins or *nix tools. On the other 
hand, SCons, CMake and other build systems not based on autotools should work 
fine without bash and/or should be able to generate makefiles that don't rely 
on bash or *nix tools.

Second - MinGW toolset with MSys, working with bash, which can't be invoked by 
calling "sh.exe" (even if you have full absolute path to sh.exe), because you 
must cast a few black magic spells by calling sh.exe with "--login" to hook up 
/etc/profile, which sets up PATH and other environment variables; without it 
you won't be able to run anything that isn't in c:/msys/1.0/bin - including 
mingw32-gcc.exe, which lives in c:/mingw/bin, unless you'd want to duplicate 
/etc/profile in Python (which is possible, remind me to try that), and you have 
to be careful to not give it any \-separated paths (even in scaped form) at 
command line, because bash won't understand them, and path mangling doesn't 
kick in until you're *within* bash, and that includes the name of the script 
you want to run - it must be /-separated and not absolute (because bash will 
pass it as $0 without mangling).

--

___
Python tracker 

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

[issue9752] MSVC Compiler warning in Python\import.c

[Jon Anglin]

Jon Anglin  added the comment:

Visual Studio ships with the source code for the CRT (\Program Files\Microsoft 
Visual Studio 9.0\VC\crt\src). I looked up _mkdir. It does just call 
CreateDirectory(path, NULL).  If no error occurs it returns zero. If an error 
occurs, it then converts the result of GetLastError to an appropriate errno 
code and returns -1.

Thus the following calls are equivalent:
_mkdir(dirname);
CreateDirectory(dirname, NULL);

--

___
Python tracker 

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

[issue9797] wrong assumption in pystate.c

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, it is simpler indeed. Here is an updated patch.

--
Added file: http://bugs.python.org/file18795/autotlskey2.patch

___
Python tracker 

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

[issue9797] wrong assumption in pystate.c

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Couldn't the patch use autoInterpreterState instead?
It is already modified at the same times as autoTLSkey.

--

___
Python tracker 

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

[issue9786] Native TLS support for pthreads

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The problem turns out to be in pystate.c (my system returns 0 as a valid key 
number). See issue #9797.

--
dependencies: +wrong assumption in pystate.c

___
Python tracker 

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

[issue9797] wrong assumption in pystate.c

[Antoine Pitrou]

New submission from Antoine Pitrou :

pystate.c assumes that when autoTLSkey is 0, it hasn't been created yet. 
However, some TLS implementations can return 0 as a valid key value. Lots of 
interesting things then happen.

Here is a patch.

--
files: autotlskey.patch
keywords: patch
messages: 115858
nosy: amaury.forgeotdarc, krisvale, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: wrong assumption in pystate.c
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18794/autotlskey.patch

___
Python tracker 

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

[issue4947] sys.stdout fails to use default encoding as advertised

[STINNER Victor]

STINNER Victor  added the comment:

I commited my patch (with a new test, iso-8859-1:replace) to 2.7: r84621. I 
will no backport to 2.6 because this branch now only accept security fixes.

--
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

[issue3871] cross and native build of python for mingw32 with distutils

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton  added the comment:

sorry to have to ask, but could we get some feedback please so that this issue 
may move forward?  currently there is a conflict between what is required and 
what is stated as being "absolute law".

let's imagine that it is reasonable to expect distutils2 to be used.  python 
proceeds with the mingw32 patches using distutils2, python 2.N is compiled and 
released.  an average user installs python 2.N mingw32 and they run "python 
setup.py install" on a package - what happens?

they get a compile error, don't they?

why do they get a compile error?

because the setup.py tries to build some c code, and at the top of *their* 
setup.py is "import distutils".

so you now force thousands of developers to patch a their setup.py scripts 
- scripts which have worked for years - _just_ so that those packages can cope 
with the use of distutils2 for the mingw32 platform?

so we have another "reducto ad absurdum" which demonstrates that it is 
impractical to expect distutils to be frozen.

thus, we are forced to consider alternative options, such as "monkey-patching" 
of distutils, to satisfy the requirements.

would the following be acceptable, to be inserted somewhere in the path so that 
it is guaranteed to work at all times?

import mingw32_distutils_compiler
import sys
if "distutils.compiler" in sys.modules:
sys.modules['distutils.compiler'] = mingw32_distutils_compiler


where mingw32_distutils_compiler performs an import of distutils.compiler and 
performs a monkey-patch mish-mash to combine and replace various parts of the 
compiler module at run-time, to get round the "freeze" objections.

would that be acceptable?  please say no, because the long-term viability and 
maintainability of such practices is virtually nil.

basically i'm pointing out to you, eric, that the freeze on distutils is 
unworkable and impractical and unnecessary.

this isn't "bug-fixing" of distutils, it's absolutely necessary and critically 
required because this is an entirely new platform.

* it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks.

* it's not standard unix gcc: you need to output ".dll" not ".so"

* it's not msvc: mingw32-gcc doesn't accept "/this /that" for options.

therefore i'm very sorry to have to spell it out but a new compiler and linker 
type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type 
- IS required in order to cater for this platform, and there's no getting away 
from that fact.

please could we have some acknowledgement of this fact, and acceptance of this 
fact, and a plan for moving forward with careful review of this patch, so that 
LRN and others do not have their time spent pursuing a direction involving 
distutils2 which will be completely fruitless?

many many thanks,

l.

--

___
Python tracker 

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

[issue2745] Add support for IsWow64Process

[Pete Bartlett]

Pete Bartlett  added the comment:

Hi,

I am a Python user seeking an implementation of iswow64 and found this tracker. 
Unfortunately I don't think Martin's suggested alternative approach works.

os.environ["PROCESSOR_ARCHITECTURE"]

returns "x86" on my system when run from a 32-bit python, even though if I look 
at my "real" environment I see 

D:\>echo %PROCESSOR_ARCHITECTURE%
AMD64

i.e it appears that Windows is passing "false information", if you will, to 
whatever populates os.environ in 32-bit windows.

Perhaps Mark's patch should be resurrected. Or is there a further way to get 
this information?

[My Python version information:
D:\>python
ActivePython 2.6.5.12 (ActiveState Software Inc.) based on
Python 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC v.1500 32 bit (Intel)] on 
win32
]

--
nosy: +pcb21

___
Python tracker 

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

[issue9632] Remove sys.setfilesystemencoding()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> "keep the C function"
> 
> Hum, currently, Python3 only has a *private* function called 
> _Py_SetFileSystemEncoding() which can only be called after _Py_InitializeEx() 
> (because it relies on the codecs API). If you consider that there is a real 
> use case, we should create a function to set the filesystem encoding, 
> function that should (have to?) be called before Py_InitializeEx().
> 
> I still think that Python knows better than the application how to set the 
> encoding (when, how to choose it, etc.).

If you embed Python into another application, say as scripting
language for that application, that other application may have
completely different requirements for the user setup than Python
expects, e.g. for a Windows GUI application it's not feasible to
ask the user to change the environment variables via the registry
in order for Python to pick up the right encoding information.

What we'd need is a way for the embedding application to provide this
information in a way that doesn't require setting up the environment
in some special way. The application will likely have its own way
of configuring things like file system or I/O stream encodings. Think
of e.g. GTK or Qt applications as example.

The Py_InitializeEx() function sounds like a good idea to pass the
information about such important extra parameters to Python. This
could take arguments for setting the file system encoding as
well as the I/O encoding. The arguments would then override the env var
settings.

So you can remove the function, but have to keep a backdoor open
for use cases like the one I described above.

The Py_InitializeEx()
function approach would also avoid all the issues that you have
with calling _Py_SetFileSystemEncoding() after the interpreter
has been initialized.

--

___
Python tracker 

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

[issue6114] distutils build_ext path comparison only based on strings

[Sven Rebhan]

Sven Rebhan  added the comment:

Of course there is a secret distutils comunity using git! ;-) The three ppl 
mentioned there found and fixed the problem, that's why.

But back to the issue: Can we use a switch or wrapper function to change the 
test method for this path dependent on the OS? I'm asking because in windows 
there might be no symlink either and everything just works(tm).

--

___
Python tracker 

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

[issue9796] Add summary tables for unittest API

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Just focus on the table for assert* methods.  This is the one category that 
users will need to look-up over and over again.  The goal is to make the docs 
more usable, not more voluminous.

Also, I suggest finding meaningful groupings (don't stick with alpha order) and 
including a short plain assert-statement equivalents to show what the methods 
actual do (this is important because many are new, some are obscure, and not 
all have obvious semantics):

 | assertEqual(x, y)  | assert x == y  |
 | assertGreaterThan(x, y)| assert x > y   |
 | assertItemsEqual(act, exp) | assert sorted(exp) == sorted(act)  |

--

___
Python tracker 

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