[issue2568] Seconds range in time unit

[Anton Fedorov]

New submission from Anton Fedorov <[EMAIL PROTECTED]>:

"%S Second as a decimal number [00,61]. (2)
(2) The range really is 0 to 61; this accounts for leap seconds and the 
(very rare) double leap seconds."

That is wrong. There NEVER can be two leap seconds in one moment, since UTC 
time keep the difference between UTC and UT1 from exceeding ±0.9 s.

Leap seconds occur only at the end of a UTC month, and have only ever been 
inserted at the end of June 30 or December 31.

So, 61 is wrong, real seconds range from 0 to 60 inclusive.

--
components: Library (Lib)
messages: 65067
nosy: datacompboy
severity: normal
status: open
title: Seconds range in time unit
type: behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

This is now fixed in r62203.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2567] Section "New-style and classic classes" needs to be removed/rewritten

[Martin v. Löwis]

New submission from Martin v. Löwis <[EMAIL PROTECTED]>:

There are no classic classes anymore in Python.

--
assignee: georg.brandl
components: Documentation
messages: 65065
nosy: georg.brandl, loewis
severity: normal
status: open
title: Section "New-style and classic classes" needs to be removed/rewritten
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

Finish the change from 'type' to 'class'
(See carefully written title ;-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2566] Py3.0a4 wsgiref simple_server failed to start

[delimy]

New submission from delimy <[EMAIL PROTECTED]>:

Here's the most recent traceback:

  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
116, in finish_response
self.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
199, in write
self.send_headers()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
255, in send_headers
self.send_preamble()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
178, in send_preamble
self._write('HTTP/%s %s\r\n' % (self.http_version,self.status))
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
385, in _write
self.stdout.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/socket.py", line 222, in write
return self._sock.send(b)
TypeError: send() argument 1 must be bytes or read-only buffer, not str

It should convert str to bytes before write to stdout.

--
components: Library (Lib)
messages: 65063
nosy: delimy
severity: normal
status: open
title: Py3.0a4 wsgiref simple_server failed to start
type: crash
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

So which one should it be: type or class?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue2128] sys.argv is wrong for unicode strings

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

What warnings precisely are you seeing? I didn't see anything in the 3k
branch (not even for #2388, as PyErr_Format doesn't have the GCC format
attribute in 3k, unlike 2.x).

__
Tracker <[EMAIL PROTECTED]>

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

[issue2388] Compiler warnings when using UCS4

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

This is now fixed in r62199

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2513] 64bit cross compilation on windows

[Mark Hammond]

Mark Hammond <[EMAIL PROTECTED]> added the comment:

Checked in r62197, including the patch from Thomas.  Note I expanded the
patch to the distutils doc (noting you need to build Python itself for
the target platform before it works) and added a short entry to Misc/NEWS

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2565] Change 'type' to 'class' in repr/str(builtin-class)

[Terry J. Reedy]

New submission from Terry J. Reedy <[EMAIL PROTECTED]>:

>From py3 devel list today:

>  r23331 | gvanrossum | 2001-09-25 05:56:29 +0200 (Di, 25 Sep 2001) | 5
lines
>
>  Change repr() of a new-style class to say  rather
>  than .  Exception: if it's a built-in type or an
>  extension type, continue to call it .

Well, if we're going to break user code, 3.0 is the time to do it. :-)

--
components: Extension Modules, Interpreter Core
keywords: easy
messages: 65058
nosy: tjreedy
severity: normal
status: open
title: Change 'type' to 'class' in repr/str(builtin-class)
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue595601] file (& socket) I/O are not thread safe

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

Fix committed to trunk in revision 62195 via Issue 815646


Tracker <[EMAIL PROTECTED]>


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

[issue815646] thread unsafe file objects cause crash

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

Committed to trunk in revision 62195.

Misc/NEWS entry added.

I also added two new C API functions: PyFile_IncUseCount and
PyFile_DecUseCount along with documentation.  They should be used by any
C extension code that uses PyFile_AsFile and wants to make use of the
returned FILE* with the GIL released.

The net effect of not using them is no change from the existing behavior
(crashes would be possible) for those C extension modules.

--
resolution:  -> accepted
status: open -> closed
versions:  -Python 3.0


Tracker <[EMAIL PROTECTED]>


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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Neal Norwitz]

