[issue12127] Inconsistent leading zero treatment

[Mark Dickinson]

Changes by Mark Dickinson :


--
type: compile error -> feature request
versions: +Python 3.3 -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

[issue12127] Inconsistent leading zero treatment

[Mark Dickinson]

Mark Dickinson  added the comment:

I think this is something that should be brought up for wider discussion on the 
python-dev mailing list.  It may be that people are ready to allow those 
leading zeros for Python 3.3 or 3.4.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue12105] open() does not able to set flags, such as O_CLOEXEC

[STINNER Victor]

STINNER Victor  added the comment:

> Why not to implement 'e' letter in py3k ?
> 
> In systems where O_CLOEXEC is not supported in open(), flag should be set 
> non-atomically using fcntl.

Having an atomic or non-atomic behaviour depending on the OS is not a
good idea.

--

___
Python tracker 

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

[issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import

[Nick Coghlan]

Nick Coghlan  added the comment:

Several of these could be handled just by having test.support.make_legacy_pyc() 
fall back to compiling from source if sys.dont_write_bytecode is set.

The others may need to be skipped in that situation.

--

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[Eric V. Smith]

Changes by Eric V. 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

[issue12105] open() does not able to set flags, such as O_CLOEXEC

[Charles-François Natali]

Charles-François Natali  added the comment:

> To exclude races (in concurrent threads), this two ops should be done under 
> lock (GIL?)

That won't work, because open(), like other slow syscalls, is called without 
the GIL held. Furthermore, it wouldn't be atomic anyway (imagine a fork is done 
from a C extension without the GIL held).
So we would end up tricking people into using a 'e' flag that, contrarily to 
GNU fopen(), would not be atomic.
Since the fopen() 'e' flag is only available on platform supporting O_CLOEXEC, 
you're exactly as portable using the fdopen() trick. And you're sure of what's 
happening.

--

___
Python tracker 

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

[issue12105] open() does not able to set flags, such as O_CLOEXEC

[Petri Lehtinen]

Changes by Petri Lehtinen :


--
nosy: +petri.lehtinen

___
Python tracker 

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

[issue1006238] cross compile patch

[Senthil Kumaran]

Senthil Kumaran  added the comment:

hello wrobell , I see that issue3754 has patches for more recent line of code 
and issue 1597850 is related too.  Would you like to test the patches in there? 
If successful, this feature can be pushed further (and considered) for 
inclusion.

--
nosy: +orsenthil

___
Python tracker 

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

[issue1006238] cross compile patch

[wrobell]

wrobell  added the comment:

Senthil,

I would be more than happy to do that but for Python 3.2 (or there is no chance 
to backport it?). Python 3.3 is too far in time at the moment.

--

___
Python tracker 

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

[issue1597850] Cross compiling patches for MINGW

[wrobell]

Changes by wrobell :


--
nosy: +wrobell

___
Python tracker 

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

[issue3754] cross-compilation support for python build

[wrobell]

Changes by wrobell :


--
nosy: +wrobell

___
Python tracker 

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

[issue1006238] cross compile patch

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Code compatibility wise there is not much difference between Python3.2
and Python3.3. So you can do it for Python3.2 (in a bitbucket cpython
branch) and it is found stable, there are good chances that it will be
can be made in Python3.3 and future. I don't think, this would be
backported.

--

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Torsten Landschoff]

Torsten Landschoff  added the comment:

I updated the patch for upstream pysqlite2. Available at

http://code.google.com/p/pysqlite/issues/detail?id=24

Patch over there is for Python 2 (tested with our production Python 2.6).

--

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[Ezio Melotti]

Ezio Melotti  added the comment:

Do you have any use case for x = 0050?
I don't any reason to adding leading 0s to a literal, but with int() the 
situation is different because you might get string with leading 0s from 
somewhere else.  Also note that the int() function is more flexible and there 
are other similar "inconsistencies":

>>> x = int('１２')
>>> x
12
>>> x = １２
  File "", line 1
x = １２
 ^
SyntaxError: invalid character in identifier


I suggest closing this as "rejected".

--
nosy: +ezio.melotti, rhettinger

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[Nadeem Vawda]

Nadeem Vawda  added the comment:

The behaviour of int() can be made consistent with the syntax for Python
integer literals by specifying a base of 0:

>>> int("0050", 0)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 0: '0050'

>>> int("0o050", 0)
40

>>> int("0x050", 0)
80

