On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
You could say the same about equally confusing results, yet equality never
raises TypeError (except between datetime instances):
() == []
False
And even closer to home,
date(2012,6,1) == datetime(2012,6,1)
False
I
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
You could say the same about equally confusing results, yet equality never
raises TypeError (except between datetime instances):
Good point.
On Tue, Jun 5, 2012 at 12:17 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
You could say the same about equally
Just to correct a misapprehension seen in this thread: there are still
plenty of closed systems on the planet where every machine is set to UTC so
that local time is UTC regardless of where the machine is physically
located. You just won't hear about many of those systems if you're not
working on
On 6/5/2012 3:17 PM, Guido van Rossum wrote:
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrousolip...@pitrou.net wrote:
You could say the same about equally confusing results, yet equality never
raises
On Tue, Jun 5, 2012 at 5:48 PM, Terry Reedy tjre...@udel.edu wrote:
3.3 enhancement or backported bugfix?
Please move this discussion to the tracker: http://bugs.python.org/issue15006
___
Python-Dev mailing list
Python-Dev@python.org
Terry Reedy wrote:
A rich comparison method may return the singleton NotImplemented if it
does not implement the operation for a given pair of arguments. By
convention, False and True are returned for a successful comparison.
However, these methods can return any value,
That's to give the
On Mon, Jun 4, 2012 at 9:19 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK). It seems
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan ncogh...@gmail.com wrote:
My perspective is that if I'm dealing with strictly absolute time, I
should only need one import: datetime
If I'm dealing strictly with relative time, I should also only need
one import: time
Can you define relative time
On Mon, Jun 4, 2012 at 10:18 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Can you define relative time here? The term makes me think of things
like timedelta.
Timeouts, performance measurement, that kind of thing. Mostly
timescales of less than an hour, and usually less than a minute.
On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote:
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
Personally, I would really like not having to think about the time
module at all, except if I wanted to go low-level (e.g. get a Unix
timestamp from scratch).
+1
Oh and, practicality beats purity.
-Barry
On Mon, Jun 4, 2012 at 8:51 AM, Barry Warsaw ba...@python.org wrote:
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
Personally, I would really like not having to think about the time
module at all, except if I wanted to go low-level (e.g. get a Unix
timestamp from scratch).
+1
Oh and,
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
A big +1 on making conversions between POSIX timestamps and datetime
(with or without timezone) easier.
I am all for achieving this goal, but I think the root of the problem
is not the lack of mxDT's ticks() method. Note
Agreed that having a robust tzinfo object representing local time,
whatever it is would be a good feature too. This shouldn't have to
depend on the Olson tz database; it should just consult the libc
localtime function.
--Guido
On Mon, Jun 4, 2012 at 11:30 AM, Alexander Belopolsky
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
... I heard
a colleague complain that he'd lost several hours trying to figure out
how to determine whether two datetimes were within 24h of each other,
getting confused by what was happening when the two were on
On Mon, Jun 4, 2012 at 11:46 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum gu...@python.org wrote:
... I heard
a colleague complain that he'd lost several hours trying to figure out
how to determine whether two datetimes were
Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK). It seems like a fairly straightforward case of practicality
over purity:
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum gu...@python.org wrote:
You seem to have misread -- I don't want to check if they are exactly
24 hours apart. I want to check if they are at most 24 hours apart.
The timezone can be assumed to be the same on dt1 and dt2.
A variant of (1) was
On Mon, Jun 4, 2012 at 1:57 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum gu...@python.org wrote:
You seem to have misread -- I don't want to check if they are exactly
24 hours apart. I want to check if they are at most 24 hours
On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum gu...@python.org wrote:
..
But I don't know what ticks() is supposed to do.
.ticks(offset=0.0,dst=-1)
Returns a float representing the instances value in ticks (see above).
The conversion routine assumes that the stored date/time value is
given
Can I change this behaviour (before the first beta) in Python 3.3?
Fine with me. That code predates 43e32b2b4004. I don't recall
discussion to set the LC_CTYPE locale and not take it back, but
apparently, this is what Python currently does, which means that
another setlocale call is not
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On
Behalf Of mar...@v.loewis.de
Sent: 18. apríl 2012 07:11
To: python-dev@python.org
Subject: Re: [Python-Dev] issue 9141, finalizers and gc
** **
*From:* python-dev-bounces+kristjan=ccpgames@python.org [mailto:
python-dev-bounces+kristjan=ccpgames@python.org] *On Behalf Of *Maciej
Fijalkowski
*Sent:* 17. apríl 2012 21:29
*To:* Antoine Pitrou
*Cc:* python-dev@python.org
*Subject:* Re: [Python-Dev] issue 9141, finalizers
To: Antoine Pitrou
Cc: python-dev@python.org
Subject: Re: [Python-Dev] issue 9141, finalizers and gc module
PyPy breaks cycles randomly. I think a pretty comprehensive description of what
happens is here:
http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html
http
Well, we specifically decided that objects with __del__ methods that
are part of a cycle cannot be run.
The same reasoning was applied to generators, if they are in a certain state.
What makes iobase so special that its 'close' method can be run even
if it is part of a cycle?
It's a hack,
What I want to know is, why is this limitation in place? Here are
two possibilities:
1) The order of calling finalizers in a cycle is undefined so
it is not a solvable problem. But this would allow a single
object, with only internal cycles to be collected. Currently this
is not
-Original Message-
No, that's not the case at all. As Antoine explains in the issue, there are
plenty of ways in which Python code can be run when breaking a cycle. Not
only weakrefs, but also objects released as a consequence of tp_clear which
weren't *in* the cycle (but hung
On Tue, 17 Apr 2012 17:22:57 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
We are all consenting adults. Everything is allowed - you just have to live
with
the consequences.
Well, we specifically decided that objects with __del__ methods that are part
of a cycle cannot
On Tue, Apr 17, 2012 at 8:30 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 17 Apr 2012 17:22:57 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
We are all consenting adults. Everything is allowed - you just have to
live with
the consequences.
Well, we
On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray rdmur...@bitdance.comwrote:
On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org
wrote:
Here's a different puzzle. Has anyone written a demo yet that
I'm confused. Are you saying that that program always raised
RuntimeError, or that it started raising RuntimeError with the new
behavior (3.3 alpha 2)?
On Tue, Apr 3, 2012 at 2:47 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray
Never mind, I got it. This always raised RuntimeError. I see this
should be considered support in favor of keeping the change, since
sharing dicts between threads without locking is already fraught with
RuntimeErrors.
At the same time, has anyone looked at my small patch (added to the
issue) that
On 03/30/2012 03:25 PM, R. David Murray wrote:
On Fri, 30 Mar 2012 15:13:36 -0400, Etienne Robillardanimelo...@gmail.com
wrote:
So far I was only attempting to verify whether this is related to
PEP-416 or not. If this is indeed related PEP 416, then I must obviously
attest that I must still
The frozendict builtin type was rejected, but we are going to add
types.MappingProxyType: see issue #14386.
types.MappingProxyType(mydict.copy()) is very close to the frozendict
builtin type.
Victor
Thanks, Victor. :)
Will this mean the new dict subclass for CPython will not expose
On Sat, 31 Mar 2012 07:43:28 -0400, Etienne Robillard animelo...@gmail.com
wrote:
Yet I might miss how this new dict type could potentially induce a
RuntimeError unless in python 3.3 a new dict proxy alias is introduced
to perform invariant operations in non thread-safe code.
Etienne,
On Thu, Mar 29, 2012 at 1:48 PM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 29 Mar 2012 16:31:03 -0400, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum gu...@python.org
wrote:
My original assessment was that this only affects
On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org wrote:
Here's a different puzzle. Has anyone written a demo yet that provokes
this RuntimeError, without cheating? (Cheating would be to mutate the
dict from *inside* the __eq__ or __hash__ method.) If you're serious
about
On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum gu...@python.org wrote:
Here's a different puzzle. Has anyone written a demo yet that provokes
this RuntimeError, without cheating? (Cheating would be to mutate the
Try reducing sys.setcheckinterval().
--Guido van Rossum (sent from Android phone)
On Mar 31, 2012 10:45 AM, R. David Murray rdmur...@bitdance.com wrote:
On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum
2012/3/31 Guido van Rossum gu...@python.org:
Try reducing sys.setcheckinterval().
setcheckinterval() is a no-op since the New-GIL. sys.setswitchinterval
has superseded it.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
On Apr 1, 2012 8:54 AM, Benjamin Peterson benja...@python.org wrote:
2012/3/31 Guido van Rossum gu...@python.org:
Try reducing sys.setcheckinterval().
setcheckinterval() is a no-op since the New-GIL. sys.setswitchinterval
has superseded it
Ah, that's at least one thing wrong with my
On 03/29/2012 06:07 PM, R. David Murray wrote:
On Thu, 29 Mar 2012 23:00:20 +0200, Stefan Behnelstefan...@behnel.de wrote:
R. David Murray, 29.03.2012 22:31:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote:
Some of us have
Etienne, I have not understood either of your messages in this thread. They
just did not make sense to me. Do you actually understand the issue at hand?
--Guido
On Friday, March 30, 2012, Etienne Robillard wrote:
On 03/29/2012 06:07 PM, R. David Murray wrote:
On Thu, 29 Mar 2012 23:00:20
Hi Guido,
I'm sorry for being unclear! I just try actually to learn what thoses
consequences for theses 'unattended' mutations in dictionary key lookups
could be, :-)
however, it seems now that I might have touch a nerve without realizing
it. I would therefore appreciate more light on this
Multiple threads can agree by convention not to mutate a shared dict,
there's no great need for enforcement. Multiple processes can't share
dicts.
its not sure I get completely the meaning of mutate... And if
possible, I would like also the rational for the 2nd phrase while we're
at it as
Etienne Robillard, 30.03.2012 17:45:
Sorry also if this is OT... :)
Yes, it is. Please do as Nick told you.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
you wish...are you also truth allergic or irritated by the consequences
of free speech ? Please stop giving me orders. You don't even know me
and this is at all not necessary and good netiquette if you want to
bring a point to ponder.
Sorry for others who thinks this is not OT as I its
Etienne Robillard, 30.03.2012 18:08:
are you also truth allergic or irritated by the consequences of
free speech ?
Please note that free speech is a concept that is different from asking
beginner's computer science questions on the core developer mailing list of
a software development project.
your reasoning is pathetic at best. i pass... Thanks for the tip :-)
Cheers,
Etienne
On 03/30/2012 12:18 PM, Stefan Behnel wrote:
Etienne Robillard, 30.03.2012 18:08:
are you also truth allergic or irritated by the consequences of
free speech ?
Please note that free speech is a concept
On 03/30/2012 02:23 PM, Ethan Furman wrote:
Etienne Robillard wrote:
your reasoning is pathetic at best. i pass... Thanks for the tip :-)
The Python Developer list is for the discussion of developing Python,
not for teaching basic programming.
You are being rude, and a smiley does not make
On 03/30/2012 03:02 PM, Guido van Rossum wrote:
Hey Etienne, I am honestly trying to understand your contribution but
you seem to have started a discussion about free speech. Trust me that
we don't mind your contributions, we're just trying to understand what
you're saying, and the free speech
On Fri, 30 Mar 2012 15:13:36 -0400, Etienne Robillard animelo...@gmail.com
wrote:
So far I was only attempting to verify whether this is related to
PEP-416 or not. If this is indeed related PEP 416, then I must obviously
attest that I must still understand why a immutable dict would prevent
On Fri, Mar 30, 2012 at 12:13 PM, Etienne Robillard
animelo...@gmail.com wrote:
On 03/30/2012 03:02 PM, Guido van Rossum wrote:
Hey Etienne, I am honestly trying to understand your contribution but
you seem to have started a discussion about free speech. Trust me that
we don't mind your
On 03/30/2012 03:27 PM, Guido van Rossum wrote:
On Fri, Mar 30, 2012 at 12:13 PM, Etienne Robillard
animelo...@gmail.com wrote:
On 03/30/2012 03:02 PM, Guido van Rossum wrote:
Hey Etienne, I am honestly trying to understand your contribution but
you seem to have started a discussion about
No, not really. Anyways, I guess I'll have to further dig down why is
PEP-416 is really important to Python and why it was likewise rejected,
supposing I confused the pep 416 and issue 14417 along the way.. :-)
The frozendict builtin type was rejected, but we are going to add
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray rdmur...@bitdance.com wrote:
Some of us have expressed uneasiness about the consequences of dict
raising an error on lookup if the dict has been modified, the fix Victor
made to solve one of the crashers.
I don't know if I speak for the
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum gu...@python.org wrote:
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray rdmur...@bitdance.com
wrote:
Some of us have expressed uneasiness about the consequences of dict
raising an error on lookup if the dict has been modified, the fix
On Thu, 29 Mar 2012 16:31:03 -0400, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum gu...@python.org wrote:
My original assessment was that this only affects dicts whose keys
have a user-implemented __hash__ or __eq__ implementation, and that
R. David Murray, 29.03.2012 22:31:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote:
Some of us have expressed uneasiness about the consequences of dict
raising an error on lookup if the dict has been modified, the fix Victor
On 03/29/2012 04:48 PM, R. David Murray wrote:
On Thu, 29 Mar 2012 16:31:03 -0400, R. David Murrayrdmur...@bitdance.com
wrote:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossumgu...@python.org wrote:
My original assessment was that this only affects dicts whose keys
have a
On Thu, 29 Mar 2012 23:00:20 +0200, Stefan Behnel stefan...@behnel.de wrote:
R. David Murray, 29.03.2012 22:31:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote:
Some of us have expressed uneasiness about the consequences of
On Fri, Mar 23, 2012 at 3:46 PM, Glyph gl...@twistedmatrix.com wrote:
On Mar 23, 2012, at 1:26 PM, Brad Allen wrote:
Thanks, Glyph. In that case maybe the Python subprocess docs need not
single out SystemRoot, but instead plaster a big warning around the
use of the 'env' parameter.
I
On Mar 21, 2012, at 4:38 PM, Brad Allen wrote:
I tripped over this one trying to make one of our Python at work
Windows compatible. We had no idea that a magic 'SystemRoot'
environment variable would be required, and it was causing issues for
pyzmq.
It might be nice to reflect the findings
I tripped over this one trying to make one of our Python at work
Windows compatible. We had no idea that a magic 'SystemRoot'
environment variable would be required, and it was causing issues for
pyzmq.
It might be nice to reflect the findings of this email thread on the
subprocess documentation
2012/3/20 Jim J. Jewett jimjjew...@gmail.com:
In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
Georg Brandl posted:
+ If available, a monotonic clock is used. By default, if *strict* is
False,
+ the function falls back to another clock if the monotonic clock
On Wed, Feb 22, 2012 at 10:14 AM, Barry Warsaw ba...@python.org wrote:
Two more small details to address, and then I think we're ready to start
creating release candidates.
- sys.flags.hash_randomization
In the tracker issue, I had previously stated a preference that this flag
only
Thoughts?
Apparently, there are at least two users of SystemRoot:
- side-by-side (fusion?) apparently uses it to locate the WinSxS
folder, at least on some Windows releases,
- certain registry keys contain SystemRoot, in particular the
path names of crypto providers (this apparently is XP
On 05/12/2011 08:10, Martin v. Löwis wrote:
I agree with Nick that we shouldn't do anything except perhaps
for documentation changes. There are many other environment variables
whose absence could also cause failures to run the executable,
such as PATH, LD_LIBRARY_PATH, etc. Even not passing
On Mon, Dec 5, 2011 at 7:01 PM, Tim Golden m...@timgolden.me.uk wrote:
We could probably do with a HOWTO (or blog post or whatever) on using
subprocess on Windows, not least because a fair amount of the docs
are Unix-centric and actually very slightly confusing for naive
Windows-based
On Sun, Dec 4, 2011 at 8:59 PM, Tim Golden m...@timgolden.me.uk wrote:
So... what's our take on this? As I see it we could:
1) Do nothing: it's the caller's responsibility to understand the
complications of the chosen Operating System.
2) Add a doc warning (ironically, considering the
On 04/12/2011 11:42, Nick Coghlan wrote:
There's actually two questions to be answered:
1. What should we do in 3.2 and 2.7?
2. Should we do anything more in 3.3?
Agreed.
1. Unset 'SystemRoot' in a windows shell
2. Run the test suite and observe the scale of the breakage
Sorry; something I
On 4 December 2011 12:20, Tim Golden m...@timgolden.me.uk wrote:
On 04/12/2011 11:42, Nick Coghlan wrote:
There's actually two questions to be answered:
1. What should we do in 3.2 and 2.7?
2. Should we do anything more in 3.3?
See below...
This is actually a separate issue: how much of
On 04/12/2011 12:41, Paul Moore wrote:
I'm not 100% clear on the problem here. From how I'm reading things,
the problem is that not supplying SystemRoot will cause (some or all)
invocations of subprocess.Popen to fail - it's not specific to
starting Python.
That's basically the situation.
On 04/12/2011, Tim Golden m...@timgolden.me.uk wrote:
Someone raised issue13524 yesterday to illustrate that a
subprocess will crash immediately if an environment block is
passed which does not contain a valid SystemRoot environment
variable.
...
2) Add a doc warning (ironically, considering
That's why I'm suggesting we look specifically at the cases where *Python*
misbehaves in an empty environment on Windows. Those are legitimately our
issue.
The problem in *general* is a platform one, so I don't think it makes sense
for us to modify the environment that has explicitly been passed
On 12/4/2011 5:59 AM, Tim Golden wrote:
http://bugs.python.org/issue13524
Someone raised issue13524 yesterday to illustrate that a
subprocess will crash immediately if an environment block is
passed which does not contain a valid SystemRoot environment
variable.
Note that the calling (Python)
On Mon, Dec 5, 2011 at 7:08 AM, Terry Reedy tjre...@udel.edu wrote:
My inclination would be #4 on Windows, certainly for 3.3, unless there is a
clear reason not to.
Yes, there is: that environment is the *exact* environment that should
be passed to the child processes. It's not our place to go
On Sat, Aug 27, 2011 at 2:59 AM, Ask Solem a...@celeryproject.org wrote:
On 26 Aug 2011, at 16:53, Antoine Pitrou wrote:
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain forked processes is the
right way forward for multiprocessing.
I see two drawbacks:
- it will be slower, since the interpreter
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain forked processes is the
right way forward for multiprocessing.
I see two
On Mon, 29 Aug 2011 13:03:53 -0400
Jesse Noller jnol...@gmail.com wrote:
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain
On Mon, Aug 29, 2011 at 1:16 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Aug 2011 13:03:53 -0400
Jesse Noller jnol...@gmail.com wrote:
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described
Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
Yes, it is annoying; but again - this makes it more consistent with
the windows implementation. I'd rather that restriction than the
sanitization of the ability to use threading and multiprocessing
alongside one another.
That
On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
Yes, it is annoying; but again - this makes it more consistent with
the windows implementation. I'd rather that restriction than the
sanitization of the
On Mon, Aug 29, 2011 at 8:16 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Aug 2011 13:03:53 -0400 Jesse Noller jnol...@gmail.com wrote:
Yes; but spawning and forking are both slow to begin with - it's
documented (I hope heavily enough) that you should spawn
multiprocessing
On Mon, Aug 29, 2011 at 8:42 PM, Jesse Noller jnol...@gmail.com wrote:
On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
That sanitization is generally useful, though. For example if you want
to use any I/O after a fork().
Oh! I don't disagree; I'm just against the
On 8/29/2011 3:41 PM, Nir Aides wrote:
I am not familiar with the python-dev definition for deprecation, but
Possible to planned eventual removal
when I used the word in the bug discussion I meant to advertize to
users that they should not mix threading and forking since that mix is
and
On 26 Aug 2011, at 16:53, Antoine Pitrou wrote:
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it uses internally to manage queues, etc. Removing that
ability would require a
Another face of the discussion is about whether to deprecate the mixing of
the threading and processing modules and what to do about the
multiprocessing module which is implemented with worker threads.
On Tue, Aug 23, 2011 at 11:29 PM, Antoine Pitrou solip...@pitrou.netwrote:
Le mardi 23 août
On Fri, Aug 26, 2011 at 3:18 AM, Nir Aides n...@winpdb.org wrote:
Another face of the discussion is about whether to deprecate the mixing of
the threading and processing modules and what to do about the
multiprocessing module which is implemented with worker threads.
There's a bug open -
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it uses internally to manage queues, etc. Removing that
ability would require a near-total rewrite, which is just a
non-starter.
I
2011/8/23, Nir Aides n...@winpdb.org:
Hi all,
Hello Nir,
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Just for the record, I'm now in favor of the atfork mechanism. It
won't solve the problem for I/O locks, but it'll at
On Tue, 23 Aug 2011 20:43:25 +0200
Charles-François Natali cf.nat...@gmail.com wrote:
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Just for the record, I'm now in favor of the atfork mechanism. It
won't solve the problem
2011/8/23 Antoine Pitrou solip...@pitrou.net:
Well, I would consider the I/O locks the most glaring problem. Right
now, your program can freeze if you happen to do a fork() while e.g.
the stderr lock is taken by another thread (which is quite common when
debugging).
Indeed.
To solve this, a
Le mardi 23 août 2011 à 22:07 +0200, Charles-François Natali a écrit :
2011/8/23 Antoine Pitrou solip...@pitrou.net:
Well, I would consider the I/O locks the most glaring problem. Right
now, your program can freeze if you happen to do a fork() while e.g.
the stderr lock is taken by another
On Sun, May 1, 2011 at 7:31 PM, Georg Brandl g.bra...@gmx.net wrote:
On 30.04.2011 16:53, anatoly techtonik wrote:
On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray rdmur...@bitdance.com
wrote:
The hardest part is debugging the TAL when you make a mistake, but
even that isn't a whole lot
2011/5/2 anatoly techtonik techto...@gmail.com:
On Sun, May 1, 2011 at 7:31 PM, Georg Brandl g.bra...@gmx.net wrote:
On 30.04.2011 16:53, anatoly techtonik wrote:
On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray rdmur...@bitdance.com
wrote:
The hardest part is debugging the TAL when you
On Mon, May 2, 2011 at 11:06, anatoly techtonik techto...@gmail.com wrote:
On Sun, May 1, 2011 at 7:31 PM, Georg Brandl g.bra...@gmx.net wrote:
On 30.04.2011 16:53, anatoly techtonik wrote:
On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray rdmur...@bitdance.com
wrote:
The hardest part is
2011/4/30 anatoly techtonik techto...@gmail.com:
On Tue, Mar 29, 2011 at 4:37 AM, R. David Murray rdmur...@bitdance.com
wrote:
The hardest part is debugging the TAL when you make a mistake, but
even that isn't a whole lot worse than any other templating language.
How much in % is it worse
201 - 300 of 572 matches
Mail list logo