Neal Norwitz <[EMAIL PROTECTED]> added the comment:

Trent, go ahead and try this out.  We should definitely be moving in
this direction.  So I'd rather fix the problem than keep suffering with
the current problems of not being able to run the test suite
concurrently.  I think bind_port might be documented, so you should
update the docs if so.  Also, please add a Misc/NEWS entry.

--
nosy: +nnorwitz
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

I've attached another patch that fixes test_support.bind_port() as well 
as a bunch of files that used that method.  The new implementation 
always uses an ephemeral port in order to elicit an unused port for 
subsequent binding.  Tested on Windows 32-bit & x64 and FreeBSD 6.2.  
Would like to apply sooner rather than later unless anyone has any 
objections as it'll fix my two Windows buildbots that are on the same 
machine from both hanging if they test asynchat at the same time (which 
happens more often than you'd think).

Added file: http://bugs.python.org/file9966/trunk.2550.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2548] Undetected error in exception handling

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

I've identified rev58032 [1] as the one introducing this issue. It's
Brett's code, fixing a nasty crasher and adding a pre-built exception
(PyExc_RecursionErrorInst).


[1] http://svn.python.org/view?rev=58032&view=rev

P.S.: Thanks Thomas for correctly identifying an issue I mis-reported :)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

[Updating issue with mailing list discussion; my reply to Jean-Paul]
> >"With TCP, we are never able to start multiple servers that bind
> > the same IP address and same port: a completely duplicate binding.
> > That is, we cannot start one server that binds 198.69.10.2 port 80
> > and start another that also binds 198.69.10.2 port 80, even if we
> > set the SO_REUSEADDR socket option for the second server."

> Notice that the quoted text explains that you cannot start multiple
> servers that etc.  Since you didn't call listen on either socket, it's
> arguable that you didn't start any servers, so there should be no
> surprise regarding the behavior.  Try adding listen calls at various
> places in the example and you'll see something different happen.

I agree in principle, Stevens says nothing about what happens if you 
*do* try and bind two sockets on two identical host/port addresses.  
Even so, test_support.bind_port() makes an assumption that bind() will 
raise EADDRINUSE if the port is not available, which, as has been 
demonstrated, won't be the case on Windows or Linux.

> FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote
> on Linux/BSD/UNIX/etc.  On Windows, however, that option actually 
means
> something quite different.  It means that the address should be stolen
> from any process which happens to be using it at the moment.

Probably explains why the python process wedges when this happens on 
Windows...

> There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
> which, AIUI, makes it impossible for another process to steal the port
> using SO_REUSEADDR.

Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, 
Windows raises EADDRINUSE on the second bind().  I don't have access to 
any Linux boxes at the moment, so I can't test what sort of error is 
raised with the example I posted if listen() and accept() are called on 
the two sockets bound to identical addresses.  Can anyone else shed 
some light on this?  I'd be interested in knowing if the process wedges 
on Linux as badly as it does on Windows (to the point where it's not 
respecting ctrl-c or sigkill).


Trent.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

[Updating issue with mailing list discussion; Jean-Paul's reply]
On Fri, 4 Apr 2008 13:24:49 -0700, Trent Nelson <[EMAIL PROTECTED]> 
wrote:
>Interesting results!  I committed the patch to test_socket.py in 
r62152.  I was expecting all other platforms except for Windows to 
behave consistently (i.e. pass).  That is, given the following:
>
>import socket
>host = '127.0.0.1'
>sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock.bind((host, 0))
>port = sock.getsockname()[1]
>sock.close()
>del sock
>
>sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>sock1.bind((host, port))
>sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>sock2.bind((host, port))
>
>
>the second bind should fail with EADDRINUSE, at least according to 
the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 
7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed):
>
>"With TCP, we are never able to start multiple servers that bind
> the same IP address and same port: a completely duplicate binding.
> That is, we cannot start one server that binds 198.69.10.2 port 80
> and start another that also binds 198.69.10.2 port 80, even if we
> set the SO_REUSEADDR socket option for the second server."
>
>The results: both Windows *and* Linux fail the patched test; none of 
the buildbots for either platform encountered an EADDRINUSE 
socket.error after the second bind().  FreeBSD, OS X, Solaris and Tru64 
pass the test -- EADDRINUSE is raised on the second bind.  (Interesting 
that all the ones that passed have a BSD lineage.)

