[issue12723] Provide an API in tkSimpleDialog for defining custom validation functions

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I think we have to reject this issue.
Adding generic validation make sense, but adding just permanent check for 
non-empty string is wrong.

--
nosy: +asvetlov

___
Python tracker 

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

[issue14489] repr() function link on the built-in function documentation is incorrect

[H Xu]

New submission from H Xu :

The `repr()` built-in function link  in this page [ 
http://docs.python.org/library/functions.html ] should link to the built-in 
version of `repr()`.
It should link to: http://docs.python.org/library/functions.html#repr

However, it links to here: http://docs.python.org/library/repr.html#module-repr

--
assignee: docs@python
components: Documentation
messages: 157462
nosy: H.Xu, docs@python
priority: normal
severity: normal
status: open
title: repr() function link on the built-in function documentation is incorrect
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

[issue9634] Add timeout parameter to Queue.join()

[Nick Coghlan]

Nick Coghlan  added the comment:

The thread pool impl where I'm using this: 
http://git.fedorahosted.org/git/?p=pulpdist.git;a=blob;f=src/pulpdist/cli/thread_pool.py

--

___
Python tracker 

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

[issue14065] Element should support cyclic GC

[Eli Bendersky]

Eli Bendersky  added the comment:

Attaching a patch that should fix the build - I don't have write access to 
commit where I am - will be able to commit it later today.

--
Added file: http://bugs.python.org/file25113/issue14065_buildfix.patch

___
Python tracker 

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

[issue14065] Element should support cyclic GC

[Eli Bendersky]

Eli Bendersky  added the comment:

Stefan, thanks. The windows bots were down when I was looking :-/

I'll work on a fix

--

___
Python tracker 

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

[issue9634] Add timeout parameter to Queue.join()

[Nick Coghlan]

Nick Coghlan  added the comment:

The function below is the workaround I plan to use based on the 
undocumented-but-public Thread attributes that relate to the task queue (it's 
essentially just a combination of Queue.join() with the existing structure of 
the Queue.get() implementation):

  def join_queue(q, timeout=None):
  q.all_tasks_done.acquire()
  try:
  if timeout is None:
  while q.unfinished_tasks:
  self.all_tasks_done.wait()
  elif timeout < 0:
  raise ValueError("'timeout' must be a positive number")
  else:
  endtime = _time() + timeout
  while q.unfinished_tasks:
  remaining = endtime - _time()
  if remaining <= 0.0:
  raise Pending
  self.all_tasks_done.wait(remaining)
  finally:
  q.all_tasks_done.release()

--

___
Python tracker 

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

[issue14488] Can't install Python2.7.2

[Janice]

New submission from Janice :

During the installation, an error occurred and I have no idea how to fix it.
Please help!! 
The error says, An error occurred during the installation of assembly
'Microsoft.VC90.CRT,version="9.0.21022.8",publicKeyToken="1fc8b3b81e18e3b",processorArchitecture="x86",type="win32".

Please help me~~

--
components: +Installation
title: Can -> Can't install Python2.7.2
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

[issue14488] Can

[Janice]

Changes by Janice :


--
nosy: kiwii128
priority: normal
severity: normal
status: open
title: Can

___
Python tracker 

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

[issue14487] Add pending() query method to Queue.Queue

[Jeff McNeil]

Jeff McNeil  added the comment:

I looked at doing this. The empty() and full() methods are marked with a 
disclaimer stating they're likely to be removed at some point?

I'm curious, does just checking the value of .unfinished_tasks satisfy 
the requirement? It could still easily be non-zero even if the queue itself is 
empty, signifying work in progress.  Another option might be to allow 
non-blocking use of join()?

--
nosy: +mcjeff

___
Python tracker 

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

[issue9634] Add timeout parameter to Queue.join()

[Nick Coghlan]

Nick Coghlan  added the comment:

I killed off my new issue in favour of this one, since they're covering the 
same ground.

--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue14487] Add pending() query method to Queue.Queue

[Nick Coghlan]

Changes by Nick Coghlan :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Add timeout parameter to Queue.join()

___
Python tracker 

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

[issue9634] Add timeout parameter to Queue.join()

[Nick Coghlan]

Nick Coghlan  added the comment:

I just created #14487 to request a documented API (Queue.pending()) that 
provides a formal mechanism for asking whether or not any jobs are still 
pending (analagous to the existing empty() and full() query methods).