>>> int("0b010", 0)
2

As for changing the default behaviour, I think it would be a bad idea.
Having ``0050'' be an invalid token is perhaps jarring to people used to
C/C++/Java/etc., but at least attempts to use it fail loudly and
obviously. Having it be valid and yet mean something different could lead
to nasty surprises for the unsuspecting.

--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue12072] Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6a546bf5252f by Ezio Melotti in branch '2.7':
#12072: add missing parenthesis in the doc.  Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/6a546bf5252f

New changeset 68134a384c73 by Ezio Melotti in branch '3.1':
#12072: add missing parenthesis in the doc.  Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/68134a384c73

New changeset 68dd623f77f4 by Ezio Melotti in branch '3.2':
#12072: merge with 3.1.
http://hg.python.org/cpython/rev/68dd623f77f4

New changeset d6f899ae4ca0 by Ezio Melotti in branch 'default':
#12072: merge with 3.2.
http://hg.python.org/cpython/rev/d6f899ae4ca0

--
nosy: +python-dev

___
Python tracker 

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

[issue12072] Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides

[Ezio Melotti]

Ezio Melotti  added the comment:

Fixed, thanks for the patch!

--
assignee: docs@python -> ezio.melotti
nosy: +ezio.melotti
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

[issue12127] Inconsistent leading zero treatment

[Mark Dickinson]

Mark Dickinson  added the comment:

Well, I'd personally like to see those leading zeros accepted at some point in 
Python's future, for the sake of cleanliness and consistency.  Not just 
consistency with int(), but also e.g. with float literals:

>>> 0050.
50.0
>>> 0050
  File "", line 1
0050
   ^
SyntaxError: invalid token

I'm just not sure whether we're at that point yet.

I don't find the PEP 3127 argument that we should protect people from 
subsequent confusion in other languages with 'leading zero implies octal' 
semantics at all convincing.

On the other hand, I do see the case for not having Python 3 silently behave 
differently from Python 2.

It seems worth a discussion, at least.

--

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[Ezio Melotti]

Ezio Melotti  added the comment:

If the leading 0s are valid for floats (and complex) literals then int literals 
are indeed inconsistent.
If we want consistency with the other literals, it is probably better allowing 
them for ints, because removing them from float/complex is not backward 
compatible, but on the other hand it might be better to wait a few more 
versions to avoid surprises for people porting 2.x code to 3.x.

--

___
Python tracker 

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

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Christophe Devriese]

Christophe Devriese  added the comment:

I realize this bugreport cannot fix 35 years of a bad design decision in
linux. That's not the intention (that's a gordian knot I *will* be keeping a
safe distance from). The intention is to create a saner default situation
for most python programs.

Christophe

2011/5/20 Charles-François Natali 

>
> Charles-François Natali  added the comment:
>
> Hello Christophe,
>
> First and foremost, I think that the FD_CLOEXEC approach is terminally
> broken, as it should have been the default in Unix. Now, we're stuck with
> this bad design.
> But we can't simply change the default to FD_CLOEXEC, for two reasons:
> - we can't silently change the Unix semantics
> - this is going to break some applications: for example, FD inherited
> across exec is used by super servers such as inetd, and there are others
> very legitimate uses
>
> >  in the class TCPServer
> >  add the following 2 lines in __init__ after self.socket = socket( ...:
> >flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
> >fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)
>
> There are at least two problems with this approach:
> 1) there's a race between the socket creation and the call to fcntl
> 2) accept doesn't necessarily inherit the FD_CLOEXEC flag
>
> 1) can be fixed on systems that support it through SOCK_CLOEXEC
> 2) can be fixed on systems that support it through accept4(), but it seems
> to break badly on some systems, see issue #10115
>
> But I think this is a perfectly legitimate request, so one approach to
> tackle this problem could be:
> - since accept4() seems to fail so badly in some configurations, the only
> portable and reliable choice left is probably to call accept() then
> fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We might
> reconsider this syscall in a couple years when we're sure it's implemented
> correctly
> - in the socketserver module, add a new set_socket_cloexec attribute to
> BaseServer, which would do the right thing (i.e. create the socket with
> SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in
> TCPServer, call fcntl(FD_CLOEXEC) after accept.
>
> That way, this would at least fix the problem for people using the
> socketserver module. People using sockets directly of course have the option
> of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.
>
> Gregory, any thoughts on this?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___I realize this bugreport cannot fix 35 years of a bad design decision in linux. 
That's not the intention (that's a gordian knot I *will* be keeping a 
safe distance from). The intention is to create a saner default situation for 
most python programs.

