date:20100415


Charles-Francois Natali  added the comment:

Please disregard my remark on COND_TIMED_WAIT not updating timeout_result, it's 
wrong (it's really a macro, not a function...)

--

___
Python tracker 

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

[issue8408] need console/pager module

2010-04-15 Thread anatoly techtonik


New submission from anatoly techtonik :

Many many Python tools have duplicating code related to getting console 
properties like width and height to provide pagination and cute progress bars. 
While the issue seems minor, making such features work crossplatform way 
requires many tuits. That's why it is highly desirable to have console module 
inside Python stdlib.

--
components: Library (Lib)
messages: 103187
nosy: techtonik
severity: normal
status: open
title: need console/pager module
type: feature request
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue8326] Cannot import name SemLock on Ubuntu lucid


Mark Dickinson  added the comment:

As an aside, I don't really understand why the sem_open check is failing on the 
build machine.  'man sem_overview' says:

"On a system with Linux 2.6 and a glibc that provides the NPTL threading 
implementation, a complete implementation of POSIX semaphores is provided."

Is some part of this not true for the Ubuntu build machines?

> can't the required kernel version be checked at runtime?

What exact check would that be, and where would you put it?  It seems to me 
that the check may be more complicated than just looking for a kernel version 
(e.g., might depend on libc version, on whether POSIX semaphore support is 
actually compiled into the kernel or not).  Whatever runtime check is used 
would also need to work for *BSD and other systems.

We could try just doing a sem_open test call somewhere at run time (e.g. when 
importing the relevant piece of multiprocessing?);  we'd have to find some way 
to catch the SIGSYS signal that generates on FreeBSD (and on Linux?) though.

--

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able


Ned Deily  added the comment:

I think this is essentially a duplicate of Issue7713.
(Also there doesn't seem to be an "attached".)

--
nosy: +ned.deily

___
Python tracker 

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

[issue5651] OS X Installer: add checks to ensure proper Tcl configuration during build


Changes by Ned Deily :


--
assignee:  -> ronaldoussoren
components: +Macintosh
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue5651] OS X Installer: add checks to ensure proper Tk configuration during build


Changes by Ned Deily :


--
title: OS X Installer: add checks to ensure proper Tcl configuration during 
build -> OS X Installer: add checks to ensure proper Tk configuration during 
build

___
Python tracker 

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

[issue8408] need console/pager module

2010-04-15 Thread anatoly techtonik


anatoly techtonik  added the comment:

How to get console width:

http://stackoverflow.com/questions/566746/how-to-get-console-window-width-in-python
http://code.activestate.com/recipes/440694-determine-size-of-console-window-on-windows/

PDCurses may contain some public domain code:
http://pdcurses.sourceforge.net/
BSD like licensed Console module from Fredrik Lundh:
http://effbot.org/zone/console-handbook.htm

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Julian Scheid  added the comment:

Having this in 2.6/2.7 would be great.

I don't think the ELLIPSIS workaround suggested by Barry works, have you 
actually tried it?

Below is an example where ELLIPSIS doesn't seem to help (run in 2.6.5).  I have 
also tried "...Error:" and "...:", and tried replacing ". . ." by "...", to no 
avail.

I'm assuming this has to do with issue #1192554, or am I making a silly mistake?

Otherwise, are there any other workarounds you can suggest?

Without ellipsis the following example works in 2.6 but of course fails in 3.x.

Failed example:
Redacted.from_str('1-7@') #doctest: +ELLIPSIS
Expected:
Traceback (most recent call last):
  . . .
...ParserError: :
1-7@
^
expected digit
Got:
Traceback (most recent call last):
  
ParserError: :
1-7@
^
expected digit

--
nosy: +Julian.Scheid

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able

2010-04-15 Thread Skip Montanaro


Skip Montanaro  added the comment:

Let's try this again.

--
keywords: +patch
Added file: http://bugs.python.org/file16930/setup.diff

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able

2010-04-15 Thread Skip Montanaro


Skip Montanaro  added the comment:

The patches referenced in issue7713 just unconditionally delete certain
directories from the search path(s).  This patch (now attached) allows
the user to control that.  I presume, for instance, if the MacPorts
folks don't want /usr/X11/... in search paths that they don't have
/usr/X11/bin in PATH when they build Python.  This concept can be
extended to other such directories.  I was mostly concerned about the
Fink and MacPorts directories since they came up in the thread on
python-dev.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Lennart Regebro  added the comment:

The ellipsis doesn't work, because when you have an ellipsis at the beginning 
of the message, doctest will not understand that it's supposed to be an 
Exception, so it doesn't even try to match exceptions, and it will therefore 
always fail.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Julian Scheid  added the comment:

Here's a better example that you can cut and paste.

import optparse

def foo():
"""
>>> foo() #doctest: +ELLIPSIS
Traceback (most recent call last):
  . . .
...OptionError: option bar: foo
"""
raise optparse.OptionError('foo', 'bar')

if __name__ == "__main__":
import doctest
doctest.testmod()

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Julian Scheid  added the comment:

Ah, right... so there is no easy workaround at present?

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Lennart Regebro  added the comment:

Sure: Catch the exception in the test, and fail if it isn't catched.

>>> try:
... do_something_that_raises_exception()
... raise Assertionerror("Exception Blah was not raised")
... except Blah:
... pass

Ugly, yes, but easy. To make it less ugly you can make a "assertRaises()" like 
the one that exists on standard unit tests and call that. Not so ugly.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Julian Scheid  added the comment:

Thank you for the suggestion but in my mind that's not a viable workaround, and 
not just because of uglyness:  I'm using doctest to validate code examples, 
which are included in the documentation and are meant to be educational.  If 
I'd change my examples to match the pattern you suggest they might still serve 
their purpose as a test but they'd become useless as an example.

So it appears there is no real workaround for this issue.  Any chance we can 
get the patch into 2.7?

By the way, I said earlier that Barry suggested the ELLIPSIS workaround but it 
was actually ncoghlan who did so - apologies for the confusion.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Julian Scheid  added the comment:

Hmm, wait.  Here's a variation of your suggestion that works OK-ish even as an 
example:

>>> try:
...# ... code that fails ...
... except mypkg.MyException, e:
...print(str(e))
Expected error message.

This works because it omits the exception type in the output.

It's still far from ideal, because as an example it's more complicated than it 
would need to be, but I guess it works as a stop-gap solution.

Still, +1 for including the patch.

--

___
Python tracker 

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

[issue850728] Semaphore.acquire() timeout parameter

2010-04-15 Thread Andrew Svetlov


Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue5419] urllib.request.open(someURL).read() returns a bytes object so writing it requires binary mode

2010-04-15 Thread Daniel Haertle


Daniel Haertle  added the comment:

I got struck by the same feature. In addition, currently the docs are wrong in 
the examples (at 
http://docs.python.org/dev/py3k/library/urllib.request.html#examples the output 
of f.read() is a string instead of bytes). There I propose the change from 

>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100))

>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100).decode('utf-8'))
http://www.w3.org/TR/xhtml1/DTD/xhtm

The other examples need to be corrected in a similar way.
Even more importantly, the "HOWTO Fetch Internet Resources Using The urllib 
Package" needs to be corrected too.

In the documentation of urllib.request.urlopen I propose to add a sentence 
(after the paragraph "This function returns a file-like object...") explaining 
that reading the object returns bytes that need to be decoded to a string:
"Note that the method read() returns bytes that need to be decoded to a string 
using decode()."

--
nosy: +Danh
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received

2010-04-15 Thread Ezio Melotti


Changes by Ezio Melotti :


--
keywords: +needs review
priority:  -> normal
stage:  -> patch review

___
Python tracker 

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

[issue4079] new urllib2.Request 'timeout' attribute needs to have a default


R. David Murray  added the comment:

Senthil, Facundo, is there a reason this bug shouldn't be fixed, or are we just 
waiting for someone to come up with a patch?  I'm assuming the latter and 
setting it to languishing, but maybe this will wake somebody up who is 
interested in fixing it.

--
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> unit test needed
status: open -> languishing

___
Python tracker 

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

[issue5419] urllib.request.open(someURL).read() returns a bytes object so writing it requires binary mode


Changes by Senthil Kumaran :


--
assignee: georg.brandl -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

___
Python tracker 

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

[issue5419] urllib.request.open(someURL).read() returns a bytes object so writing it requires binary mode


Senthil Kumaran  added the comment:

Yeah, there a example in the tutorial that was changed recently along similar 
lines suggested. 
(http://docs.python.org/dev/py3k/tutorial/stdlib.html#internet-access)
The other examples got to be changed too.

--

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able


Ned Deily  added the comment:

Without testing it, I'd guess the patch wouldn't hurt but it also wouldn't 
affect the OS X installer build as the installer script builds a local copy of 
Sleepycat db4 (since none is included in OS X) and supplies it as an additional 
local library/include file which is always found first by the setup.py code, so 
it never gets to searching the additional paths affected by the patch.  If you 
are building manually and don't supply a local lib, then the build of the dbm 
extension will either fail or it will try to use a MacPorts or Fink version if 
available.

--
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Andrew Bennetts  added the comment:

Your patches look good to me.

(They don't fix platforms without sigaction, but as you say they probably don't 
have siginterrupt, and even if they do they will still have an unfixable race.)

What's the next step?  I can't see an button to add this issue to the "Show 
Needing Review" queue.

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


R. David Murray  added the comment:

Will the modified test fail on platforms that don't define HAVE_SIGACTION?

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

[issue8406] Make some setup.py paths exclude-able

2010-04-15 Thread Ronald Oussoren


Ronald Oussoren  added the comment:

Ned: the patch does have a (positive) effect when building the OSX installer: 
the build-installer script creates private builds of a number of libraries, but 
setup.py can detect other libraries (such as libintl) as well and we don't 
guard against that at the moment.

Skip: I'm +0 on including this functionality, but haven't looked at the patch 
yet.

To be honest I'd must rather remove /opt/local and /sw entirely from setup.py 
and add new configure flags to specify the location of a number of libraries 
(e.g. 'configure --with-sleepycat-db=/opt/local').  Explicit configure flags is 
what other OSS packages seem to use to specify that you like to use a library 
that is not in /usr or /usr/local.

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Charles-Francois Natali  added the comment:

> Will the modified test fail on platforms that don't define HAVE_SIGACTION?

Well, in theory, if the system has siginterrupt but not sigaction, it will 
fail. But as said, I don't think it's possible, see man siginterrupt:
"  This library routine uses an extension of the sigaction(2) system call
 that is not available in 4.2BSD, hence it should not be used if backward
 compatibility is needed."

and the test right now has this at the beginning:
if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
raise unittest.SkipTest("Can't test signal on %s" % \
   sys.platform)

So it pretty much assumes that any Unix system has siginterrupt, hence 
sigaction, so it should be safe.
So I'd say in theory, it will, but I don't think that siginterrupt can be 
available without sigaction anyway.
So feel free to modify the test, or not ;-)

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Andrew Bennetts  added the comment:

Are there any platforms that define HAVE_SIGINTERRUPT but that do not define 
HAVE_SIGACTION?  If there are, then yes I expect they would fail that test.

It would be a shame to delay this fix just because it doesn't fix all 
platforms... is it possible to mark that test as a known failure on a platform 
with siginterrupt but without sigaction?

My initial comment outlined a change that would work for all platforms, but 
would be more complex.  (I think the signal_noreinstall.diff change would be 
good to make even with the more complex approach, though.)

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Andrew Bennetts  added the comment:

FWIW, comparing the "change history" sections of 
 and 
 
suggests that sigaction predates siginterrupt, but it's a wild and varied world 
out there.

--

___
Python tracker 

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

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module


Changes by Andrew Bennetts :


--
nosy: +spiv

___
Python tracker 

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

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module


Antoine Pitrou  added the comment:

I'm with Martin, better to target 3.2 IMO.
Does signalfd really bring something compared to set_wakeup_fd()?
The one big difference I can see is that set_wakeup_fd() doesn't transmit the 
signal number, but this could be fixed if desired (instead of sending '\0', 
send a byte containing the signal number).

--
nosy: +pitrou

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

2010-04-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

The corner case I was talking about was the one where you actually *want* the 
old, more restrictive behaviour (i.e. you specifically want to receive 
'x.y.Exception' and receiving 'a.b.Exception' instead should fail), but still 
want to ignore the details of the exception string representation.

With this change in place, that corner case could be handled fairly easily by 
using the ELLIPSIS option instead of IGNORE_EXCEPTION_DETAIL (or else mandating 
the exception details as well the type).

This change trips my "feature" meter, so it's probably too late for 2.7 (adding 
Benjamin to confirm), but definitely a good candidate for 3.2 later in the year.

--
nosy: +benjamin.peterson
versions: +Python 3.2 -Python 3.1

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


R. David Murray  added the comment:

Yes, my question was directed at finding out if there were any platforms on 
which we'd have to add an additional skip (which would mean refactoring that 
test into two tests).  But if the buildbots are all happy after it is applied 
we can probably choose to not worry about it until/if we get a bug report.

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Charles-Francois Natali  added the comment:

Well, I just think that the probability of having siginterrupt without 
sigaction is far less than having a Unix system without siginterrupt (which the 
current test_signal assumes). Or just drop the patch for the test, it honestly 
doesn't bother me ;-)

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received

2010-04-15 Thread Jean-Paul Calderone


Jean-Paul Calderone  added the comment:

> Will the modified test fail on platforms that don't define HAVE_SIGACTION?

Only if they also have siginterrupt, which seems unlikely (as neologix 
explained).  The implemented behavior on such platforms is unmodified from 
current trunk, while the test requires new behavior.

I think it's probably worth testing this new behavior separately from the test 
for the existing behavior anyway, for the sake of clarity.  If it turns out 
there's a platform with siginterrupt but not sigaction, then that'll also let 
the test be skipped there, which is nice (though this case seems unlikely to 
come up).

I'm not exactly sure how we will know if it is expected to fail, though.  I 
don't think `HAVE_SIGACTION` is exposed nicely to Python right now.  Perhaps 
the signal module should make this information available (it's somewhat 
important now, as it will mean the difference between a nicely working 
signal.siginterrupt and a not-so-nicely working one).

This quirk probably also bears a mention in the siginterrupt documentation.

A few other thoughts on the code nearby:

  * There seems to be no good reason to special case SIGCHLD in signal_handler. 
 The comment about infinite recursion has no obvious interpretation to me.  
Fortunately, this is irrelevant on platforms with sigaction, because the 
handler remains installed anyway!

  * The distance between the new #ifndef HAVE_SIGACTION check and the 
corresponding #ifdef HAVE_SIGACTION in pythonrun.c is somewhat unfortunate.  
Someone could very easily change the logic in PyOS_setsig and disturb this 
relationship.  I'm not sure how this could best be fixed.  A general idea which 
presents itself is that both of these pieces of code could use a new identifier 
to make this choice, and that identifier could be named/documented such that it 
is obvious that it is used in two different places which must be kept 
synchronized.  Or, some more comments in both places might help.  It seems 
likely that the remaining SIGCHLD check in handle_signal is only there because 
whoever updated PyOS_setsig to use sigaction didn't know about it/remember it.

Aside from those points, the fix seems correct and good.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

Kristján Valur Jónsson added the comment:

Here is yet another point:
if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use the (fair)
semaphore. If it is not present, or HAVE_BROKEN_POSIX_SEMAPHORES defined, the
semaphore is supposed to be emulated using a condition variable.
Now, I don't have access to a mac or linux machine, but does a modern python
build perhaps actually have USE_SEMAPHORES defined? if so, then this entire
rant about a broken lock on pthreads is nonsense.

Please note that the "emulated" semaphore is unfair, as I've pointed out,
whereas a posix_sem object strives to be fair. So this "emulation" is not
working..

Martin, you are right that some mutexes are indeed fair. There has been a move
towards using unfair mutexes, particularly on multicore machines. This is
because they reduce the "lock convoying" problem.
A fair mutex hands off the lock to a waiting thread. That thread is then made
runnable. But on a busy system, it may take a while for that thread to
actually start running and use the locked resource. The reesult is that the
locked resource is unavailable for a longer time. An unfair mutex will wake up
a waiting thread, yet have that thread compete for the mutex with any
interloper that might arrive and claim it. See e.g.
http://www.bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx
and http://developer.amd.com/documentation/articles/Pages/282007123.aspx

___
Python tracker

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


R. David Murray  added the comment:

I think this one is worth making an exception for, since it would mean that a 
project could have 3.x doctests that also work with 2.7, whereas if we leave it 
out of 2.7 the doctests have to stay in 2.x format even if the project has (at 
some future point) dropped support for all earlier versions of 2.x.  (Unless 
3to2 can reformat Exceptions in doctest output?)

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Lennart Regebro  added the comment:

It's not possible for 2to3 to reformat exceptions, as the formatting would need 
to go from TheException to themodule.TheException, and there is no way to 
figure out the module name...

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

2010-04-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

With a little more thought, I'm actually keen on including it as well (although 
the docs still need a bit more tweaking). The 2.x/3.x compatibility point is a 
good one.

If Benjamin OKs it, I'll include this in the list of things I want to get to 
for beta2 (said list seems to be getting longer rather than shorter, but...)

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Antoine Pitrou  added the comment:

> if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use
> the (fair) semaphore.  If it is not present, or
> HAVE_BROKEN_POSIX_SEMAPHORES defined, the semaphore is supposed to be
> emulated using a condition variable.
> Now, I don't have access to a mac or linux machine, but does a modern
> python build perhaps actually have USE_SEMAPHORES defined?

Yes, it does.
Actually, I find it unlikely that any modern Unix would fall back on the
non-semaphore version. All this code is (mostly) very old.

--

___
Python tracker 

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

[issue8409] gettext should honor $LOCPATH environment variable