Notice that the quoted text explains that you cannot start multiple 
servers
that etc.  Since you didn't call listen on either socket, it's arguable 
that
you didn't start any servers, so there should be no surprise regarding 
the
behavior.  Try adding listen calls at various places in the example and
you'll see something different happen.

FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote on
Linux/BSD/UNIX/etc.  On Windows, however, that option actually means
something quite different.  It means that the address should be stolen 
from
any process which happens to be using it at the moment.

There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
which, AIUI, makes it impossible for another process to steal the port
using SO_REUSEADDR.

Hope this helps,

Jean-Paul

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

[Updating the issue with relevant mailing list conversation]
Interesting results!  I committed the patch to test_socket.py in 
r62152.  I was expecting all other platforms except for Windows to 
behave consistently (i.e. pass).  That is, given the following:

import socket
host = '127.0.0.1'
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind((host, 0))
port = sock.getsockname()[1]
sock.close()
del sock

sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock1.bind((host, port))
sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock2.bind((host, port))


the second bind should fail with EADDRINUSE, at least according to 
the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 
7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed):

"With TCP, we are never able to start multiple servers that bind
 the same IP address and same port: a completely duplicate binding.
 That is, we cannot start one server that binds 198.69.10.2 port 80
 and start another that also binds 198.69.10.2 port 80, even if we
 set the SO_REUSEADDR socket option for the second server."

The results: both Windows *and* Linux fail the patched test; none of 
the buildbots for either platform encountered an EADDRINUSE 
socket.error after the second bind().  FreeBSD, OS X, Solaris and Tru64 
pass the test -- EADDRINUSE is raised on the second bind.  (Interesting 
that all the ones that passed have a BSD lineage.)

I've just reverted the test in r62156 as planned.  The real issue now 
is that there are tests that are calling test_support.bind_socket() 
with the assumption that the port returned by this method is 'unbound', 
when in fact, the current implementation can't guarantee this:

def bind_port(sock, host='', preferred_port=54321):
for port in [preferred_port, 9907, 10243, 32999, 0]:
try:
sock.bind((host, port))
if port == 0:
port = sock.getsockname()[1]
return port
except socket.error, (err, msg):
if err != errno.EADDRINUSE:
raise
print >>sys.__stderr__, \
'  WARNING: failed to listen on port %d, trying 
another' % port

This logic is only correct for platforms other than Windows and Linux.  
I haven't looked into all the networking test cases that rely on 
bind_port(), but I would think an implementation such as this would be 
much more reliable than what we've got for returning an unused port:

def bind_port(sock, host='127.0.0.1', *args):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, 0))
port = s.getsockname()[1]
s.close()
del s

sock.bind((host, port))
return port

Actually, FWIW, I just ran a full regrtest.py against trunk on Win32 
with this change in place and all the tests still pass.

Thoughts?

Trent.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2515] Segfault while operating on closed sqlite3 cursor.

[Paul Davis]

Paul Davis <[EMAIL PROTECTED]> added the comment:

No prob.

On Sun, Apr 6, 2008 at 7:06 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote:
>
>  Gerhard Häring <[EMAIL PROTECTED]> added the comment:
>
>  Thanks for reporting this. It's fixed in r62183 in the 2.5 maintenance
>  branch.
>
>  --
>  resolution:  -> fixed
>  status: open -> closed
>
>
>
>  __
>  Tracker <[EMAIL PROTECTED]>
>  
>  __
>

__
Tracker <[EMAIL PROTECTED]>

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

[issue1297] pyconfig.h not compatible with MS VC++ Express Edition

[Johannes Hoff]

Johannes Hoff <[EMAIL PROTECTED]> added the comment:

This is still the case with Visual Studio Express 2008. It can be fixed 
by downloading the Windows SDK, though it would be nicer if this was 
not necessary.
Download link: http://blogs.msdn.com/windowssdk/archive/2008/02/07/
windows-sdk-rtms.aspx
I recommend the "web install", since only the headers and libraries are 
needed, not the whole 1GB blob that comes with it.

Amaury: The file python.hpp, thus basetsd.h, is used by boost-python.

--
nosy: +johanneshoff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