Christophe2011/5/20 
Charles-François Natali rep...@bugs.python.org>


Charles-François Natali neolo...@free.fr> added the comment:

Hello Christophe,

First and foremost, I think that the FD_CLOEXEC approach is terminally broken, 
as it should have been the default in Unix. Now, we're stuck with this bad 
design.
But we can't simply change the default to FD_CLOEXEC, for two reasons:
- we can't silently change the Unix semantics
- this is going to break some applications: for example, FD inherited across 
exec is used by super servers such as inetd, and there are others very 
legitimate uses

>  in the class TCPServer
>  add the following 2 lines in __init__ after self.socket = socket( 
...:
>    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
>    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

There are at least two problems with this approach:
1) there's a race between the socket creation and the call to fcntl
2) accept doesn't necessarily inherit the FD_CLOEXEC flag

1) can be fixed on systems that support it through SOCK_CLOEXEC
2) can be fixed on systems that support it through accept4(), but it seems to 
break badly on some systems, see issue #10115

But I think this is a perfectly legitimate request, so one approach to tackle 
this problem could be:
- since accept4() seems to fail so badly in some configurations, the only 
portable and reliable choice left is probably to call accept() then 
fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We 
might reconsider this syscall in a couple years when we're sure it's 
implemented correctly


- in the socketserver module, add a new set_socket_cloexec attribute to 
BaseServer, which would do the right thing (i.e. create the socket with 
SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in TCPServer, 
call fcntl(FD_CLOEXEC) after accept.



That way, thi

[issue12127] Inconsistent leading zero treatment

[Eric V. Smith]

Eric V. Smith  added the comment:

I don't buy the "confusion with other languages" argument. It's a different 
language. People know that.

I'd like to see leading zeros allowed for integer literals, but I don't feel 
strongly about it, so +0. I'd mainly use them for tables of numbers that I'd 
like to line up.

If using 2to3 or 3to2, they could deal with it. The only case it would cause 
you problems is code that you want to run unchanged in 2.x and 3.x.

--

___
Python tracker 

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

[issue3754] cross-compilation support for python build

[Greg Hellings]

Greg Hellings  added the comment:

Current patch errors with the following message:
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/manual/lib 
-L/binary/lib -L/manual/lib -L/binary/lib  Parser/acceler.o Parser/grammar1.o 
Pars
er/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o 
Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o 
Objects/obmalloc.o
Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o 
Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o 
Parser/pgenmain
.o -lintl -lpthread  -o Parser/pgen.exe
./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c
./Grammar/Grammar: line 18: single_input:: command not found
./Grammar/Grammar: line 18: simple_stmt: command not found
./Grammar/Grammar: line 18: compound_stmt: command not found
./Grammar/Grammar: line 19: syntax error near unexpected token `NEWLINE'
./Grammar/Grammar: line 19: `file_input: (NEWLINE | stmt)* ENDMARKER'
make: *** [Parser/pgen.stamp] Error 2

--

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Per the suggestion in the Visual Studio forums, I posted a report against 
Visual Studio here: 
https://connect.microsoft.com/VisualStudio/feedback/details/669601/regression-calling-wstat64i32-on-symlink-directory-with-kb2467174-installed#details

--

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[R. David Murray]

R. David Murray  added the comment:

IMO 3.3 is definitely too soon.  3.4 may be too, depending on how many people 
are stuck on legacy systems using 2.7.

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

[issue1746656] IPv6 Interface naming/indexing functions

[Charles-François Natali]

Changes by Charles-François Natali :


Removed file: http://bugs.python.org/file22025/socket_if.diff

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Charles-François Natali]

Charles-François Natali  added the comment:

> You use UTF-8 encoding:

Here's an updated patch taking your comments into account (I'm really 
blissfully ignorant when it comes to encoding issues, so I hope it will be OK 
this time).

--
Added file: http://bugs.python.org/file22039/socket_if.diff

___
Python tracker 

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

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Charles-François Natali]

Charles-François Natali  added the comment:

> That's not the intention (that's a gordian knot I *will* be keeping
> a
> safe distance from). The intention is to create a saner default situation
> for most python programs.