Specifically, what I have is a client process that is executed periodically, 
gathers up a set of tasks and uses a thread pool to submit them in parallel to 
a synchronous API.

If all tasks complete with no new tasks being scheduled, then the client should 
terminate. However, if a new task arrives while any existing task is still in 
progress, then the client should submit it "immediately" (where, due to the 
time scales involved, "immediately" actually means "within the next few 
minutes" so I have plenty of scope to let the client block for a while instead 
of implementing a busy loop).

So, a timeout on join() would actually fit my use case better than the 
pending() API I proposed in the other issue. The processing loop would then 
look something like:

while have_tasks_to_process():
   submit_tasks_to_queue()
   try:
   task_queue.join(timeout)
   except Pending:
   pass

The advantage of having the timeout is that it would avoid the clumsy 
workarounds needed to avoid the busy loop created by the use of a query based 
approach. (Of course, I'm going to have to use the workaround anyway, since my 
client runs on Python 2.6, but still, I believe it meets the "concrete use 
case" criterion).

>From a design aesthetic point of view, a pending() query API and a timeout on 
>join() that throws a Pending exception would match the existing 
>empty()/get()/Empty and full()/put()/Full API triples.

--
nosy: +ncoghlan
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue14487] Add pending() query method to Queue.Queue

[Nick Coghlan]

Changes by Nick Coghlan :


--
components: +Library (Lib)
stage:  -> needs patch
type:  -> enhancement
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

[issue14487] Add pending() query method to Queue.Queue

[Nick Coghlan]

New submission from Nick Coghlan :

The task management API in the Queue module doesn't let you check to see if 
there are any pending tasks still being processed.

A pending() query API (analagous to empty() and full()) would resolve that 
problem.

The use case is for a process that terminates when all current jobs are 
complete, but should immediately start processing any *new* jobs that arrive 
while waiting for the old ones. Using the current Queue.join() method would 
fail the second requirement (since the blocking calls means that no new jobs 
could be added while waiting for the old ones to finish).

--
messages: 157453
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add pending() query method to Queue.Queue

___
Python tracker 

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

[issue14425] Improve handling of 'timeout' parameter default in urllib.urlopen

[R. David Murray]

R. David Murray  added the comment:

Well, it turns out that this design is intentional, because actually using the 
global socket timeout is deprecated (see issue 2451).  (That is, the non-None 
default value of the timeout parameter is a backward compatibility hack.)

So I'm closing this as invalid.  Sorry for the confusion, and thanks for the 
patches, even though they didn't get used this time.  (They did help me realize 
the issue was invalid though, because the tests didn't pass when I applied 
them!)

I still don't like the doc artifact, but I can't think of a way to improve it 
given the nature of the API.

--
nosy: +pitrou
resolution:  -> invalid
stage: commit 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

[issue14486] Add some versionchanged notes in threading docs

[Nick Coghlan]

New submission from Nick Coghlan :

A (very) minor irritation discovered today - the PEP 8 style names were added 
to the threading.Thread API in 2.6, but the only notice of this is up at the 
top of the module docs.

Some embedded notices like:

  ..versionchanged:: 2.6
 Added PEP 8 compliant interfaces. See note at top of page.

might be helpful.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 157451
nosy: docs@python, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Add some versionchanged notes in threading docs
type: enhancement
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

[issue14397] Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock

[STINNER Victor]

STINNER Victor  added the comment:

I'm closing this issue as a duplicate... of the PEP 418. See the python-dev 
mailing list for discussions on this PEP.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue14440] Close background process if IDLE closes abnormally.

[Roger Serwy]

Roger Serwy  added the comment:

Andrew, the reason the subprocess is not closing is due to a thread management 
problem. I found that a dummy thread handles cvar.wait() which is why the 
subprocess fails to terminate properly. 

If you change the tight loop in _getresponse to be:

while myseq not in self.responses:
print(threading.enumerate(), file=sys.__stderr__)
sys.__stderr__.flush()
cvar.wait(1)

Then you'll get the following dumped to the terminal once a second:
[<_DummyThread(Dummy-1, started daemon 139991862630176)>, 
]

The MainThread already stopped, but these two daemon threads don't terminate, 
which is strange. Is this a bug in itself?

Polling the OS for the IDLE frontend process will give an indication to 
terminate the subprocess, but actually terminating the subprocess from within 
the subprocess is the main problem.