As a follow-up: for compatibility, it might be possible to support
either Unicode or arbitrary plain strings in write_pkg_file. In 3k, such
support can then be dropped.

As that constitutes a new feature, it shouldn't be applied to 2.5.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I agree there is a bug in distutils. Before we proceed, I think
distutils-sig needs to be consulted. My proposal would be the one I
suggested earlier: all strings should either be Unicode or ASCII-only
byte strings. This contradicts to the documentation that says that none
of the strings must be Unicode, so it would be an incompatible change
(and would indeed likely break packages that currently use UTF-8, and
sdist, but never register)

--
resolution: wont fix -> 
status: closed -> open
versions: +Python 2.6 -3rd party

__
Tracker <[EMAIL PROTECTED]>

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

[issue2128] sys.argv is wrong for unicode strings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

MvL's recent commit creates compiler warnings for Unicode UCS4 for the
same reason as #2388.

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2530] Document IO module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Ok. attaching an improved patch. Do you think information about
indenting classes and such can be added to the style guide? It'd be very
helpful.

Added file: http://bugs.python.org/file9965/io_doc2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2564] Python hangs on FreeBSD7 in test_capi

[Taavi Repän]

New submission from Taavi Repän <[EMAIL PROTECTED]>:

When doing import.test_autotest, test_capi hangs.
It seems that threads 1,2,3 are trying to acquire import lock, which is
owned by thread 4, which is trying to lock some other lock.

Python 2.5.2 (r252:60911, Apr  6 2008, 17:28:23) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

Added file: http://bugs.python.org/file9964/backtrace

__
Tracker <[EMAIL PROTECTED]>

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

[issue2530] Document IO module

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Looks good already! I can't review the full text now, but can you move
member documentation into the indented block for the class? (I know
other documents don't do this, but this is a legacy and I'd like new
documents to adopt this style.)

Additionally, the function description style is inconsistent ("Flushes
the stream" vs "Return this").

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue2564] Python hangs on FreeBSD7 in test_capi

[Taavi Repän]

Changes by Taavi Repän <[EMAIL PROTECTED]>:


--
components: None
nosy: trepan
severity: normal
status: open
title: Python hangs on FreeBSD7 in test_capi
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Instead of  ... raise an error, it should read  ... report the _ctypes 
module as missing, do not run any tests, etc.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

oh, hold one, it is more complicated in fact :)

setuptools calls DistributionMetadata.dist.write_pkg_file()
method to write the .egg-info file.

This method make the assertion that the metadata fields are string
so it is not setuptools fault.

This code fail the same way:

dist = Distribution(attrs={'author': u'Mister Café'})
dist.metadata.write_pkg_file(file)

 
So I guess the patch needs to be done in
distutils.dist.DistributionMetadata, so it checks upon
the type of field before it runs:

file.write('Author: %s\n' % self.get_contact() ) 

That what I meant when I said that distutils should
decide wheter it works with unicode or str for this fields.

I can re-write a new patch if you agree on this

__
Tracker <[EMAIL PROTECTED]>

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

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> If option --with-system-ffi is not specified and if the compiler is not 
> gcc, raise an error.

Up to here, it all sounded fine. What do you mean by error? Abort?
That should not happen. Instead, setup.py skips modules if it doesn't
find the proper prerequisites - which here is the pre-existing FFI
implementation.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

ok I see what you mean, thanks for the explanation

__
Tracker <[EMAIL PROTECTED]>

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

[issue2530] Document IO module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Attaching a draft.

--
keywords: +patch
Added file: http://bugs.python.org/file9963/io_doc.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Agreed.  In addition, gcc -v writes to stderr and catching the output 
requires redirecting stderr or using os.popen3 or -4.  The latter fail 
since the select module (needed by subprocess) is still missing at that 
time.

Going back to Thomas' comments and before getting into implementation 
details, the best way to address the issue might be the following.

If the compiler is not gcc then config option --with-system-ffi *must* 
be specified (and a libffi library must exist).

If option --with-system-ffi is not specified and if the compiler is not 
gcc, raise an error.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I don't understand. It is *certainly* allowed to use byte strings for
these data, as long as they are ASCII. The Unicode requirement exists
only for non-ASCII characters, and distutils makes explicit, deliberate
use of the default encoding here (hoping that nobody changed it away
from ASCII).