I understand what you're saying, and I agree with you on the principle.
But the point I was making is that we can't make this the "default
situation", for the reasons explained above (we can't change the
default socket semantics, and it's going to break some applications,
which is unacceptable).
That's why I was suggesting to add this as an option to the
socketserver module (since that's the piece of code you were referring
to).
The Python interpreter is not a simple standalone library/application,
we can't just make those kind of changes.

P.S.: please avoid sending html messages, they result in a spurious
"unnamed" file being attached.

--

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Gregory P. Smith]

Gregory P. Smith  added the comment:

that patch looks good.  though I do wish we had a function similar to 
PyObject_AsStringEncodedFSDefault() so that the ParseTuple call wasn't needed 
for this relatively common operation when interfacing with system library calls 
that deal in C strings.

--

___
Python tracker 

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

[issue1597850] Cross compiling patches for MINGW

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy:  -gregory.p.smith

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[STINNER Victor]

STINNER Victor  added the comment:

> that patch looks good

I tested it with non-ASCII interface names: it works as expected with
ASCII and UTF-8 locales. It's the first time that I see the "O&" format
for Py_BuildValue(), I didn't know this one. The patch looks good.

@neologix: You can commit it into Python 3.3. Tell me if you need
help ;-)

> though I do wish we had a function similar to
> PyObject_AsStringEncodedFSDefault() so that the ParseTuple call wasn't
> needed for this relatively common operation when interfacing with
> system library calls that deal in C strings.

PyUnicode_FSConverter and PyUnicode_FSDecoder don't fit your needs?

What you would be the purpose of PyObject_AsStringEncodedFSDefault()?
What is its prototype?

--

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Roundup Robot]

Roundup Robot  added the comment:

New changeset cc60d0283fad by Charles-François Natali in branch 'default':
Issue #1746656: make if_nameindex(), if_indextoname() and if_nametoindex()
http://hg.python.org/cpython/rev/cc60d0283fad

--

___
Python tracker 

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

[issue11643] Use |version| instead of X.Y in the doc

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +georg.brandl

___
Python tracker 

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

[issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Honestly, now that it's been established that it has to do with a bogus system 
default (on Mageia/Mandriva installs), I'm not sure it's worth fixing if it 
means adding more logic to the tests.

--
assignee: brett.cannon -> 

___
Python tracker 

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

[issue1006238] cross compile patch

[Éric Araujo]

Éric Araujo  added the comment:

Hi wrobell.  As a new feature, this could not be backported to stable versions. 
 Regarding status, there are currently a number of duplicate or overlapping 
reports and patches, it’s rather difficult to find out which one should be 
reviewed.

--

___
Python tracker 

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

[issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import

[R. David Murray]

R. David Murray  added the comment:

In fact, not fixing it might send a small message as to what we think about 
that particular system default :)

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

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

[Éric Araujo]

Éric Araujo  added the comment:

> ...py3k-20110520...
For successive versions of the same patch, it’s best to remove the obsolete 
ones and add the new one, all with the same name.

> with updates of integrated recently distutil2
Your patch touches distutils, which is not acceptable.  Also, it contains a lot 
of FIXME comments.  I suggest you open reports for those bugs and make this one 
depend on them.  Please post a patch when it’s ready for review; in-development 
patches don’t really help.

--
dependencies: +cross-compilation support for python build

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

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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file17362/python-trunk-20100516-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file17779/python-trunk-20100626-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file18626/python-trunk-20100824-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file19587/python-2.7-20101112-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file19589/python-py3k-20101112-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file20538/python-2.7-20110126-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file20540/python-py3k-20110126-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file21571/python-py3k-20110407-MINGW.patch

___
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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file18339/py3k_mingwmsys_autogen.diff

___
Python tracker 

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

[issue1006238] cross compile patch

[wrobell]

wrobell  added the comment:

Hi Eric,

Good point. I was just about ask, which bug and patch are the primary ones? :)

--

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Charles-François Natali]

Charles-François Natali  added the comment:

> @neologix: You can commit it into Python 3.3. Tell me if you need
> help ;-)

My first commit :-)
What's the next step?
Can this issue be closed, or should I wait until the tests pass on
some buildbot?

--

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> My first commit :-)
> What's the next step?
> Can this issue be closed, or should I wait until the tests pass on
> some buildbot?

You can close the issue nevertheless (as "fixed" /
"committed/rejected"). It can be reopened later if there's a buildbot
failure.
(note that many 3.x buildbots are currently red for another reason :))

--

___
Python tracker 

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

[issue1746656] IPv6 Interface naming/indexing functions