2010-04-15 Thread Barry A. Warsaw


New submission from Barry A. Warsaw :

LOCPATH is an environment variable recognized by locale(1)

http://man.he.net/?topic=locale§ion=all

gettext.find() should probably consult $LOCPATH and use that for localedir if 
the argument is not given.

--
assignee: barry
components: Library (Lib)
keywords: easy
messages: 103220
nosy: barry
priority: normal
severity: normal
status: open
title: gettext should honor $LOCPATH environment variable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue8409] gettext should honor $LOCPATH environment variable

2010-04-15 Thread Barry A. Warsaw


Changes by Barry A. Warsaw :


--
versions:  -Python 2.7, Python 3.1

___
Python tracker 

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

[issue8409] gettext should honor $LOCPATH environment variable

2010-04-15 Thread Barry A. Warsaw


Changes by Barry A. Warsaw :


--
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able

2010-04-15 Thread Skip Montanaro


Skip Montanaro  added the comment:

Ronald> To be honest I'd must rather remove /opt/local and /sw entirely
Ronald> from setup.py and add new configure flags to specify the
Ronald> location of a number of libraries (e.g. 'configure
Ronald> --with-sleepycat-db=/opt/local').  Explicit configure flags is
Ronald> what other OSS packages seem to use to specify that you like to
Ronald> use a library that is not in /usr or /usr/local.

Right, but then you still have the problem with /usr/local (note the package
patches mentioned in the other issue), and you'd have to go through that
dance for every bit of functionality which might be found in an external
library.

Someone else (David Cornapeau?) mentioned he just uses a chroot jail to
build numpy and scipy installers.  That might ultimately be the best way to
do things.

Skip

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


R. David Murray  added the comment:

@Lennart: no, in that direction (2.7 to 3.x) there's less of a problem.  You 
leave the module name off in the doctest, and have 2to3 add the 
IGNORE_EXCEPTION_DETAIL to the doctest during translation.

I was looking at the farther future case, where a project has moved to 3.x, but 
is still supporting 2.7 by using *3to2*.  3to2 could theoretically peel off the 
IGNORE_EXCEPTION_DETAIL and the module name, but I know that 2to3 doesn't touch 
the *output* of doctests, so I'm thinking that 3to2 probably doesn't either.  
(Maybe it could, for the limited case of Exceptions, but that seems like a big 
enough project to motivate including this patch in 2.7.)

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


Lennart Regebro  added the comment:

Sure, but +IGNORE_EXCEPTION_DETAIL will only work on Python 3.2+, so 2to3 can't 
solve the issue. It can only help once 3.2 does the actual solving. ;)

3to2 could simply remove the module name from exceptions in the output. You 
don't need to touch IGNORE_EXCEPTION_DETAIL for that.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Kristján Valur Jónsson  added the comment:

Oh dear.  I was assuming that the mutex+condition variable were the actual 
implementation mostly in use on pthreads.  This is because of David's GIL open 
talk at pycon, where we were looking at the source and bickering about the 
placement of "pthread_cond_signal()" being after the "pthread_mutex_unlock()" 
call.  

In which case, more than half of this thread is invalid.  I could, perhaps, 
start a new defect: "semaphore emulation using condition variable is broken".

However, I just asked a colleague with a os X to compile python 2.7 and 
_POSIX_SEMAPHORES isn't defined, and so, it is running using the emulation.  
Why, I wonder?  Isn't it defined in unistd.h?

Martin, I don't know if you were suggesting that a "fair" mutex would make the 
emulated semaphore fair too.  You probably weren't, but just in case, the 
fairness of the mutex is immaterial because it is only held for a short time to 
guard the internal state of the "semaphore".  You won't see threads queing up 
on it, but they will queue on the Contition variable.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Antoine Pitrou  added the comment:

> However, I just asked a colleague with a os X to compile python 2.7
> and _POSIX_SEMAPHORES isn't defined, and so, it is running using the
> emulation.  Why, I wonder?  Isn't it defined in unistd.h?

Perhaps a bad combination of defines. Has he checked that the semaphore
path isn't used at all? (just put a #error in the other path) If so,
opening an issue would be good.

I would hope we can drop the emulation path one day.

--

___
Python tracker 

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

[issue2987] RFC2732 support for urlparse (IPv6 addresses)


Senthil Kumaran  added the comment:

Final patch with inclusion of detecting invalid urls at netloc and hostname 
level, tests and NEWS entry.

--
Added file: http://bugs.python.org/file16931/issue2987-final.patch

___
Python tracker 

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

[issue850728] Semaphore.acquire() timeout parameter


Antoine Pitrou  added the comment:

2.7 is in (mostly) feature freeze mode, so I'm retargetting this to 3.2.
(yes, this issue is very old; sorry)
I will try to include it (or a variant thereof; the non-blocking + timeout 
combination doesn't make much sense, so I plan to forbid it) to the py3k branch 
soon.

--
assignee:  -> pitrou
stage: unit test needed -> patch review
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

[issue8299] Improve GIL in 2.7


Kristján Valur Jónsson  added the comment:

Yes, we put #error in both places (defining and undefining USE_SEMAPHORES).  
The colleague in question is Christian Tismer, he is unlikely to have gotten it 
wrong.  I am also curious why David Beazley kept talking about the "binary 
semaphore" when it is apparent that that is supposed to be a "hack" to use on 
platforms that don't have posix semaphores.

This gets curiouser and curiouser.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name


R. David Murray  added the comment:

By that logic, 2to3 can't solve anything.  I don't think there's any question 
that this patch should be applied to 3.2.  3.1 might be an issue as it is a new 
feature, but maybe we can claim it is a bug fix :)

As for 3to2, like I said I don't think 3to2 touches doctest *output*, so 
removing the module name would be require the addition of a whole new feature 
(IIUC).

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Antoine Pitrou  added the comment:

> Yes, we put #error in both places (defining and undefining
> USE_SEMAPHORES).  The colleague in question is Christian Tismer, he is
> unlikely to have gotten it wrong.

Ok, so can you or Christian open an issue about it? We should try to fix
it.