Attached is a patch which takes a different approach to terminating the 
subprocess by using .shutdown instead.

--
Added file: http://bugs.python.org/file25112/issue14440_rev2.patch

___
Python tracker 

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

[issue14065] Element should support cyclic GC

[Stefan Krah]

Stefan Krah  added the comment:

Just in case you missed it: The Windows buildbots fail to compile
14abfa27ff19:

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x

--
nosy: +skrah

___
Python tracker 

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

[issue14478] Decimal hashing very slow, could be cached

[Stefan Krah]

Stefan Krah  added the comment:

> but hashing will be faster.

I retract that. The exponent actually makes things worse.

--

___
Python tracker 

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

[issue14478] Decimal hashing very slow, could be cached

[Stefan Krah]

Stefan Krah  added the comment:

I agree that caching the hash would be useful for 3.2, but the
request comes at a unfortunate time: 3.2.3 is about to be released,
and there's no way that the change would go into it.


So let's focus on the C version in 3.3. These are the timings on a
64-bit machine with the C version in 3.3:

int:  0.537806510925293
CachingDecimal:  2.2549374103546143
Decimal:  1.8158345222473145


These are the timings with a hacked C version that caches the hash:

int:  0.5755119323730469
CachingDecimal:  2.3034861087799072
Decimal:  0.4364290237426758



The hash calculation time depends on the size of the coefficient
of the Decimal and the exponent. Note that the context is not
applied when using the Decimal constructor:


>>> Decimal(1e100)
Decimal('1159028911097599180468360808563945281389781327557747838772170381060813469985856815104')


So the numbers you are using have an unusually high precision for
regular decimal floating point arithmetic.

If you want well defined limits, I suggest using either:

>>> Decimal('1e100')
Decimal('1E+100')

Or, if the input really must be a float:

>>> c = getcontext()
>>> c.create_decimal(1e100)
Decimal('1.15902891110E+100')


In that latter case, of course the conversion is inexact and
rounded (but hashing will be faster).

--

___
Python tracker 

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

[issue11734] Add half-float (16-bit) support to struct module

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +pitrou
stage:  -> patch review

___
Python tracker 

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

[issue2636] Adding a new regex module (compatible with re)

[Sandro Tosi]

Sandro Tosi  added the comment:

I've just uploaded regex into Debian: this will hopefully gives some more eyes 
looking at the module and reporting some feedbacks.

--
nosy: +sandro.tosi

___
Python tracker 

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

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Here is another patch, with test.

--
nosy: +amaury.forgeotdarc
stage: test needed -> patch review
Added file: http://bugs.python.org/file25111/picklable_process_exception.patch

___
Python tracker 

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

[issue14470] Remove using of w9xopen in subprocess module

[Brian Curtin]

Changes by Brian Curtin :


--
priority: critical -> release blocker

___
Python tracker 

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

[issue14470] Remove using of w9xopen in subprocess module

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Brian, please don't forget to cleanup subprocess code when you will be ready to.

--
assignee:  -> brian.curtin

___
Python tracker 

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

[issue1584] Mac OS X: building with X11 Tkinter

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Thank you, Ned.

--

___
Python tracker 

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

[issue1584] Mac OS X: building with X11 Tkinter

[Ned Deily]

Ned Deily  added the comment:

It certainly is still possible to patch current Pythons to build with the X11 
Tk 8.5 on OS X.  For example, the current MacPorts Python ports use an X11 Tk 
8.5.  Considering all the issues that have arisen with the other Tcl/Tk 
implementations on OS X (i.e. Cocoa Tk and Carbon Tk), I think it would be 
useful to provide better support for choosing which to build with.  I'll take a 
look at this as a possible feature.

--
assignee:  -> ned.deily
nosy: +ned.deily -BreamoreBoy

___
Python tracker 

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

[issue3033] tkFont added displayof where necessary

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I've updated the patch.

If nobody object I'll commit it soon.

--
nosy: +asvetlov
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file25110/issue3033.diff

___
Python tracker 

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

[issue14065] Element should support cyclic GC

[Eli Bendersky]

Changes by Eli Bendersky :


--
resolution:  -> fixed
stage: needs patch -> 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

[issue14065] Element should support cyclic GC

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 14abfa27ff19 by Eli Bendersky in branch 'default':
Fixes and enhancements to _elementtree:
http://hg.python.org/cpython/rev/14abfa27ff19

--