[Charles-François Natali]

Changes by Charles-François Natali :


--
status: open -> closed

___
Python tracker 

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

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

[Charles-François Natali]

Changes by Charles-François Natali :


Removed file: http://bugs.python.org/file16758/urllib_redirect.diff

___
Python tracker 

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

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

[Charles-François Natali]

Charles-François Natali  added the comment:

Those URLs don't trigger the problem anymore, but AFAICT from the code, this 
problem is still present in py3k.
Here's an updated patch.

--
Added file: http://bugs.python.org/file22040/urllib_redirect.diff

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the patches.
One comment: I'm not sure a frozen interpreter can take regular Python flags.
As for the test, you could run a function returning sys.flags from the child to 
the parent, and check that the returned value is equal to the parent's 
sys.flags.

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Ram Rachum]

New submission from Ram Rachum :

When you create an `abc.abstractproperty` on a class, any subclass must 
override it as an actual property in order to be instantiable. But sometimes 
you want to override it with a data attribute instead, i.e. `self.x = 5` 
instead of `x = property(...)`. It would be nice if doing `self.x = 5` would 
satisfy `abc.abstractproperty` and allow the subclass to be instantiable.

--
components: Library (Lib)
messages: 136388
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow `abc.abstractproperty` to be overridden by a data attribute
type: feature request
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

SGTM.  I've written code where this would have been useful.

Could you write a patch?

--
nosy: +stutzbach
stage:  -> needs patch

___
Python tracker 

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

[issue12127] Inconsistent leading zero treatment

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

-0 on making it valid ever, due to the different meaning in many other 
languages.

-1 on making it valid while many still use a version of python where it's valid 
with a different meaning.  Maybe for Python 4. ;-)

--
nosy: +stutzbach

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Eric Snow]

Eric Snow  added the comment:

Wow!  I was literally working on this problem yesterday.  The abstract check is 
done at instantiation time (in object.__new__, typeobject.c).  So as it stands 
__new__ has no way to validate that all your abstract properties have been 
implemented unless they are actual properties.

The solution I found simplest is to not inherit from an ABC but rather to 
register your class to it, and make sure that you are compliant, whether 
through properties or instance names.

If there is a way to check the instance for names that "implement" abstract 
properties that would be a useful thing in my mind.  However, I am not sure 
this is doable without some serious work.  Yesterday I put together a list of 
some solutions that would mostly work that I plan on sending to python-list 
today.  I am not sure if baking that into the core of Python will work.

In my mind this is a question of if abstract methods (and thereby properties) 
are a promise that an instance complies with an interface or just that the 
class of the instance complies.

--
nosy: +ericsnow

___
Python tracker 

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

[issue11109] socketserver.ForkingMixIn leaves zombies, also fails to reap all zombies in one pass

[Justin]

Justin  added the comment:

Don't mean to nag. Just checking to see if anyone has taken it upon themselves 
to commit this yet since it's been a couple more months :P

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

I misread the original request.  I'm +1 on making the following work, if it 
doesn't work already:

class MySubClass(MyAbstractClass):
SOME_LIMIT = 5  # Implements abstract property with fixed value

We should be able to check that at instance creation time.

I think abstract methods and properties are to force the class to define 
methods/properties.  I don't think we should be checking if the instance adds 
things that are not defined at the class level (i.e., don't try to detect 
"self.SOME_LIMT = 5").

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Ram Rachum]

Ram Rachum  added the comment:

Daniel, the behavior you describe is already present in Python 3.2.

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

> Daniel, the behavior you describe is already present in Python 3.2.

Awesome. :)

Do you have a compelling use-case for making "self.x = 5" satisfy an 
abstractproperty requirement?  One of the problems with that approach is that 
the instance does not satisfy the requirements until the line in __init__ is 
called that sets self.x.

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Ram Rachum]

Ram Rachum  added the comment:

Eric, do you think that a solution can be made by calling `__init__` inside of 
`ABCMeta.__new__` and then afterwards checking the instance for attributes?

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Ram Rachum]

Ram Rachum  added the comment:

Ah, I got confused, there's no way we can call `__init__` in `ABCMeta.__new__`.

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Eric Snow]

Eric Snow  added the comment:

As far as I have found, there isn't a way to make it work implicitly without 
changing object.__new__.  I just posted some of the approaches I could think of 
to python-list: 

http://mail.python.org/pipermail/python-list/2011-May/1272604.html

