[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

2009-07-04 Thread James William Pye

James William Pye  added the comment:

Seeing this in 3.1 when I try to compile with mingw32 under wine:

"error: Unable to find vcvarsall.bat"


--compiler=mingw32 works in 3.0. I assume it's related to this bug?

--
nosy: +jwp
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



[issue5910] kqueue for more than one event is broken.

2009-07-04 Thread Henry Precheur

Henry Precheur  added the comment:

I tested the patch with py3k on OpenBSD 4.6 beta and it worked.

But I must admit I don't fully understand what the patch does ...

--
nosy: +henry.precheur

___
Python tracker 

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



[issue6419] Broken test_kqueue.py on OpenBSD

2009-07-04 Thread Henry Precheur

New submission from Henry Precheur :

A kqueue's test doesn't pass on OpenBSD 4.6-beta, 4.4, & 4.5:

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_kqueue.py", line 186, in 
test_main()
  File "Lib/test/test_kqueue.py", line 183, in test_main
support.run_unittest(TestKQueue)
  File "/home/henry/py3k/Lib/test/support.py", line 882, in run_unittest
_run_suite(suite)
  File "/home/henry/py3k/Lib/test/support.py", line 865, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_kqueue.py", line 119, in test_queue_event
(server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(6, -2, 5), (7, -2, 5)] != [(6, -2, 0),
(7, -2, 0)]

First differing element 0:
(6, -2, 5)
(6, -2, 0)

- [(6, -2, 5), (7, -2, 5)]
?  ^   ^

+ [(6, -2, 0), (7, -2, 0)]
?  ^   ^

It looks like OpenBSD behaves like Darwin. The attached patch fixes the
test.

--
files: patch-Lib_test_test_kqueue_py
messages: 90127
nosy: henry.precheur
severity: normal
status: open
title: Broken test_kqueue.py on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14449/patch-Lib_test_test_kqueue_py

___
Python tracker 

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



[issue6420] Fix warning in nismodule.c on OpenBSD

2009-07-04 Thread Henry Precheur

New submission from Henry Precheur :

On OpenBSD the file /usr/include/rpcsvc/ypclnt.h contains the following
declaration:

struct ypall_callback {
/* return non-0 to stop getting called */
int (*foreach)(unsigned long, char *, int, char *, int, void *);
char *data; /* opaque pointer for use of callback fn */
};

the 'foreach' function pointer's declaration in Modules/nismodule.c is
different:

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude
-I/home/henry/py3k -c /home/henry/py3k/Modules/nismodule.c -o
build/temp.openbsd-4.6-amd64-3.2/home/henry/py3k/Modules/nismodule.o
/home/henry/py3k/Modules/nismodule.c: In function `nis_cat':
/home/henry/py3k/Modules/nismodule.c:208: warning: assignment from
incompatible pointer type


The attached patch fixes this very important issue :)

--
components: Build, Library (Lib)
files: patch-Modules_nismodule_c
messages: 90128
nosy: henry.precheur
severity: normal
status: open
title: Fix warning in nismodule.c on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14450/patch-Modules_nismodule_c

___
Python tracker 

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



[issue6419] Broken test_kqueue.py on OpenBSD

2009-07-04 Thread Henry Precheur

Changes by Henry Precheur :


--
components: +Tests

___
Python tracker 

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



[issue1741130] struct.pack("I", "foo"); struct.pack("L", "foo") should fail

2009-07-04 Thread Mark Dickinson

Mark Dickinson  added the comment:

Here's a patch that does some general cleanup of the object->integer 
helper functions in the struct module;  in the process, it fixes this 
bug.  With this patch, all conversions from a PyObject to a C integer go 
through get_pylong, so they're all treated the same way.  Currently 
(i.e., without the patch) there's a lack of consistency in the way the 
various integer codes are handled---some codes emit a warning for float 
conversions and some ('q', 'Q') don't;  some codes will happily convert 
a Decimal instance, and others won't.  Some codes produce this strange 
'unsupported operand types' message and some don't, etc.

--
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file14451/issue1741130.patch

___
Python tracker 

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



[issue3410] platform.version() don't work as expected in Vista in portuguese

2009-07-04 Thread Marc-Andre Lemburg

Marc-Andre Lemburg  added the comment:

Ezio Melotti wrote:
> Ezio Melotti  added the comment:
> 
> The Vista machine is running Py 2.5.2 but is not mine so I can't
> test/debug the issue properly there. FWIW I tried win32_ver() on it and
> I got ('', '6.0.6002', 'SP2', 'Multiprocessor Free').

Interesting. Looking at the code in win32_ver() should be getting
one of ('Vista', '2008Server', 'post2008Server'), but not '' for the
release.

> Here on WinXP with 2.6 I get ('XP', '5.1.2600', 'SP2', u'Uniprocessor
> Free') (why only the last is unicode?).

Do you have the win32 tools installed on that machine ? This could
be the reason.

> On Monday I'll have access to more Windows machines (including Vista)
> but they are all in English. If there's something that I should try
> there let me know.

Please check the results of win32_ver() on those machines. The
release part should always be set.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com



::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--

___
Python tracker 

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



[issue3410] platform.version() don't work as expected in Vista in portuguese

2009-07-04 Thread Ezio Melotti

Ezio Melotti  added the comment:

> Do you have the win32 tools installed on that machine ? This could
> be the reason.

On my XP machine I have them installed for Py 2.4 only, "import
win32api" fails on Py 2.6.
"platform.win32_ver()" returns the same with both the versions, but on
Py 2.4 they are all plain strings, on Py 2.6 the last string is Unicode
(and on Py 3 they are all Unicode).

I'll let you know about the result of win32_ver() on the other machines.

--

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Tim Gordon

Tim Gordon  added the comment:

__add__ is non-commutative for lists, tuples, strings etc. - perhaps 
non-commutative wasn't quite what you were looking for :p.

--
nosy: +QuantumTim
status: pending -> open

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Jean-Paul Calderone

Jean-Paul Calderone  added the comment:

Why so much opposition to the shorter spelling of .copy() & .update()? 
As Tim pointed out, lists, tuples, and strings all provide this
shortcut.  Why not dicts?

--
nosy: +exarkun

___
Python tracker 

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



[issue6421] errors in docs re module initialization vs self arg to functions

2009-07-04 Thread Alex Martelli

New submission from Alex Martelli :

http://docs.python.org/3.1/c-api/structures.html#PyMethodDef

says (under METH_VARARGS):

"""The first one is the self object for methods; for module functions,
it has the value given to Py_InitModule4 (or NULL if Py_InitModule was
used)."""

Py_InitModule4 is no more, and the first argument is now in fact a 
pointer to the module object. This is quite important, since the module 
object is now crucial for the get-state function that's supposed to 
replace a module's statics!

http://docs.python.org/3.1/extending/extending.html#a-simple-example
is ever wronger, since it says, after presenting spam_system's code:

"""The self argument is only used when the C function implements a
built-in method, not a function. In the example, self will always be a
NULL pointer, since we are defining a function, not a method. """

It will never be NULL; it will point to the module.

--
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90134
nosy: aleax, georg.brandl
priority: normal
severity: normal
status: open
title: errors in docs re module initialization vs self arg to functions
type: behavior
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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Benjamin Peterson

Benjamin Peterson  added the comment:

Lists, tuples, and strings are all sequences. Adding two non-ordering
mappings makes much less sense in my head than two sequences.

--
nosy: +benjamin.peterson
status: open -> closed

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Alexandre Vassalotti

Alexandre Vassalotti  added the comment:

Tim Gordon wrote:
> __add__ is non-commutative for lists, tuples, strings etc. - perhaps 
> non-commutative wasn't quite what you were looking for :p.

Yeah, I was not clear in my explanation.

The thing is for lists, tuples, string and other ordered types
concatenation is a well-defined concept. Whereas for dictionaries is not
obvious what concatenation should do with duplicate keys. For example,
what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}? Should
it be {"a": 1, "b": 2} or {"a": 2, "b": 1}?

Also, it would be inconsistent the use of | for the union operation of sets.

--
status: closed -> open

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Alexandre Vassalotti

Changes by Alexandre Vassalotti :


--
status: open -> closed

___
Python tracker 

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



[issue6417] multiprocessing Process examples: print and getppid

2009-07-04 Thread Jesse Noller

Changes by Jesse Noller :


--
priority:  -> normal

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Ezio Melotti

Ezio Melotti  added the comment:

A dict.merge() method could be added so that:

>>> a = dict(x=10, y=20)
>>> b = dict(y=30, z=40)
>>> a.merge(b)
dict(x=10, y=20, z=40)
>>> b.merge(a)
dict(y=30, z=40, x=10)

In case of duplicate keys, the items of the second dict with the same
keys will be discarded (even if dict.update() does the opposite, I think
here it make more sense in this way).

I never needed to do something like this though, so I'm +0 about it.

--
nosy: +ezio.melotti
priority:  -> low
resolution: rejected -> 
status: closed -> open
versions: +Python 2.7, Python 3.2 -Python 2.6

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

IIRC, Guido has previously rejected this suggestion and its variants.

--
nosy: +rhettinger

___
Python tracker 

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



[issue6418] unittest.TestProgram change breaks nose

2009-07-04 Thread Jason Pellerin

Changes by Jason Pellerin :


--
keywords: +patch
Added file: http://bugs.python.org/file14452/6418.patch

___
Python tracker 

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



[issue6151] Make PyDescr_COMMON conform to standard C

2009-07-04 Thread Alexandre Vassalotti

Alexandre Vassalotti  added the comment:

New patch with the superfluous macros stripped out. However, I still
like my original patch better, since it is a bit more consistent.

Anyway, is anyone opposed to this change?

--

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Jean-Paul Calderone

Jean-Paul Calderone  added the comment:

> IIRC, Guido has previously rejected this suggestion and its variants.

Got a link?  It'd be nice to know what the rationale was.

--

___
Python tracker 

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



[issue6410] Dictionaries should support __add__

2009-07-04 Thread Benjamin Peterson

Benjamin Peterson  added the comment:

Regardless of whether this feature will be dict.merge or __add__, it
needs to work its way through python-ideas first.

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



[issue2370] operator.{isCallable,sequenceIncludes} needs a fixer

2009-07-04 Thread Alexandre Vassalotti

Alexandre Vassalotti  added the comment:

Committed the warning patch in r73846 (with a minor correction in
r73847), the 2to3 fixer in r73849.

Thanks!

--
assignee: collinwinter -> 
nosy: +alexandre.vassalotti
resolution:  -> accepted
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



[issue6416] Failed to compile selectmodule.c on windows (trunk)

2009-07-04 Thread Hirokazu Yamamoto

Changes by Hirokazu Yamamoto :


--
priority:  -> high

___
Python tracker 

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



[issue6416] Failed to compile selectmodule.c on windows (trunk)

2009-07-04 Thread Hirokazu Yamamoto

Changes by Hirokazu Yamamoto :


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



[issue6416] Failed to compile selectmodule.c on windows (trunk)

2009-07-04 Thread Hirokazu Yamamoto

Changes by Hirokazu Yamamoto :


--
versions: +Python 3.2 -Python 3.1

___
Python tracker 

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



[issue4509] bugs in array.array with exports (buffer protocol)

2009-07-04 Thread Alexandre Vassalotti

Alexandre Vassalotti  added the comment:

Fixed the array bug in r73850. Is there any bug left to fixed that were
reported in this issue?

--
nosy: +alexandre.vassalotti

___
Python tracker 

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



[issue4005] pydoc in web server mode tails at initial request

2009-07-04 Thread Alexandre Vassalotti

Alexandre Vassalotti  added the comment:

Committed in r73856.

--
nosy: +alexandre.vassalotti
resolution:  -> accepted
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



[issue6414] struct module : processor endianness descriptions misleading

2009-07-04 Thread Karl Magdsick

New submission from Karl Magdsick :

In http://docs.python.org/dev/library/struct.html,

it says
"Native byte order is big-endian or little-endian, depending on the host 
system. For example, Motorola and Sun processors are big-endian; Intel 
and DEC processors are little-endian."

This is a gross over-generalization at best.  Off the top of my head, 
current Linux kernels run the Intel Itanium in big-endian mode. (Though, 
I don't recall if there's a non-privileged instruction to flip 
endianness, system headers and system calls are defined in big-endian 
order, which is what's most relevant to the struct module.)  Sun SPARC 
v9 is bi-endian. Intel Itanium and XScale processors are bi-endian.  Dec 
Alphas are bi-endian.  (Though, I'm only aware of Cray using Alphas in 
big-endian mode.)

The quoted paragraph should name specific processors which are single-
endian (Intel Core 2, Sun SPARC v8) and/or provide a Wikipedia 
reference, rather than making incorrect statements.

Intel Itanium machines running Linux are probably the most common 
systems where this statement's inaccuracy is likely to cause confusion 
among developers.

--
assignee: georg.brandl
components: Documentation
messages: 90107
nosy: georg.brandl, kmag
severity: normal
status: open
title: struct module : processor endianness descriptions misleading
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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



[issue5463] Remove deprecated features from struct module

2009-07-04 Thread Mark Dickinson

Mark Dickinson  added the comment:

The trunk warning was squashed in r73004.

--
status: open -> closed

___
Python tracker 

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



[issue1741130] struct.pack("I", "foo"); struct.pack("L", "foo") should fail

2009-07-04 Thread Mark Dickinson

Mark Dickinson  added the comment:

Thanks for the patch, Daniel!  It certainly fixes the problem.  I was 
planning something a little more drastic, though---I think the struct 
module could do with a bit of a cleanup in this area.

At the moment it's not clear exactly what types should be accepted by
struct.pack with an integer format.  Just ints and longs (and their 
subclases)?  Anything implementing an __index__ method?  Anything 
implementing an __int__ method (e.g., Decimal instances)?

I propose doing a little bit of rewriting so that

  (1) all attempted conversions of a PyObject to a C integer
  go through PyNumber_Index; thus anything with an __index__
  method can be packed.

  (2) If PY_STRUCT_FLOAT_COERCE is defined, instances of float or
  subclasses of float (i.e., everything that passes PyFloat_Check)
  are also accepted, for backwards compatibility.

Does this seem reasonable?

--

___
Python tracker 

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



[issue3392] subprocess fails in select when descriptors are large

2009-07-04 Thread Frank Chu

Frank Chu  added the comment:

Thanks!  Good to hear it's checked in finally :-).

Frank

On Fri, Jul 3, 2009 at 7:47 PM, Gregory P. Smith wrote:

>
> Gregory P. Smith  added the comment:
>
> Merged to py3k in r73833.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file14446/unnamed

___
Python tracker 

___Thanks!  Good to hear it's checked in finally 
:-).FrankOn Fri, Jul 3, 2009 at 7:47 
PM, Gregory P. Smith rep...@bugs.python.org> 
wrote:


Gregory P. Smith g...@krypto.org> 
added the comment:

Merged to py3k in r73833.

--

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue3392>
___

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



[issue6415] warnings.warn segfaults on bad formatted string

2009-07-04 Thread wiesenth

New submission from wiesenth :

The interpreter crashes with an segmentation fault when warnings.warn
shall output a Warning instance, whose string representation is bad
formatted.

Don't know if this is fixed in a minor 2.6 release or in 2.7, I use the
Ubuntu 9.04 python2.6 package.

An easy reproducing example is given.

This is also an issue within python3.0 (python3.1 does not exist in the
repositories)

--
files: warnsegfault.py
messages: 90111
nosy: wiesenth
severity: normal
status: open
title: warnings.warn segfaults on bad formatted string
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14447/warnsegfault.py

___
Python tracker 

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



[issue3410] platform.version() don't work as expected in Vista in portuguese

2009-07-04 Thread Ezio Melotti

Ezio Melotti  added the comment:

I tried platform.version() on a non-English Vista and XP and I got
'32bit' for Vista and '5.1.2600' for XP. With platform.platform() I got
'Windows-32bit-SP2' on Vista and 'Windows-XP-5.1.2600-SP2' on XP.

--
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 2.7 -Python 2.5

___
Python tracker 

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



[issue6416] Failed to compile selectmodule.c on windows (trunk)

2009-07-04 Thread Hirokazu Yamamoto

New submission from Hirokazu Yamamoto :

I cannot compile selectmodule.c on windows(trunk). PIPE_BUF will not be
defined if macro _POSIX_ is not defined. But if define _POSIX_ before
"#include " in Include/Python.h another compile error happens.

E:\python-dev\trunk\PC\msvcrtmodule.c(39) : warning C4013: 関数
'_heapmin' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(2901) : warning C4013: 関数
'_exit' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(2974) : warning C4013: 関数
'execv' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(3107) : warning C4013: 関数
'execve' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(3194) : error C2065:
'_OLD_P_OVERLAY' : 定義されていない識別子です。
E:\python-dev\trunk\Modules\posixmodule.c(3195) : error C2065:
'_P_OVERLAY' : 定義されていない識別子です。
E:\python-dev\trunk\Modules\posixmodule.c(3198) : warning C4013: 関数
'_spawnv' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(3343) : warning C4013: 関数
'_spawnve' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(3790) : warning C4013: 関数
'getpid' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(4918) : warning C4013: 関数
'alloca' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(5868) : warning C4013: 関数
'_cwait' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(6743) : warning C4013: 関数
'putenv' は定義されていません。int 型の値を返す外部関数と見なします。
E:\python-dev\trunk\Modules\posixmodule.c(8941) : error C2065: '_P_WAIT'
: 定義されていない識別子です。
E:\python-dev\trunk\Modules\posixmodule.c(8942) : error C2065:
'_P_NOWAIT' : 定義されていない識別子です。
E:\python-dev\trunk\Modules\posixmodule.c(8944) : error C2065:
'_P_NOWAITO' : 定義されていない識別子です。
E:\python-dev\trunk\Modules\posixmodule.c(8945) : error C2065:
'_P_DETACH' : 定義されていない識別子です。
(snip)

Probaly it's not good define _POSIX_ on windows. Is it reasonable to put
"#ifdef PIPE_BUF" around

PyModule_AddIntConstant(m, "PIPE_BUF", PIPE_BUF);

in selectmodule.c.

--
components: Build, Windows
messages: 90113
nosy: ocean-city
severity: normal
status: open
title: Failed to compile selectmodule.c on windows (trunk)
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



[issue6416] Failed to compile selectmodule.c on windows (trunk)

2009-07-04 Thread Hirokazu Yamamoto

Hirokazu Yamamoto  added the comment:

>E:\python-dev\trunk\PC\msvcrtmodule.c(39) : warning C4013:
>関数'_heapmin' は定義されていません。int 型の値を返す外部関数と見なします。

This means "_heapmin is not defined".

--

___
Python tracker 

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



[issue3410] platform.version() don't work as expected in Vista in portuguese

2009-07-04 Thread Marc-Andre Lemburg

Marc-Andre Lemburg  added the comment:

Ezio Melotti wrote:
> Ezio Melotti  added the comment:
> 
> I tried platform.version() on a non-English Vista and XP and I got
> '32bit' for Vista and '5.1.2600' for XP. With platform.platform() I got
> 'Windows-32bit-SP2' on Vista and 'Windows-XP-5.1.2600-SP2' on XP.

Could you please run the platform function win32_ver() through
a debugger and check why it doesn't return "Vista". That function
does have support for Vista.

--
title: platform.version() don't work as expected in Vista in portuguese -> 
platform.version() don't work as expected in Vista inportuguese

___
Python tracker 

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



[issue6415] warnings.warn segfaults on bad formatted string

2009-07-04 Thread Hirokazu Yamamoto

Hirokazu Yamamoto  added the comment:

I hope attached patch will fix this issue.

--
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file14448/warnings_segfault.patch

___
Python tracker 

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



[issue3410] platform.version() don't work as expected in Vista in portuguese

2009-07-04 Thread Ezio Melotti

Ezio Melotti  added the comment:

The Vista machine is running Py 2.5.2 but is not mine so I can't
test/debug the issue properly there. FWIW I tried win32_ver() on it and
I got ('', '6.0.6002', 'SP2', 'Multiprocessor Free').

Here on WinXP with 2.6 I get ('XP', '5.1.2600', 'SP2', u'Uniprocessor
Free') (why only the last is unicode?).

On Monday I'll have access to more Windows machines (including Vista)
but they are all in English. If there's something that I should try
there let me know.

--

___
Python tracker 

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



[issue6415] warnings.warn segfaults on bad formatted string

2009-07-04 Thread Benjamin Peterson

Changes by Benjamin Peterson :


--
assignee:  -> brett.cannon
nosy: +brett.cannon

___
Python tracker 

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



[issue6417] multiprocessing Process examples: print and getppid

2009-07-04 Thread Michael Newman

New submission from Michael Newman :

The "16.6.1.1. The Process class" section of the multiprocessing
documentation:
http://docs.python.org/dev/py3k/library/multiprocessing.html
has errors in both examples.

The first example needs the indentation fixed on the "from" and "if"
lines (remove the leading spaces).

The second example has two issues: print syntax needs be updated from
2.0 to 3.0 syntax. Also, getppid is not available on win32 platforms.
Below is a corrected example, which I tested successfully on on win32
and linux:

# Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
C:\>c:\Python31\python.exe Process_with_more_info.py
main line
module name: __main__
parent process: None
process id: 3216
function f
module name: __main__
parent process: 3216
process id: 3692
hello bob

# Python 3.0.1 (r301:69556, Jun  6 2009, 21:34:43) [GCC 4.3.2] on linux2
m...@www:~/files$ python3.0 Process_with_more_info.py
main line
module name: __main__
parent process: 19853
process id: 22544
function f
module name: __main__
parent process: 22544
process id: 22545
hello bob

# Start of corrected example:

from multiprocessing import Process, current_process
from sys import platform
import os

def info(title):
print(title)
print('module name:', __name__)
if platform == 'win32':
  print('parent process:', current_process()._parent_pid)
else:
  print('parent process:', os.getppid())
print('process id:', os.getpid())

def f(name):
info('function f')
print('hello', name)

if __name__ == '__main__':
info('main line')
p = Process(target=f, args=('bob',))
p.start()
p.join()

# End of corrected example.

I also saw this online:
"os.getppid on Windows"
http://d.hatena.ne.jp/chrono-meter/20090325/p1
But the license of the code is not clear, and it would make the example
too confusing to insert in.

Another reference:
"Multiprocessing docs are not 3.0-ready"
http://bugs.python.org/issue3256
Looks like some print statements fixed back then, but not sure why the
examples mentioned here were not fixed.

--
assignee: georg.brandl
components: Documentation
messages: 90118
nosy: georg.brandl, mnewman
severity: normal
status: open
title: multiprocessing Process examples: print and getppid
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



[issue6381] test_urllib2_localnet sporadic failures closing socket

2009-07-04 Thread Kristján Valur Jónsson

Kristján Valur Jónsson  added the comment:

meged to py3k in revision 73845

--

___
Python tracker 

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



[issue6417] multiprocessing Process examples: print and getppid

2009-07-04 Thread Benjamin Peterson

Changes by Benjamin Peterson :


--
assignee: georg.brandl -> jnoller
nosy: +jnoller

___
Python tracker 

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



[issue6382] test_socketserver fails on trunk in test_ForkingTCPServer

2009-07-04 Thread Kristján Valur Jónsson

Kristján Valur Jónsson  added the comment:

This is a "fork" problem.
socket.close must be done on the parent, while socket.shutdown and 
socket.close must be performed on the child.
I must restructure this a little bit to make it work.

--
nosy: +krisvale

___
Python tracker 

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



[issue6417] multiprocessing Process examples: print and getppid

2009-07-04 Thread Michael Newman

Michael Newman  added the comment:

# Revised example that is more platform neutral (avoids sys.platform):

from multiprocessing import Process, current_process
import os

def info(title):
print(title)
print('module name:', __name__)
if not hasattr(os, 'getppid'):  # win32
  print('parent process:', current_process()._parent_pid)
else:
  print('parent process:', os.getppid())
print('process id:', os.getpid())

def f(name):
info('function f')
print('hello', name)

if __name__ == '__main__':
info('main line')
p = Process(target=f, args=('bob',))
p.start()
p.join()

--

___
Python tracker 

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



[issue3810] os.chdir() et al: is the path str or bytes?

2009-07-04 Thread R. David Murray

Changes by R. David Murray :


--
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

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



[issue6415] warnings.warn segfaults on bad formatted string

2009-07-04 Thread Jerry Chen

Jerry Chen  added the comment:

Bug and patch confirmed on both py3k and python2.7 branches

Before:

$ ./python.exe warnsegfault.py 
this exception is caught: incomplete format
this exception is also caught: incomplete format
Bus error

After:

$ ./python.exe warnsegfault.py this exception is caught: incomplete format
this exception is also caught: incomplete format
Traceback (most recent call last):
  File "warnsegfault.py", line 21, in 
warnings.warn(MyWarning())
  File "warnsegfault.py", line 10, in __str__
return "A bad formatted string %(err)" % {"err" : "there is no %(err)s"}
ValueError: incomplete format

--
nosy: +jcsalterego

___
Python tracker 

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



[issue6418] unittest.TestProgram change breaks nose

2009-07-04 Thread Jason Pellerin

New submission from Jason Pellerin :

This changeset:

http://hg.python.org/cpython/rev/c3fb79d1c036

breaks nose, as it changes the behavior of unittest.TestProgram in a
non-backwards-compatible way. Previously, when called like:

TestProgram(testRunner=None)

self.testRunner would be None when runTests() was called. Now, it is 
populated with the default TextTestRunner class in TestProgram.__init__. 
nose expects self.testRunner to be None or a runner instance in 
runTests(), and thus fails immediately with 2.6.3.

If initialization of self.testRunner could be deferred to runTests() as 
in unitttest for 2.5 and earlier, that would be ideal for nose.

--
components: Library (Lib)
messages: 90123
nosy: jpellerin
severity: normal
status: open
title: unittest.TestProgram change breaks nose
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



[issue6418] unittest.TestProgram change breaks nose

2009-07-04 Thread Michael Foord

Michael Foord  added the comment:

This change was made to fix a regression in 2.6.
In 2.5 the default was None and someone (else) made the also backwards
incompatible change to make the default the TextTestRunner class. This
broke test suites (like setuptools for example) which expected to be
able to pass None in and get sensible default behaviour.

The change can't be reverted as it was a bugfix, but a different change
could be applied.

--
nosy: +michael.foord

___
Python tracker 

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