___
Python tracker 

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

[issue1584] Mac OS X: building with X11 Tkinter

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Is there actual?

--
nosy: +asvetlov
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

[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

[issue12979] tkinter.font.Font object not usable as font option

[Andrew Svetlov]

Andrew Svetlov  added the comment:

The test from ilikepython is incorrect, but after changing to:


import tkinter
import tkinter.font

root = tkinter.Tk()
w = tkinter.Frame(root)
f = tkinter.font.Font(root, family='Arial', size=30)
label = tkinter.Label(w, text="Hello", font=f)
label.pack()
w.pack()
root.mainloop()

it works.

Closing the issue.

--
assignee:  -> asvetlov
nosy: +asvetlov
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
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

[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism

[R. David Murray]

R. David Murray  added the comment:

I made some time to work on this today.  Attached is a new patch.  I've 
incorporated the tests from the existing patches (though I'm doing the 
infrastructure a bit differently).  PLAIN seems to be a specific case of the 
general authenticate, so I just have a generalized test.

My fix is slightly different.  I'm changing the _Authenticate class to except 
either bytes or string as input.  String because that's more natural in 
Python3, bytes because there might be auth mechanisms that require bytes (since 
implementations can define 'X' auth mechanisms).

The authentication callback always gets passed the data as bytes, for the same 
reasons of generality.  So I'd be OK with the idea that the authentication 
handler always has to return bytes...which would require a different fix in 
login_cram_md5.

My login_cram_md5 test passes, so I *think* the fix I made there is OK.  
However, I'm getting a traceback from SSL about the socket being shut down, 
which seems to arise from an imaplib.abort resulting from an unexpected 'b''' 
value.  I'm out of time for working in this right now, so I'm uploading the 
patch to see if anyone else has time to figure it out.  I'll come back to it as 
some point but I don't know when.

--
assignee: docs@python -> r.david.murray
components:  -Documentation
nosy:  -docs@python
stage:  -> patch review
versions:  -Python 3.1
Added file: http://bugs.python.org/file25109/imaplib_authenticate.patch

___
Python tracker 

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

[issue14482] multiprocessing.connection.Listener fails with invalid address on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you for the patch. It's now committed.

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

[issue14482] multiprocessing.connection.Listener fails with invalid address on Windows

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 57c0867fbf30 by Antoine Pitrou in branch '3.2':
Issue #14482: Raise a ValueError, not a NameError, when trying to create
http://hg.python.org/cpython/rev/57c0867fbf30

New changeset ddc5adcedf29 by Antoine Pitrou in branch 'default':
Issue #14482: Raise a ValueError, not a NameError, when trying to create
http://hg.python.org/cpython/rev/ddc5adcedf29

--
nosy: +python-dev

___
Python tracker 

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

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

[Daniel Blanchard]

Daniel Blanchard  added the comment:

I believe I'm still encountering this issue in 2.7:


Exception in thread Thread-3:
Traceback (most recent call last):
  File "/opt/python/2.7/lib/python2.7/threading.py", line 552, in 
__bootstrap_inner
self.run()
  File "/opt/python/2.7/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
  File "/opt/python/2.7/lib/python2.7/multiprocessing/pool.py", line 347, in 
_handle_results
task = get()
TypeError: ('__init__() takes at least 3 arguments (1 given)', , ())

--
nosy: +Daniel.Blanchard
versions: +Python 2.7 -Python 2.6

___
Python tracker 

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

[issue14485] hi, thanks, nice to learn from you

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Dear Junyan, you  are very welcome. Please understand that Python is really a 
contribution of many developers, so if you ever want to contribute to Python, 
please post your bug reports and patches here.

--
nosy: +loewis
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue14485] hi, thanks, nice to learn from you

[junyan]

New submission from junyan :

Thank you very much, thanks for your job of the free software opening to us, 
and I am a primary worker on this aspect research.

best.

Yours
Junyan

--
messages: 157431
nosy: james tao
priority: normal
severity: normal
status: open
title: hi, thanks,  nice to learn from you

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> As for the second point, why else are you calling os.kill if you don't
> want to kill the given process? I don't disagree that it's on the
> perverse side, but that's the functionality available. Perhaps we
> should *not* have the fallback and only operate on the signals?

I just meant that exiting with 0 isn't exactly expected when a process
is forcibly killed (0 meaning success, as far as I know).

--

___
Python tracker 

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

[issue14480] os.kill on Windows should accept zero as signal

[Andrew Svetlov]

Andrew Svetlov  added the comment:

There are no `kill` function in Windows API.
>From my perspective win32_kill was added to emulate posix sibling if possible. 
>If not — better to give another Windows native name to that function.
Really don't see good solution. Maybe better what we can do — declare what 
os.kill cannot be called with 0 signum on Windows for proc presence checking 
and note that fact in os.rst.
Terminating process looks like overcomplication. POSIX kill only sends signal 
to process and nothing more.

--

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[R. David Murray]

R. David Murray  added the comment:

I would think that if Windows doesn't support a specific signal, os.kill should 
raise a ValueError.  But I'm an outsider here, I know nothing about how Windows 
works for this except what I'm reading here.  

To answer your question: there are many reasons to call kill on unix, and only 
a few of them kill the process.  Kill is just an historical name, it really 
means 'send a signal'.

In a broader picture, I think that os.kill calls should have the same 
"meaning", insofar as possible, on both linux and windows.  Having a single API 
with the same syntax but different semantics on different platforms sounds bad 
to me.

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

[issue14480] os.kill on Windows should accept zero as signal

[Brian Curtin]

Brian Curtin  added the comment:

I meant that in the underlying, such as in the TerminateProcess API, 0 doesn't 
mean anything special. As is being debated over on #14484 we currently take all 
integers to be passed to TerminateProcess (the int becomes the killed proc's 
return code), and two signals to pass to GenerateConsoleCtrlEvent (which is 
more like posix os.kill).

--

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Brian Curtin]