Mostly it is a matter of using decorators for validation.

--

___
Python tracker 

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

[issue11455] issue a warning when populating a CPython type dict with non-string keys

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +brian.curtin

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Sergey Mezentsev]

Changes by Sergey Mezentsev :


Removed file: http://bugs.python.org/file22021/Issue12098.branch-2.6.patch

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Sergey Mezentsev]

Changes by Sergey Mezentsev :


Removed file: http://bugs.python.org/file22022/Issue12098.branch-default.patch

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Sergey Mezentsev]

Changes by Sergey Mezentsev :


Added file: http://bugs.python.org/file22041/Issue12098.branch-2.6.patch

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Sergey Mezentsev]

Changes by Sergey Mezentsev :


Added file: http://bugs.python.org/file22042/Issue12098.branch-default.patch

___
Python tracker 

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

[issue11442] list_directory() in SimpleHTTPServer.py should add charset=... to Content-type header

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Senthil, I just want to verify.  You applied this patch to the Python 2.6 
branch in hg, but not in svn, correct?  Since I'm going to be making the 2.6.7 
release from svn, I am porting this patch over to the svn 2.6 branch.  You 
don't have to do that, but if you can just confirm it, that would be great.

--

___
Python tracker 

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

[issue12098] Child process running as debug on Windows

[Sergey Mezentsev]

Sergey Mezentsev  added the comment:

I updated the patch.
Added a test and remove arguments for frozen interpreter.

--

___
Python tracker 

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

[issue12128] Allow `abc.abstractproperty` to be overridden by a data attribute

[Daniel Urban]

Changes by Daniel Urban :


--
nosy: +durban

___
Python tracker 

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

[issue11662] Redirect vulnerability in urllib/urllib2

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I think this is another patch that needs to be cross-ported to the 2.6 svn 
branch (which I'll do).

--

___
Python tracker 

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

[issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import

[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

[issue10808] ssl unwrap fails with Error 0

[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

[issue12129] Document Object Model API - validation

[Kyle Keating]

New submission from Kyle Keating :

I was doing some tests on using this library and I noticed xml elements and 
attribute names could be created with mal-formed xml because special characters 
which can break validation are not cleaned or converted from their literal 
forms. Only the attribute values are cleaned, but not the names.

For example

import xml.dom

...
doc.createElement("p>") 
...

will just embed a pair of p tags in the xml result. I thought that the xml spec 
did not permit <, >, &, \n etc. in the element name or attribute name? Could I 
get some clarification on this, thanks!

--
components: Library (Lib)
messages: 136402
nosy: Kyle.Keating
priority: normal
severity: normal
status: open
title: Document Object Model API - validation
type: behavior
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

[issue11442] list_directory() in SimpleHTTPServer.py should add charset=... to Content-type header

[Guido van Rossum]

Guido van Rossum  added the comment:

Let me confirm that. Since it is a security patch the entire point of it is to 
be placed in the release.

I don't want to question the reasons for doing the release from svn instead of 
from hg, but I do want to emphasize that the hg branch ought to be considered 
the master which svn should track as closely as possible.  The only reason to 
not port a patch to the svn branch would be if it was submitted to the hg 
branch in contradiction with some policy (e.g. a non-security fix to a branch 
that should only receive security fixes), and then it should probably be rolled 
back in the hg branch (and the decision to do so should be very visible on 
python-dev).

--

___
Python tracker 

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

[issue11442] list_directory() in SimpleHTTPServer.py should add charset=... to Content-type header

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On May 20, 2011, at 10:07 PM, Guido van Rossum wrote:

>
>Guido van Rossum  added the comment:
>
>Let me confirm that. Since it is a security patch the entire point of it is
>to be placed in the release.

Cool, I've ported it over to svn.

>I don't want to question the reasons for doing the release from svn instead
>of from hg, but I do want to emphasize that the hg branch ought to be
>considered the master which svn should track as closely as possible.  The
>only reason to not port a patch to the svn branch would be if it was
>submitted to the hg branch in contradiction with some policy (e.g. a
>non-security fix to a branch that should only receive security fixes), and
>then it should probably be rolled back in the hg branch (and the decision to
>do so should be very visible on python-dev).

I'm okay with that.  Right now I can't push my reconciled hg repo though
because line ending changes were committed to various files in hg but not
svn.  I don't think they're appropriate frankly, but rolling them back causes
hg push to fail.

Antoine suggested whitelisting those files in .hgeol, which I'll investigate.

--

___
Python tracker 

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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Julian]

New submission from Julian :

Trying to use regex 0.1.2011051 with the overlapped=True feature

It works great, unless I have the 'start of string' (caret) character in my 
regular expression:


>>> regex.findall(r"a.*b","abadalaba",overlapped=True)
['abadalab', 'adalab', 'alab', 'ab']
>>> regex.findall(r"^a.*b","abadalaba",overlapped=True)
['abadalab']

--
components: Regular Expressions
messages: 136405
nosy: jcerruti
priority: normal
severity: normal
status: open
title: regex 0.1.20110514 findall overlapped not working with 'start of string' 
expression
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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Brian Curtin]

Brian Curtin  added the comment:

Please report this to the regex bug tracker.

--
nosy: +brian.curtin
resolution:  -> rejected
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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Ezio Melotti]

Ezio Melotti  added the comment:

I think that's normal, the ^ matches only at the beginning of the string.

--
nosy: +ezio.melotti, mrabarnett

___
Python tracker 

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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Julian]

