If you've read my blog (eg: on planet python), you will be aware that
I dedicated August to full time email package development. At the
beginning of the month I worked out a design proposal for the remaining
API additions to the email package, dealing with handling message bodies
in a more natural
On 8/30/2013 9:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
But it isn't ;-). Gui apps routinely use event loops and/or threads or
subprocesses to avoid blocking on either user input (which can come from
keyboard or mouse) and maybe disk operations and calc
Hi all,
I think that PEP 450 is now ready for a PEP dictator. There have been a number
of code reviews, and feedback has been taken into account. The test suite
passes. I'm not aware of any unanswered issues with the code. At least two
people other than myself think that the implementation is
On 08/30/2013 06:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
Sometimes it is. And sometimes it's user-input related, or waiting on a local-pipeline related. But in all cases it
means, return whatever is ready, don't block if nothing is ready.
--
~Ethan~
I still think non-blocking sounds network-related...
On Fri, Aug 30, 2013 at 12:23 PM, Eli Bendersky wrote:
>
>
>
> On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou wrote:
>
>>
>> Hello,
>>
>> On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
>> eli.bendersky wrote:
>> > diff --git a/Doc/library/xml.e
ACTIVITY SUMMARY (2013-08-23 - 2013-08-30)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4182 (+14)
closed 26476 (+50)
total 30658 (+64)
Open issues wit
On 8/30/2013 8:18 AM, Christian Heimes wrote:
By the way Coverity Scan doesn't understand Python code. It can only
analyzes C, C++ and Java code.
Have you (or Coverity) thought about which, if any, of the C defect
categories apply to Python? (Assuming no use of ctypes ;-). Would it
make any
I don't have a strong opinion on this either. The distinction between
send() and send_all() makes sense to me though (send_all() works hard to
get all your data out, send() only does what it can quickly).
Personally for calls like select() I think returning early on EINTR makes
sense, it's usually
On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou wrote:
>
> Hello,
>
> On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
> eli.bendersky wrote:
> > diff --git a/Doc/library/xml.etree.elementtree.rst
> b/Doc/library/xml.etree.elementtree.rst
> > --- a/Doc/library/xml.etree.elementtree.rst
> > +++ b/Doc/li
Hello,
On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky wrote:
> diff --git a/Doc/library/xml.etree.elementtree.rst
> b/Doc/library/xml.etree.elementtree.rst
> --- a/Doc/library/xml.etree.elementtree.rst
> +++ b/Doc/library/xml.etree.elementtree.rst
> @@ -105,37 +105,42 @@
> >>> root
On Fri, 30 Aug 2013 12:29:12 +0200
Charles-François Natali wrote:
>
> Furthermore, the stdlib code base is not consistent: some code paths
> handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does
> but not sock_send()...
> Just grep for EINTR and InterruptedError and you'll be amazed
2013/8/30 Amaury Forgeot d'Arc :
> I agree.
> Is there a way to see in C code where EINTR is not handled?
EINTR can be returned on slow syscalls, so a good heuristic would be
to start with code that releases the GIL.
But I don't see a generic way apart from grepping for syscalls that
are documente
I've made a patch. It works except scenario described by Christian Heimes.
See details in http://bugs.python.org/issue18882
On Fri, Aug 30, 2013 at 3:21 PM, Antoine Pitrou wrote:
> Le Fri, 30 Aug 2013 14:06:11 +0200,
> Christian Heimes a écrit :
>> Am 30.08.2013 11:39, schrieb Antoine Pitrou:
>>
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes a écrit :
> Am 30.08.2013 11:39, schrieb Antoine Pitrou:
> >
> > Le Fri, 30 Aug 2013 12:24:07 +0300,
> > Andrew Svetlov a écrit :
> >> Main thread is slightly different from others.
> >> Signals can be subscribed from main thread only.
> >> Tu
Le Fri, 30 Aug 2013 22:09:37 +1000,
Nick Coghlan a écrit :
> On 30 August 2013 20:27, Andrew Svetlov
> wrote:
> > I've filed http://bugs.python.org/issue18882 for this.
>
> I don't actually object to the addition, but is there any way that
> "threading.enumerate()[0]" *won't* be the main thread?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 30.08.2013 01:24, schrieb Sturla Molden:
>
> Do the numbers add up?
>
> .005 defects in 1,000 lines of code is one defect in every 200,000
> lines of code.
>
> However they also claim that "to date, the Coverity Scan service
> has analyzed near
On 30 August 2013 20:29, Charles-François Natali wrote:
> Hello,
>
> This has been bothering me for years: why don't we properly handle
> EINTR, by running registered signal handlers and restarting the
> interrupted syscall (or eventually returning early e.g. for sleep)?
>
> EINTR is really a nuis
On 30 August 2013 20:27, Andrew Svetlov wrote:
> I've filed http://bugs.python.org/issue18882 for this.
I don't actually object to the addition, but is there any way that
"threading.enumerate()[0]" *won't* be the main thread?
(subinterpreters, perhaps, but they're going to have trouble anyway,
si
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
>
> Le Fri, 30 Aug 2013 12:24:07 +0300,
> Andrew Svetlov a écrit :
>> Main thread is slightly different from others.
>> Signals can be subscribed from main thread only.
>> Tulip has special logic for main thread.
>> In application code we can explicitl
2013/8/30 Charles-François Natali
> Hello,
>
> This has been bothering me for years: why don't we properly handle
> EINTR, by running registered signal handlers and restarting the
> interrupted syscall (or eventually returning early e.g. for sleep)?
>
> EINTR is really a nuisance, and exposing it
Hello,
This has been bothering me for years: why don't we properly handle
EINTR, by running registered signal handlers and restarting the
interrupted syscall (or eventually returning early e.g. for sleep)?
EINTR is really a nuisance, and exposing it to Python code is just pointless.
Now some peo
I've filed http://bugs.python.org/issue18882 for this.
On Fri, Aug 30, 2013 at 12:52 PM, Andrew Svetlov
wrote:
> _MainThread can be used as workaround, but adding public function makes value.
>
> Oleg, as I understand _MainThread is a class, not class instance, test
> for threading._MainThread.id
_MainThread can be used as workaround, but adding public function makes value.
Oleg, as I understand _MainThread is a class, not class instance, test
for threading._MainThread.ident doesn't make sense.
On Fri, Aug 30, 2013 at 12:44 PM, Oleg Broytman wrote:
> On Fri, Aug 30, 2013 at 12:24:07PM +0
I missed _MainThread in threading, that's why I've guessed to add
function to signal module.
threading.main_thread() is much better sure.
On Fri, Aug 30, 2013 at 12:39 PM, Antoine Pitrou wrote:
>
> Le Fri, 30 Aug 2013 12:24:07 +0300,
> Andrew Svetlov a écrit :
>> Main thread is slightly differen
On Fri, Aug 30, 2013 at 12:24:07PM +0300, Andrew Svetlov
wrote:
> Main thread is slightly different from others.
> Signals can be subscribed from main thread only.
> Tulip has special logic for main thread.
> In application code we can explicitly know which thread is executed,
> main or not.
> Bu
Le Fri, 30 Aug 2013 11:36:57 +0200,
Victor Stinner a écrit :
>
> If we expose the identifier of the main thread, something should be
> added to the threading module, not the signal module.
Agreed.
> Is it possible that the main thread exit while there are still other
> live threads?
"exit" in
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov a écrit :
> Main thread is slightly different from others.
> Signals can be subscribed from main thread only.
> Tulip has special logic for main thread.
> In application code we can explicitly know which thread is executed,
> main or not.
> But f
2013/8/30 Andrew Svetlov :
> Tulip uses check like
> threading.current_thread().name == 'MainThread'
You should use the identifier, not the name: threading.current_thread().ident.
> This approach has a problem: thread name is writable attribute and can
> be changed by user code.
The ident at
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov a écrit :
> Main thread is slightly different from others.
> Signals can be subscribed from main thread only.
> Tulip has special logic for main thread.
> In application code we can explicitly know which thread is executed,
> main or not.
> But f
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
main or not.
But from library it's not easy.
Tulip uses check like
threading.current_thre
30 matches
Mail list logo