Brian Curtin  added the comment:

I don't remember exactly why, but it can be removed. It may have just been left 
in while I was debugging it.

As for the second point, why else are you calling os.kill if you don't want to 
kill the given process? I don't disagree that it's on the perverse side, but 
that's the functionality available. Perhaps we should *not* have the fallback 
and only operate on the signals?

--

___
Python tracker 

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

[issue14480] os.kill on Windows should accept zero as signal

[R. David Murray]

R. David Murray  added the comment:

Hmm.  I would think it would be a good idea to have os.kill do posix emulation 
where that makes sense, it makes cross-platform usage easier.  That's what 
'kill' with no signal does, right (kills the process, just like the posix 
default)?

The posix spec says "If sig is 0 (the null signal), error checking is performed 
but no signal is actually sent. The null signal can be used to check the 
validity of pid." So *signal* zero doesn't have any special meaning on posix, 
either, but it does have a special meaning to the kill command.

It seems like it would be nice to add support for that to the windows version, 
but I'm a little confused.  First you say that signal 0 has no special meaning, 
and then you say that it does (signal.CTRL_C_EVENT).  Which is it?

--
nosy: +r.david.murray
status: pending -> open

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I can't find where we talked about this, maybe just IRC, but that's
> there (perhaps poorly) as a special case.
> 
> 0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version
> first then fall back to TerminateProcess.

Then why set the error?
That said, abruptly killing another process and making it return 0
sounds a bit perverted.

--

___
Python tracker 

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

[issue14440] Close background process if IDLE closes abnormally.

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I still prefer to check in subprocess for parent proc existing.

--

___
Python tracker 

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

[issue14127] add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds

[Larry Hastings]

Larry Hastings  added the comment:

Sorry to let this slide but I just got back from vacation.  Unless anybody has 
any more feedback I'm checking this in tomorrow (Wednesday April 4).  Phew!

--

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Brian Curtin]

Brian Curtin  added the comment:

I can't find where we talked about this, maybe just IRC, but that's there 
(perhaps poorly) as a special case.

0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version first then 
fall back to TerminateProcess.

I was just looking at this myself and it's not great. I actually wish we could 
change what signal.CTRL_C_EVENT means, or maybe add a flag to determine if the 
second parameter is supposed to be a return code or a signal? I'm open to 
anything.

--

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Antonie, you right.

--

___
Python tracker 

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

[issue14484] missing return in win32_kill?

[Antoine Pitrou]

New submission from Antoine Pitrou :

Here is an excerpt from the os.kill implementation under Windows (in 
win32_kill(), posixmodule.c):

if (sig == CTRL_C_EVENT || sig == CTRL_BREAK_EVENT) {
if (GenerateConsoleCtrlEvent(sig, pid) == 0) {
err = GetLastError();
PyErr_SetFromWindowsErr(err);
}
else
Py_RETURN_NONE;
}