Julian  added the comment:

Sorry for posting in the wrong tracker. I'm a bit dumb: can you please point me 
to the right tracker?

I know ^ should match the beginning of the string, but there are multiple 
overlapping matches with the beginning of the string (as the first set of 
results show). Maybe I'm missing something subtler here?

--

___
Python tracker 

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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Julian]

Julian  added the comment:

Just in case somebody else stumbles upon this, I ended up posting here: 
https://code.google.com/p/mrab-regex-hg/issues/detail?id=10

--

___
Python tracker 

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

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file22038/unnamed

___
Python tracker 

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

[issue12126] incorrect select documentation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The socket HOWTO looks so stupid, obscure and badly written that it should IMO 
be deleted.

--
nosy: +pitrou

___
Python tracker 

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

[issue12126] incorrect select documentation

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue12024] 2.6 svn and hg branches are out of sync

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Although hg2.6 is not yet pushed, svn2.6 has been sync'd so this is ready to go 
for 2.6.7rc2.

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

[issue12124] python -m test test_packaging test_zipimport failure

[Roundup Robot]

Roundup Robot  added the comment:

New changeset bfceb8c8178a by Victor Stinner in branch '2.7':
Issue #12124: zipimport doesn't keep a reference to zlib.decompress() anymore
http://hg.python.org/cpython/rev/bfceb8c8178a

--

___
Python tracker 

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

[issue12124] python -m test test_packaging test_zipimport failure

[STINNER Victor]

Changes by STINNER Victor :


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

[issue4558] with_stdc89

[STINNER Victor]

STINNER Victor  added the comment:

Is it still useful to ensure that ISO C89 compilers are supported in 2011?

--
nosy: +haypo

___
Python tracker 

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

[issue12114] packaging.util._find_exe_version(): potential deadlock

[Roundup Robot]

Roundup Robot  added the comment:

New changeset bf5b974e7d32 by Victor Stinner in branch 'default':
Close #12114: fix a potential deadlock in packaging.util._find_exe_version()
http://hg.python.org/cpython/rev/bf5b974e7d32

--
nosy: +python-dev
resolution:  -> fixed
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