There are tons of setup.py files out there that use plain byte strings,
and there is no reason to break them, e.g. by mandating that the string
is Unicode already.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2563] embed manifest in windows extensions

[Mark Hammond]

New submission from Mark Hammond <[EMAIL PROTECTED]>:

The move to vs2008 has caused .manifest files to be created next to
distutils created extensions modules, rather than being embedded as
recommended by Microsoft.

See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx

The attached patch achieves this by telling the compiler to generate the
manifest in the temp dir, them embeds that manifest using mt.exe

Adding Christian for comment (hopefully the correct Christian this time
  - sorry about that :)

--
assignee: mhammond
components: Distutils
files: embed_manifest.patch
keywords: patch, patch
messages: 65034
nosy: mhammond, tiran
severity: normal
status: open
title: embed manifest in windows extensions
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9962/embed_manifest.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

In that case, distutils should not do a unicode() call over each field
passed before .encode('utf8') is called, because it makes the assumption
that string type can be used.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

The official supported way for non-ASCII characters in distutils is to
use Unicode strings. If anything else fails, that's not a bug.

IIUC, in this case, it's setuptools that fails, not distutils. Assuming
I understood correctly, I'm closing this as won't-fix/3rd party.

--
nosy: +loewis
resolution:  -> wont fix
status: open -> closed
versions: +3rd party -Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue980098] Module to dynamically generate structseq objects

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
versions: +Python 2.6


Tracker <[EMAIL PROTECTED]>


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

[issue815646] thread unsafe file objects cause crash

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Ok Greg, I wasn't sure locking/unlocking the GIL would create a memory
barrier but it sounds logical after all. Your patch looks fine to me.


Tracker <[EMAIL PROTECTED]>


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

[issue2515] Segfault while operating on closed sqlite3 cursor.

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Thanks for reporting this. It's fixed in r62183 in the 2.5 maintenance
branch.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue815646] thread unsafe file objects cause crash

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

Patched and tested on one of my buildbots, test_file passes without 
error with your latest Patch Greg.

--
nosy: +Trent.Nelson


Tracker <[EMAIL PROTECTED]>


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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file9961/unicode.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9960/unicode.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

New submission from Tarek Ziadé <[EMAIL PROTECTED]>:

If I try to put my name in the Author field as a string field, 
it will brake because distutils makes the assumption that 
the fields are string encoded in ascii, before it decodes
it into unicode, then encode it in utf8 to send the data.

See in distutils.command.register.post_to_server :

value = unicode(value).encode("utf-8")


One way to avoid this error is to provide unicode for all field,
but will fail farther if setuptools is used, because
this other package makes the assumption that the fields *are* strings::

self.run_command('egg_info')
...
distutils/dist.py", line 1047, in write_pkg_info
pkg_info.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 18: ordinal not in range(128)

So I guess distutils shouldn't guess that it receives ascii strings
and do a raw unicode() call, and should make the assumption that 
it receives unicode fields only.


Since many packages out there use strings, I have left a unicode()
call in my patch, together with a warning. 

test provided.

--
components: Distutils
files: unicode.patch
keywords: patch
messages: 65028
nosy: tarek
severity: normal
status: open
title: Cannot use non-ascii letters in disutils if setuptools is used.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9960/unicode.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue980098] Module to dynamically generate structseq objects

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

I believe this is obsolete now we have namedtuple?

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


Tracker <[EMAIL PROTECTED]>


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

[issue2558] Document pickle protocol 3

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Committed the patch in r62181.

--
assignee: gvanrossum -> georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2561] Instance remembers old values from former life

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Yes, this is expected. Default values are only evaluated once, at
function creation time. If you need to have a mutable default argument
that is assigned to something and changed, use something like this:

def f(arg=None):
if arg is None:
arg = []
...

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2561] Instance remembers old values from former life

[Werner Arnhold]

New submission from Werner Arnhold <[EMAIL PROTECTED]>:

I don't know if it is a bug or a feature but the result seems to be
wrong for me: A constructor argument remembers its values from the last call

--
files: class_with_listparamdefault.py
messages: 65024
nosy: warnhold
severity: normal
status: open
title: Instance remembers old values from former life
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9959/class_with_listparamdefault.py

__
Tracker <[EMAIL PROTECTED]>

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