> I am also curious why David Beazley kept talking about the "binary
> semaphore" when it is apparent that that is supposed to be a "hack" to
> use on platforms that don't have posix semaphores.

I think David often uses technical terms (such as "semaphore" or
"signal") in more generic meanings than what you might expect :)

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

I'm looking at this again, after installing FreeBSD 8.0/amd64 in a VM.

I've reduced Lib/test/test_curses.py to the following 9 lines:

import rlcompleter
import curses
f = open('mytempfile', 'w+b')
stdscr = curses.initscr()
stdscr.putwin(f)
f.seek(0)
curses.getwin(f)
f.close()
curses.endwin()

I then get:

$ ./python Lib/test/regrtest.py test_curses
test_curses
Bus error (core dumped)

>From looking at the core dump, and tracing through with gdb, the core dump  
>occurs when delwin is called (from PyCursesWindow_Dealloc) on the result of 
>curses.getwin(f), as a result of garbage collection.

The 'import rlcompleter' line appears to be necessary to cause this;  I've no 
idea why.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Kristján Valur Jónsson  added the comment:

You do realize, that if we enable the USE_SEMAPHORE, we get the GIL behaviour 
as seen on windows and with my ROUNDROBIN_GIL implementation, right?

Also, at the GIL open space talk on PyCon, David did show us the "emulation" 
source code as if it were _the_ gil.  Well, maybe he can explain it.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Antoine Pitrou  added the comment:

> You do realize, that if we enable the USE_SEMAPHORE, we get the GIL
> behaviour as seen on windows and with my ROUNDROBIN_GIL
> implementation, right?

I haven't studied this argument, but I don't see how that contradicts
anything. The main issue witnessed with the 2.x GIL -- and the point of
Dave Beazley's original talk -- is CPU inefficiency (due to far too many
lock operations).

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


R. David Murray  added the comment:

My understanding is that David noticed the problem originally on MacOS.  If the 
emulation is indeed being used on that platform (and a little googling 
indicates the MacOS posix semaphore implementation is considered at least 
slightly broken, and FreeBSD didn't support it until 7.2), then perhaps that is 
why he was looking at that code.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


R. David Murray  added the comment:

Also note that his results were much worse on MacOS than anyone was seeing on 
Linux, which may support this theory :)

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-15 Thread David Beazley


David Beazley  added the comment:

I hope everyone realizes that all of this bike-shedding about emulated 
semaphores versus "real" semaphores is mostly a non-issue.  For one thing,  go 
look at how a "real" semaphore is implemented by reading the source code to 
pthreads or some other thread library.  You'll find that semaphores are 
implemented using the exact same mechanisms that underly condition variables 
and in some cases, are actually implemented using a mutex lock and a condition 
variable exactly as Python is doing.

Second, the performance of using "real" semaphores still sucks.   So, all of 
the arguing about "fairness" and whatnot seems to be a total waste of time in 
my opinion because it doesn't address the underlying problem.

--

___
Python tracker 

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

[issue5419] urllib.request.open(someURL).read() returns a bytes object so writing it requires binary mode


Senthil Kumaran  added the comment:

Fixed in revision 80092 and merged into release31-maint in revision 80093. I am 
marking this as fixed and closed. If there are any similar issues at other 
places, we will address them as separate bugs.

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

[issue8299] Improve GIL in 2.7


Kristján Valur Jónsson  added the comment:

David, I urge you to reconsider:
The "emulated" semaphore is broken because it is unfair.  It is clearly a 
programming error, born out of naivete about how to implement such primitives.  
Proper semaphores therefore cannot be implemented using the "exact same 
mechanism" because proper semaphores are fair, this one isn't.  You do 
understand why exactly it is unfair, don't you?

Second, with a fair GIL you still get poor performance on multicore with low 
values of "tickinterval" but at least you get predictable scheduling.  The 
emulated semaphore is bad in two ways:  Unpredictable scheduling with thread 
starvation _and_ poor multicore performance.  I don't understand why you prefer 
having two problems to one.

I also think it is worth investigating when exactly the "emulaton" semaphore 
became the "standard".  Did something break in the config script at some point?

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Kristján Valur Jónsson  added the comment:

Googling a bit gave me this:
http://lists.apple.com/archives/darwin-kernel/2005/Dec/msg00022.html
It would appear that mac os X was at least lacking full posix semaphore support 
in 2005.

--

___
Python tracker 

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

[issue8279] python-gdb PyListTests fail

2010-04-15 Thread Dave Malcolm


Dave Malcolm  added the comment:

New version of patch attached

All tests continue to pass for me.

I believe this will fix the "py-list", "py-locals", "py-print" commands and 
their respective tests on Ubuntu; I expect py-up/py-down to still fail due to 
missing gdb.Frame.select method.

--
Added file: http://bugs.python.org/file16932/fix-PyListTests.patch

___
Python tracker 

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

[issue4453] MSI installer shows error message if "Compile .py files to bytecode" option is selected

2010-04-15 Thread Aaron Thomas


Aaron Thomas  added the comment:

I can verify this will all versions of Windows 7, and the versions of python 32 
and 64 bit. I install this at my work to many machines, and every one of them 
crashes when trying to 'compile py scripts to bytecode' during install.  I have 
to left click the setup file after installation (installation fails), and 
choose 'install' in the windows context menu, then choose 'repair python' for 
the installation to complete 'successfully'.

--
nosy: +Aaron.Thomas
versions: +Python 2.5, Python 2.6

___
Python tracker 

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

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

2010-04-15 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

Any update about this issue?
This should be marked as high priority, imho.

--

___
Python tracker 

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

[issue8354] siginterrupt with flag=False is reset when signal received


Charles-Francois Natali  added the comment:

> * There seems to be no good reason to special case SIGCHLD in signal_handler. 
>  The comment about infinite recursion has no obvious interpretation to me.  
> Fortunately, this is irrelevant on platforms with sigaction, because the 
> handler remains installed anyway!