It seems there is a missing return in the first branch, when 
GenerateConsoleCtrlEvent() fails.

--
components: Windows
messages: 157419
nosy: asvetlov, brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: missing return in win32_kill?
type: behavior
versions: Python 2.7, 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

[issue14480] os.kill on Windows should accept zero as signal

[Brian Curtin]

Brian Curtin  added the comment:

-1

0 has no special meaning on Windows so I'd rather not add another special case 
for posix emulation. Additionally, 0 unfortunately already means two things as 
it is: signal.CTRL_C_EVENT and the int 0.

--
status: open -> pending

___
Python tracker 

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

[issue14483] inspect.getsource fails to read a file of only comments

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue14483] inspect.getsource fails to read a file of only comments

[Sean Grider]

New submission from Sean Grider :

I have a custom parser that generates html files to describe what python 
scripts do depending on their source comments. I use inspect.getsourcelines to 
parse out different comments styles (I use #@, #@@ and #$ to signal custom 
comments)

I recently found that getsource and getsourcelines return nothing if the file 
contains nothing other than a def main and it's comments.

It seems that getsource stops reading after the last non-comment line. For 
example:

def main():
  """ description """
  #comment1
  #comment2
  #comment3

getsource on the above file will return def main and the doc_string but nothing 
else.

if however I change it to:
def main():
  """ description """
  #comment1
  #comment2
  #comment3
  return

I now get the entire file, but just doing the following:
def main():
  """ description """
  #comment1
  my_var = 123
  #comment2
  #comment3

will now give me def main, the doc_string and comment1, but nothing else.

Is this expected behavior? I would think that the parser should not care if the 
source is comments or code, I just want to read whatever is in the file.

This behavior is present on 2.7.2 on both Windows 7x64 and RedHat 
2.6.39.4-2.fc12.x86_64

--
messages: 157417
nosy: Sean.Grider
priority: normal
severity: normal
status: open
title: inspect.getsource fails to read a file of only comments
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

[issue14466] Rip out mq instructions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Done, thank you.

--
resolution:  -> fixed
stage: needs patch -> 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

[issue14466] Rip out mq instructions

[Roundup Robot]

Roundup Robot  added the comment:

New changeset e1d4b6dc9702 by Antoine Pitrou in branch 'default':
Issue #14466: remove mq-based workflow
http://hg.python.org/devguide/rev/e1d4b6dc9702

--
nosy: +python-dev

___
Python tracker 

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

[issue14481] trivial formatting error in subprocess docs

[R. David Murray]

R. David Murray  added the comment:

Thanks.

--
nosy: +r.david.murray
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

[issue14481] trivial formatting error in subprocess docs

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2c1ce04ded55 by R David Murray in branch '2.7':
#14481: fix formatting of example in subprocess docs.
http://hg.python.org/cpython/rev/2c1ce04ded55

New changeset e5f5652bfe91 by R David Murray in branch '3.2':
#14481: fix formatting of example in subprocess docs.
http://hg.python.org/cpython/rev/e5f5652bfe91

New changeset 9599f091faa6 by R David Murray in branch 'default':
Merge #14481: fix formatting of example in subprocess docs.
http://hg.python.org/cpython/rev/9599f091faa6

--
nosy: +python-dev

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

STINNER Victor  added the comment:

> BTW: Are aware of the existing systimes.py module in pybench,
> which already provides interfaces to high resolution timers usable
> for benchmarking in a portable way ? Perhaps worth mentioning in
> the PEP.

Nope, I didn't know it. It mentioned it in the PEP.

--

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file25103/pep418-3.patch

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file25101/pep418-2.patch

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file25053/pep418.patch

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

STINNER Victor  added the comment:

Patch version 4:
 - Rename time.monotonic() to time.steady()
 - Don't use CLOCK_MONOTONIC_RAW but CLOCK_MONOTONIC for time.highres() and 
time.steady()
 - Use CLOCK_HIGHRES, useful on Solaris
 - Rewrite time.highres() and time.steady() documentation