[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression

[Matthew Barnett]

Matthew Barnett  added the comment:

Replied to the regex bug tracker.

--

___
Python tracker 

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

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

[STINNER Victor]

STINNER Victor  added the comment:

+kill(getpid(), SIGINT);

kill() doesn't exist on Windows: use raise() which is more portable and doesn't 
require a PID argument.

We may need to do something on Windows for console applications: see 
SetConsoleCtrlHandler(),
http://msdn.microsoft.com/en-us/library/ms686016(v=vs.85).aspx

+self.assertEqual(returncode, -signal.SIGINT,
+ "not a SIGINT exit code. process stderr:\n%s" % 
stderr)

I don't think that such test can pass on Windows.

--
nosy: +haypo

___
Python tracker 

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

[issue12057] HZ codec has no test

[STINNER Victor]

STINNER Victor  added the comment:

I think that issue #12100 should be fixed (wontfix/fixed) before this one.

--
dependencies: +Incremental encoders of CJK codecs reset the codec at each call 
to encode()

___
Python tracker 

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

[issue11702] dir on return value of msilib.OpenDatabase() crashes python

[Mark Mc Mahon]

Mark Mc Mahon  added the comment:

I wasn't so happy trawling through \windows\installer either :) 

Creating an MSI to test is very simple, and actually quicker than I had 
originally thought. The latest patch (support_dir_for_msi_objs.patch) creates 
the one and just uses that. Optionally I could create a new one each time 
setUp()/tearDown(). But was thinking - let's do that if/when we need to :)

The latest patch updates the tests - but no change to the C code.

(I doubt the error you received is a bug in msilib, and I couldn't repro even 
by opening EVERY MSI in my windows\installer dir. It could be a rights/security 
issue? The previous test was not opening as READ ONLY - even though it never 
saved the db, so that may be another reason?)

--
Added file: http://bugs.python.org/file22043/support_dir_for_msi_objs.patch

___
Python tracker 

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

[issue12131] python built with --prefix fails in site.py with no section 'posix_prefix'

[Ned Deily]

New submission from Ned Deily :

[reported by Stefan Behnel]

With the "packaging" changes introducing Lib/sysconfig.cfg and corresponding 
changes to Lib/sysconfig.py to depend on them, builds that use --prefix= to 
install outside of the build directory fail during startup when site.py calls 
sysconfig:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/configparser.py", line 842, in items
 d.update(self._sections[section])
KeyError: 'posix_prefix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/site.py", line 537, in 
 main()
   File "/.../python/lib/python3.3/site.py", line 522, in main
 known_paths = addusersitepackages(known_paths)
   File "/.../python/lib/python3.3/site.py", line 263, in addusersitepackages
 user_site = getusersitepackages()
   File "/.../python/lib/python3.3/site.py", line 238, in getusersitepackages
 user_base = getuserbase() # this will also set USER_BASE
   File "/.../python/lib/python3.3/site.py", line 228, in getuserbase
 USER_BASE = get_config_var('userbase')
   File "/.../python/lib/python3.3/sysconfig.py", line 576, in get_config_var
 return get_config_vars().get(name)
   File "/.../python/lib/python3.3/sysconfig.py", line 472, in get_config_vars
 _init_posix(_CONFIG_VARS)
   File "/.../python/lib/python3.3/sysconfig.py", line 324, in _init_posix
 makefile = get_makefile_filename()
   File "/.../python/lib/python3.3/sysconfig.py", line 318, in 
get_makefile_filename
 return os.path.join(get_path('stdlib'), config_dir_name, 'Makefile')
   File "/.../python/lib/python3.3/sysconfig.py", line 436, in get_path
 return get_paths(scheme, vars, expand)[name]
   File "/.../python/lib/python3.3/sysconfig.py", line 426, in get_paths
 return _expand_vars(scheme, vars)
   File "/.../python/lib/python3.3/sysconfig.py", line 142, in _expand_vars
 for key, value in _SCHEMES.items(scheme):
   File "/.../python/lib/python3.3/configparser.py", line 845, in items
 raise NoSectionError(section)
configparser.NoSectionError: No section: 'posix_prefix'

The problem is that sysconfig.py expects sysconfig.cfg to be in the same 
directory as it but no changes were added to the Makefile to do so.

A simple-minded workaround is something like this:

diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -947,7 +947,7 @@
elsetrue; \
fi; \
done
-   @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info ; \
+   @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info 
$(srcdir)/Lib/*.cfg ; \
do \
if test -x $$i; then \
$(INSTALL_SCRIPT) $$i $(DESTDIR)$(LIBDEST); \

I am not sure if that is a proper long-term fix.  For real Python 
installations, say, via a binary installer, is the lib/python3.x directory the 
proper place for a .cfg file?  Is it expected that site admins will modify this 
file?

--
assignee: tarek
messages: 136419
nosy: ned.deily, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: python built with --prefix fails in site.py with no section 
'posix_prefix'
versions: Python 3.3

___
Python tracker 

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

[issue12131] python built with --prefix fails in site.py with no section 'posix_prefix'

[Stefan Behnel]

Changes by Stefan Behnel :


--
nosy: +scoder

___
Python tracker 

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

[issue10271] warnings.showwarning should allow any callable object

[lekma]

lekma  added the comment:

how should we go about that?

--

___
Python tracker 

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

[issue12126] incorrect select documentation

[Eli Bendersky]

Eli Bendersky  added the comment:

Antoine, can you be more specific? I recall finding it quite useful when first 
learning Python. Perhaps it can be improved in a few specific places, but 
overall I don't think it's a bad document.

--
nosy: +eli.bendersky

___
Python tracker 

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