I think that it's possible, on certain systems, that setting a signal handler 
for SIGCHLD while there is un unwaited child (zombie) process triggers a new 
sending of SIGCHLD.
See 
http://standards.ieee.org/reading/ieee/interp/1003-1-90_int/pasc-1003.1-132.html:
"The SIGCHLD or SIGCLD were used for implementing job control.
Since I had implemented job control for both BSD and System V,
I pointed out to the standards group that except for SIG_DFL,
these signals had different semantics.

If a signal handler was set for SIGCLD, then a signal would
be generated if there were any unreaped child processes.
When the signal handler was caught in System V, it was reset
by default to SIG_DFL.  However, if a process did not
reap a child and instead reestablished the signal handler,
it would go into an infinite loop since the signal would
be generated again.  The SIGCLD SIG_IGN behavior was that
the system reaped the child when it completed so
that the application didn't have to deal with it.
However, I believe that a process blocked in wait() would
be awakened, but I am not certain of this.

The SIGCHLD signal on the other hand was generated when
a child completed if a signal handler was set at that time.
No signal would be generated if a signal handler was
established while there was waiting children.
The SIGCHLD signal was also generated when a child process stopped.
I believe that BSD treated SIGCHLD SIG_IGN the same way
that it treated SIGCHLD SIG_DFL."

So, there might exist out there a couple systems that merrily mix SIGCLD and 
SIGCHLD, and re-raise a SIGCHLD when setting a new handler for it when unwaited 
children exist (which is the case in signal_handle, since child processes can't 
be waited for before the main thread gets to execute the handler it set up).

--

___
Python tracker 

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

[issue2090] import with fromlist=[''] causes double initialization of modules

2010-04-15 Thread George Sakkis


George Sakkis  added the comment:

Just bitten by this (through a 3rd party library that uses this pattern) and 
I'm wondering why it was closed as invalid. Passing a non-empty fromlist string 
also imports the tail module but without the side effect of double import, so 
it's not generally harmful. More surprisingly, a colleague discovered 
accidentally that the same behavior happens if you pass one or more slashes: 
__import__('pkg', fromlist=['', '/', '//']) imports 'pkg', 'pkg.', 'pkg./' and 
'pkg.//' !

I'm not arguing that using fromlist to import the tail module is not a hack, 
but the behavior for empty strings and slashes (and whatever else causes 
multiple imports) is clearly a bug. Unless someone is actually relying on this 
double import behavior (very unlikely), I think it should be fixed.

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

[issue8406] Make some setup.py paths exclude-able

2010-04-15 Thread 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

[issue6916] Remove deprecated items from asynchat

2010-04-15 Thread 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

[issue8405] Improve test_os._kill (failing on slow machines)


R. David Murray  added the comment:

I like this version of the patch better.  Is there any reason not to drop the 
initial sleep(0.5) and loop 10 times instead?  Any place we can cut down the 
sleeps so the test suite runs faster on fast machines is good.

As someone else said, it *ought* to be possible to do this without ctypes.  
I'll see if I can find some time to play a few subprocess games on my windows 
KVM instance.

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

[issue5091] Segfault in PyObject_Malloc(), address out of bounds


Charles-Francois Natali  added the comment:

It was a long time ago, but:
- I think the interpreter will never be able to catch all memory allocation 
errors, since because of overcommitting (which Linux does), you can very well 
get a segmentation fault even if the memory allocation routine (be it malloc or 
mmap) is successful (i.e. doesn't return NULL): so basically, we don't have any 
way to avoid that, since we will segfault only when we first touch the 
allocated page
- since your application was "overflowing internal cache", this might very well 
be what happened (or it could have been a memory corruption issue :-)

Peers ?

--
nosy: +neologix

___
Python tracker 

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

[issue8410] Fix emulated lock to be 'fair'


New submission from Kristján Valur Jónsson :

On pthreads plaforms, if the posix_sem functions aren't available (when 
_POSIX_SEMAPHORES isn't defined), the python lock is implemented with a mutex 
and a condition variable.  This appears to be the case on Mac OS X, for example.
The problem is that this lock does not provide fairness to threads trying to 
acquire it.  This makes it a very poor candidate to implement the GIL, which is 
a lock that is held all the time, and all the threads are in constant 
competition to claim.
Other implementations of the python lock, such as the posix_sem based ones 
(linux) and Event based (MS Windows) provide fairness through that underlying 
synchronization primitive.

This patch fixes the "emulated semaphore" by making all competing threads wait 
their turn in the condition variable, thus enjoying whatever fairness that 
primitive provides.

I've not tested this patch for compilation since I don't have access to a mac 
to do that.  But the mechanism has been tested successfully on windows.

See also issue 8299, where this has been discussed at length.

--
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
files: pthread_lock.patch
keywords: needs review, patch, patch
messages: 103247
nosy: krisvale, ronaldoussoren
severity: normal
status: open
title: Fix emulated lock to be 'fair'
versions: Python 2.7
Added file: http://bugs.python.org/file16933/pthread_lock.patch

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able


Ned Deily  added the comment:

Ronald, as far as I can see, the patch as it stands only addresses dbm so more 
work is needed to address all the other cases, the ones that actually matter. 
Issue7713 describes a more serious, general problem because a number of other 
builders / distributers have the same problem, and not only on OS X.  Everyone 
currently needs to maintain their own set of patches on top of every release to 
modify setup.py's search behavior.  That's where the effort should go, I think.

--

___
Python tracker 

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

[issue8410] Fix emulated lock to be 'fair'

2010-04-15 Thread Martin v . Löwis


Martin v. Löwis  added the comment:

> On pthreads plaforms, if the posix_sem functions aren't available
> (when _POSIX_SEMAPHORES isn't defined), the python lock is
> implemented with a mutex and a condition variable.  This appears to
> be the case on Mac OS X, for example. The problem is that this lock
> does not provide fairness to threads trying to acquire it. 

Why do you think condition variables don't provide fairness?

--
nosy: +loewis

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able


Ned Deily  added the comment:

Skip, I saw David's chroot remark but I'm having a hard time envisioning how 
one could use that as a practical matter to build an OS X framework without 
some *serious* changes to the current configure(s), Makefile(s), and installer 
script.

--

___
Python tracker 

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

[issue8411] Improve condition variable emulation on NT


New submission from Kristján Valur Jónsson :

As per Antoine's suggestion, here is a patch to improve condition variable 
emulation on windows.

By using the windows Semaphore (which hasn't always been available) all of the 
problems in emulating condition variables using Events disappear.  in 
particular, the "lost wakeup" bug can be elimintated, and the same object 
easily supports bot the "signal" and "broadcast" mode of waking up threads.  We 
can also use the CRICITAL_SECTION objects as the associated mutex which is much 
lighter weight than using a kernel object.

I do think I´ve caught all the corner cases.  It is also simpler to prove 
because this construct is simpler than the previous one.  If, however, i have 
missed a spot, I'd be interested to know about it.  Not completely impossible 
since race conditions are devious beasts.  Ive tested this extensively on 
Windows.

See also issue 8299 where this implementation was presented.

--
components: Interpreter Core
files: nt_cond.patch
keywords: needs review, patch, patch
messages: 103251
nosy: krisvale, pitrou
severity: normal
status: open
title: Improve condition variable emulation on NT
versions: Python 3.2
Added file: http://bugs.python.org/file16934/nt_cond.patch

___
Python tracker 

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

[issue8408] need console/pager module

2010-04-15 Thread Benjamin Peterson


Benjamin Peterson  added the comment:

Please propose on python-ideas before making a bug.

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

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

2010-04-15 Thread Benjamin Peterson


Benjamin Peterson  added the comment:

2010/4/15 Nick Coghlan :
>
> Nick Coghlan  added the comment:
>
> With a little more thought, I'm actually keen on including it as well 
> (although the docs still need a bit more tweaking). The 2.x/3.x compatibility 
> point is a good one.
>
> If Benjamin OKs it, I'll include this in the list of things I want to get to 
> for beta2 (said list seems to be getting longer rather than shorter, but...)

I'm ok with it if you or someone else takes care of it.

--

___
Python tracker 

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

[issue8406] Make some setup.py paths exclude-able


Ned Deily  added the comment:

Sorry, Ronald, of course that's what you were suggesting with the proposed 
configure --with options.  +1 on that.  I'd just want to ensure that any 
solution addresses any needs in Issue7713, too.  Something like that should.  
There are probably other open issues in a similar vein.

--

___
Python tracker 

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

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

2010-04-15 Thread Benjamin Peterson


Benjamin Peterson  added the comment:

This is ok with me.

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

Here's the top of the backtrace.  (Thanks asmodai for helping me out with 
working out how to build a FreeBSD system ncurses with debugging information.)

#0  0x000801460714 in cannot_delete (win=0x80116b1d0)
at 
/usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base/lib_delwin.c:54
p = (struct _win_list *) 0xdbdbdbdbdbdbdbdb
result = false
#1  0x000801460773 in delwin (win=0x80116b1d0)
at 
/usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base/lib_delwin.c:71
result = -1
#2  0x00080170d140 in PyCursesWindow_Dealloc (wo=0x800eb74c0)
at /usr/home/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:357
No locals.
#3  0x0046325f in _Py_Dealloc (op=0x800eb74c0) at Objects/object.c:2211
dealloc = 0x80170d110 
#4  0x004578d8 in PyDict_DelItem (op=0x800f121b0, key=0x8011062e0)
at Objects/dictobject.c:829
mp = (PyDictObject *) 0x800f121b0
hash = -3668919459648339544
ep = (PyDictEntry *) 0x8010cb5a8
old_value = (PyObject *) 0x800eb74c0
old_key = (PyObject *) 0x8011062e0
__func__ = "PyDict_DelItem"
#5  0x00458a48 in dict_ass_sub (mp=0x800f121b0, v=0x8011062e0, w=0x0)
---Type  to continue, or q  to quit---
at Objects/dictobject.c:1184
No locals.
#6  0x0041aadd in PyObject_DelItem (o=0x800f121b0, key=0x8011062e0)
at Objects/abstract.c:205
m = (PyMappingMethods *) 0x6c2960

--

___
Python tracker 

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

[issue8409] gettext should honor $LOCPATH environment variable

2010-04-15 Thread Roumen Petrov


Roumen Petrov  added the comment:

LOCPATH is not used by GNU gettext.
/usr/share/locale/XX/... - message translation files (GNU gettext)
/usr/lib/locale/xx_XX*/ - locale (GNU libc)

--
nosy: +rpetrov

___
Python tracker 

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

[issue8299] Improve GIL in 2.7


Antoine Pitrou  added the comment:

> Googling a bit gave me this:
> http://lists.apple.com/archives/darwin-kernel/2005/Dec/msg00022.html
> It would appear that mac os X was at least lacking full posix semaphore 
> support in 2005.

Hmm.  OS X really sucks.

--

___
Python tracker 

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

[issue8408] need console/pager module

2010-04-15 Thread Éric Araujo


Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue2090] import with fromlist=[''] causes double initialization of modules

2010-04-15 Thread Brett Cannon


Brett Cannon  added the comment:

If you want a justification, think of it as undefined behavior. When you use an 
empty string in fromlist you are essentially simulating ``from pkg import`` 
which makes absolutely no sense, so no one has cared enough to try to fix this. 
It's such a hack that I don't think people need to worry about fixing it, 
especially with a more sanctioned way to do it and with importlib being 
available in PyPI and running in Python 2.3 and later.

Now if someone bothers to submit a patch to fix the issue that is reasonable 
then it can be considered for fixing, but I view this as such a nonsensical 
call signature that I personally don't see the need to have someone burn some 
time on this unless they really care. As a compromise I have made this a "wont 
fix" bug, but I still don't see the need to open the bug again.

--
priority: normal -> low
resolution: invalid -> wont fix

___
Python tracker 

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

[issue2090] import with fromlist=[''] causes double initialization of modules

2010-04-15 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I concur with Brett.  For the most part, we don't care about implementation 
artifacts and undefined behaviors (as long as it doesn't segfault).

--
nosy: +rhettinger

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

2010-04-15 Thread A.M. Kuchling


A.M. Kuchling  added the comment:

Could I get a login on the buildbot to make a fix?

I bet the problem is with the stdscr object.  PyCurses_InitScr()
does 'return (PyObject *)PyCursesWindow_New(stdscr);'.

PyCursesWindow_Dealloc() does:
  if (wo->win != stdscr) delwin(wo->win);

I bet FreeBSD is clearing contents of the stdscr global variable.  The 
condition in PyCursesWindow_Dealloc() is then true, and it tries to delwin() 
the old value, which is in wo->win.

One fix might be to keep a reference to that PyCursesWindow object holding 
stdscr, and change dealloc to 'if (wo != saved_stdscr_object)'.  Or maybe, 
since multiple calls to initscr() will create multiple window objects holding 
the value of stdscr, window objects should have a 'do_not_delwin' flag.

--

___
Python tracker 

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

[issue4111] Add Systemtap/DTrace probes

2010-04-15 Thread Garen


Changes by Garen :


--
nosy: +Garen

___
Python tracker 

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

[issue2090] import with fromlist=[''] causes double initialization of modules

2010-04-15 Thread Éric Araujo


Éric Araujo  added the comment:

Since ``from pkg import`` makes no sense, would it be okay if __import__ with 
an empty fromlist or slashes raised an error?

--
nosy: +merwok

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

2010-04-15 Thread A.M. Kuchling


A.M. Kuchling  added the comment:

Here's a possible patch; it at least doesn't seem to break the module on MacOS, 
though MacOS doesn't crash with the current code either.

--
keywords: +patch
Added file: http://bugs.python.org/file16935/freebsd-curses.diff

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

> Could I get a login on the buildbot to make a fix?

I think David Bolen (db3l) is the maintainer.  David?

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

> Here's a possible patch

Thanks.  I'll give it a try on my FreeBSD VM and report back.
BTW, did you mean to include the threading change in that patch?

--

___
Python tracker 

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

[issue2090] import with fromlist=

2010-04-15 Thread Brett Cannon


Brett Cannon  added the comment:

On Thu, Apr 15, 2010 at 14:56, Ãric Araujo  wrote:

That's fine with me if someone wrote a patch that did that.

--
title: __import__ with fromlist=[''] causes double initialization of modules -> 
__import__ with fromlist=
Added file: http://bugs.python.org/file16936/unnamed

___
Python tracker 

___On Thu, Apr 15, 2010 at 14:56, Ãric Araujo 
rep...@bugs.python.org> 
wrote:


Ãric Araujo mer...@netwok.org> 
added the comment:

Since ``from pkg import`` makes no sense, would it be okay if __import__ with 
an empty fromlist or slashes raised an error?
That's fine with me if someone wrote a 
patch that did that.
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7384] curses crash on FreeBSD

2010-04-15 Thread Jeroen Ruigrok van der Werven


Changes by Jeroen Ruigrok van der Werven :


--
nosy: +asmodai

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

With that patch, I'm still getting the core dump (with the traceback looking 
pretty much as it did before).