--
Added file: http://bugs.python.org/file25108/pep418-4.patch

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> I think you need to reconsider the time.steady() name you're using
>> in the PEP. For practical purposes, it's better to call it
>> time.monotonic()
> 
> I opened a new thread on python-dev to discuss this topic.
> 
>> and only make the function available if the OS provides
>> a monotonic clock.
> 
> Oh, I should explain this choice in the PEP. Basically, the idea is to
> provide a best-effort portable function.
> 
>> The fallback to time.time() is not a good idea, since then the programmer
>> has to check whether the timer really provides the features she's after
>> every time it gets used.
> 
> Nope, time.get_clock_info('steady') does not change at runtime. So it
> can only be checked once.

With "every time" I meant: in every application you use the function.
That pretty much spoils the idea of a best effort portable function.

It's better to use a try-except to test for availability of
functions than to have to (remember to) call a separate function
to find out the characteristics of the best effort approach.

>> Instead of trying to tweak all the different clocks and timers into
>> a single function, wouldn't it be better to expose each kind as a
>> different function and then let the programmer decide which fits
>> best ?!
> 
> This is a completly different approach. It should be discussed on
> python-dev, not in the bug tracker please. I think that Python can
> help the developer to write portable code by providing high-level
> functions because clock properties are well known (e.g. see
> time.get_clock_info).

Fair enough.

BTW: Are aware of the existing systimes.py module in pybench,
which already provides interfaces to high resolution timers usable
for benchmarking in a portable way ? Perhaps worth mentioning in
the PEP.

--

___
Python tracker 

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

[issue14480] os.kill on Windows should accept zero as signal

[R. David Murray]

Changes by R. David Murray :


--
nosy: +brian.curtin
stage:  -> needs patch
type: behavior -> enhancement

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

STINNER Victor  added the comment:

> I think you need to reconsider the time.steady() name you're using
> in the PEP. For practical purposes, it's better to call it
> time.monotonic()

I opened a new thread on python-dev to discuss this topic.

> and only make the function available if the OS provides
> a monotonic clock.

Oh, I should explain this choice in the PEP. Basically, the idea is to
provide a best-effort portable function.

> The fallback to time.time() is not a good idea, since then the programmer
> has to check whether the timer really provides the features she's after
> every time it gets used.

Nope, time.get_clock_info('steady') does not change at runtime. So it
can only be checked once.

> Instead of trying to tweak all the different clocks and timers into
> a single function, wouldn't it be better to expose each kind as a
> different function and then let the programmer decide which fits
> best ?!

This is a completly different approach. It should be discussed on
python-dev, not in the bug tracker please. I think that Python can
help the developer to write portable code by providing high-level
functions because clock properties are well known (e.g. see
time.get_clock_info).

> BTW: Thanks for the research you've done on the different clocks and
> timers. That's very useful information.

You're welcome.

--

___
Python tracker 

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

[issue14288] Make iterators pickleable

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 4ff234337e24 by Kristján Valur Jónsson in branch 'default':
Issue #14288: Serialization support for builtin iterators.
http://hg.python.org/cpython/rev/4ff234337e24

New changeset 51c88d51aa4a by Kristján Valur Jónsson in branch 'default':
Issue #14288: Modify Misc/NEWS
http://hg.python.org/cpython/rev/51c88d51aa4a

--
nosy: +python-dev

___
Python tracker 

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

[issue14482] multiprocessing.connection.Listener fails with invalid address on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks. The patch looks good to me.

--
stage:  -> patch review

___
Python tracker 

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

[issue14466] Rip out mq instructions

[Senthil Kumaran]

Senthil Kumaran  added the comment:

On Tue, Apr 03, 2012 at 08:37:35AM +, Ezio Melotti wrote:
> 
> Ezio Melotti  added the comment:
> 
> +   hg import --no-commit < mywork.patch
> 
> Is the '<' correct here?

No!. It should just be hg import --no-commit mywork.patch.

I asked around at PyCon to see if there were people using 'mq' just to
know about their workflow and it's advantages. I think only Ned
mentioned that he was using it, but everyone "theoretically" agreed
that it could be useful extension while working on a patch. When it is
not being used by many, I think it is just adding to the confusion by
it's mention in the devguide. +1 to remove it.

--
nosy: +orsenthil

___
Python tracker 

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

[issue14288] Make iterators pickleable

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Good idea Antoine.
So, I'll with your suggested fix to the unittests I'll commit this and then 
look on while Rome burns.

--

___
Python tracker 

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

[issue14482] multiprocessing.connection.Listener fails with invalid address on Windows

[Popa Claudiu]

New submission from Popa Claudiu :

This is related to http://bugs.python.org/issue14151. 
When using an AF_UNIX address with multiprocessing.connection.Listener or 
Client, the following error will occur, due to the fact that AF_UNIX is not 
present in socket module.

>>> import multiprocessing.connection as con
>>> con.Listener('/var/a.pipe')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python31\lib\multiprocessing\connection.py", line 97, in __init__
self._listener = SocketListener(address, family, backlog)
  File "C:\Python31\lib\multiprocessing\connection.py", line 216, in __init__
self._socket = socket.socket(getattr(socket, family))
AttributeError: 'module' object has no attribute 'AF_UNIX'


The attached patch fixes this issue, the check is done in the newly added 
_validate_family, where a similar check is done for AF_PIPE on Unix systems.

--
components: Library (Lib)
files: multiprocessing.patch
keywords: patch
messages: 157404
nosy: Popa.Claudiu, pitrou
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Listener fails with invalid address on Windows
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25107/multiprocessing.patch

___
Python tracker 

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

[issue14481] trivial formatting error in subprocess docs

[Berker Peksag]

Berker Peksag  added the comment:

Attached a patch.

--
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file25106/issue14481.diff

___
Python tracker 

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

[issue14466] Rip out mq instructions

[Ezio Melotti]

Ezio Melotti  added the comment:

+   hg import --no-commit < mywork.patch

Is the '<' correct here?

I would also mention hg diff right away, and explain about adding/removing 
files after that.
The rest looks good.

--

___
Python tracker 

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

[issue14481] trivial formatting error in subprocess docs

[Chris Rebert]

New submission from Chris Rebert :

The final line under "17.1.4.2. Replacing shell pipeline" 
(http://docs.python.org/dev/library/subprocess.html#replacing-shell-pipeline ) 
isn't formatted as code (e.g. monospaced); it should be.

--
assignee: docs@python
components: Documentation
messages: 157401
nosy: cvrebert, docs@python
priority: normal
severity: normal
status: open
title: trivial formatting error in subprocess docs
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

[issue14428] Implementation of the PEP 418

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Hi Victor,

I think you need to reconsider the time.steady() name you're using
in the PEP. For practical purposes, it's better to call it
time.monotonic() and only make the function available if the OS provides
a monotonic clock.

The fallback to time.time() is not a good idea, since then the programmer
has to check whether the timer really provides the features she's after
every time it gets used.

Regardless of this functional problem, I'm also not sure what you want
to imply by the term "steady". A steady beat would mean that the timer
never stops and keeps a constant pace, but that's not the case for
the timers you're using to implement time.steady(). If you're after
a mathematical term, "continuous" would be a better term, but
again, time.time() is not always continuous.

Instead of trying to tweak all the different clocks and timers into
a single function, wouldn't it be better to expose each kind as a
different function and then let the programmer decide which fits
best ?!

BTW: Thanks for the research you've done on the different clocks and
timers. That's very useful information.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com


2012-04-03: Python Meeting Duesseldorf today

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

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

--
nosy: +lemburg

___
Python tracker 

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

[issue6015] Tkinter Scrollbar in OS X 10.5

[Ned Deily]

Ned Deily  added the comment:

I am unable to reproduce this behavior with current versions of Python 2.7 or 
3.2 on OS X 10.5.8 using either the most recent Apple-supplied Carbon Tcl/Tk 
8.4 or with the latest ActiveState Tcl/Tk 8.4 nor with on OS X 10.7 with Tcl/Tk 
8.4 or 8.5.  There have been many fixes on the Python side to Tkinter and on 
the Tcl/Tk side.  If you can reproduce with a current Python 2.7.2 (or later) 
or 3.2.2 (or later), please reopen with details including which Python build 
and Tcl/Tk are in use.

--
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6 -Python 3.3

___
Python tracker 

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

[issue14480] os.kill on Windows should accept zero as signal

[Andrew Svetlov]

New submission from Andrew Svetlov :

Starting from 3.2 Python supports os.kill for Windows.
It process signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT, and kills pid for 
all other signals.

Posix allows to pass zero signal to check pid for existing.
It will be nice to keep that behavior for Windows also.
The patch should be trivial: just don't call TerminateProcess in 
Modules/posixmodule.c:win32_kill if sig is zero.

--
components: Library (Lib), Windows
keywords: easy
messages: 157398
nosy: asvetlov
priority: normal
severity: normal
status: open
title: os.kill on Windows should accept zero as signal
type: behavior
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