When I traced through this with gdb, I didn't see stdscr getting set to 0 at 
any point.  Unless I missed any, the only curses library calls made (in 
sequence) were:

1. initscr() -> new window win  (=stdscr, presumably)
2. putwin(file, win)
3. getwin(file) -> new window win2, with win2 != win
4. freewin(win2) -> segfault
---
and presumably without the segfault, there would have been calls
to freewin(win) and endwin() too.


And I'm at a complete loss to explain why importing rlcompleter makes a 
difference.  (importing readline also causes the segfault).  I don't think it's 
just to do with random memory changes, since if I replace the readline or 
rlcompleter import by any other randomly chosen python module then there's no 
segfault.

--

___
Python tracker 

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

[issue2090] import with fromlist=

2010-04-15 Thread Brett Cannon


Brett Cannon  added the comment:

Although now that I think about it, there is a slightly sticky situation of 
someone using '' or some name with a slash for a key in __dict__. The usage in 
fromlist would then be "reasonable", but the semantics would be somewhat odd as 
fromlist is really only needed to trigger other imports.

It's probably safe to still make it an error, although it shouldn't be 
special-cased just for slashes and spaces but specifically the logic triggering 
the double import.

--

___
Python tracker 

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

[issue2090] import with fromlist=

2010-04-15 Thread George Sakkis


George Sakkis  added the comment:

> When you use an empty string in fromlist you are essentially simulating 
> ``from pkg import`` which makes absolutely no sense, so no one has
> cared enough to try to fix this.

``from pkg import __bogus__, 123, @$%`` doesn't make sense either and yet the 
equivalent __import__ call doesn't cause multiple imports neither binds 
__name__ to bogus strings, it just imports and returns pkg.

> Since ``from pkg import`` makes no sense, would it be okay if
> __import__ with an empty fromlist or slashes raised an error?

No, this would break lots of working code and would be inconsistent anyway with 
other invalid fromlist inputs. The backwards compatible solution would be to 
treat the empty string (and slashes) like every other input, i.e. prevent 
multiple imports.

--

___
Python tracker 

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

[issue5671] Speed up pickling of lists in cPickle

2010-04-15 Thread Garen


Changes by Garen :


--
nosy: +Garen

___
Python tracker 

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

[issue2090] import with fromlist=

2010-04-15 Thread George Sakkis


George Sakkis  added the comment:

More fun findings: dots are special-cased too, but only if they don't appear 
consecutively (!);

~$ cat pkg/__init__.py
print  __name__

~$ python -c "__import__('pkg', fromlist=['.'])"
pkg
pkg..
~$ python -c "__import__('pkg', fromlist=['..'])"
pkg
~$ python -c "__import__('pkg', fromlist=['...'])"
pkg
~$ python -c "__import__('pkg', fromlist=['././//.'])"
pkg
pkg.././//.
~$ python -c "__import__('pkg', fromlist=['././../'])"
pkg

--

___
Python tracker 

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

[issue8410] Fix emulated lock to be 'fair'