ned up that will fix this use case, making sure
the file is written before the rename. We don't have to touch it.
Of course if you're planning to use the file without renaming then you
probably do need an explicit fsync and an API for that might help
after all. That'
ations of floating point that
I'm not surprised by bugs like this. I'm more surprised that people
expect consistent, deterministic results...
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
s a non-conformant encoder or garbage being misinterpreted as UTF-8).
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
as the difference between 2 other sets), but couldn't get to that
> element easily (get the pun?)
item, = set_of_one
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
est_mailbox. I've got posted a patch to fix it
> (see issue #6896), but I would like to know if such OS behaviour is normal.
Looks like an OS bug to me. Linux I'm guessing?
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
explicitly:
temp = x == 0
if temp.isnan() or temp:
else:
IEEE 754 is intended for a very different context. I don't think it
makes sense to attempt literal conformance to it.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing l
rack of how python handled NaN.
I thought "comparisons always evaluate to false" was the rule.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
ization, as it is both portable and robust.
I find it shocking to change a semantic I've come to see as a core
part of the language, but I can't come up with a rational reason to
oppose it. The approach is sane and the performance impact
on how they're broken, not on how
they'd be correct (including possible math after the comparison!) if
the language compared properly.
Without such use cases allowing comparison seems like a lot of work for nothing.
--
Adam Olsen, aka Rhamphoryncus
__
ction/complex -> complex, etc). This
gives us a preference for fast, inexact results.
Decimal is more precise, and pays a performance cost for it. It also
seems odd to stick it between float and complex (nobody's planning a
ComplexDecimal, right?) That suggests it should go between Fraction
correspond to is the code. Only going rightward through
the types is what we have today. A linear progression is a lot
simpler to understand than any sort of cycle; parallel progressions
isn't even on the table.
float has been the king of inexact types right for a long time. All
ch might be
> surprising to someone who didn't realise they were mixing floats
> and decimals.
Much like Fraction("0.1") != float("0.1") is surprising.
The only way to get rid of surprises around float is to get rid of
float, and that ain't happening.
--
A
es out there, and would they fit
into my system? I've just taken a look at sympy and although it's
clearly an ideal type, it also allows mixing with float and complex,
both producing sympy types. That puts it clearly past float and
complex in the tower.
I have no ideal where Decimal shou
ay of saying we tolerate it
for interactive use, but don't you dare mix them for real programs.
A warning should be regarded as a bug in real programs — unless it's a
transitional measure — so it might as well be an exception. Don't
guess and
mplex works right I don't see a problem with Decimal +
complex raising an exception.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
oes; it also prevents hashing of quiet NaNs, but I
> can't see any good rationale for that.)
a = Decimal('nan')
a != a
They don't follow the behaviour required for being hashable.
float NaN should stop being hashable as well.
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
>> a = Decimal('nan')
>> a != a
>>
>> They don't follow the behaviour required for being hashable.
>
> What's this required behaviour?
It's certainly not obvious without covering every comparison
with comments.
Maybe that's the solution. Signal by default on comparison, but add a
collection of naneq/naneg/etc functions (math module, methods,
whatever) that use a particular quiet mapping, making the whol
og(-1) = log(-1)
IMO, this just shows how ludicrous it is to compare NaNs. No matter
what we do it will imply some insane mathematical consequence implied
and code that will break.
They are, after all, an error passed silently.
Why is it complex can raise an exception when sorted, forcing yo
e NaN object. This is attractive because it is a
> minimal change that provides a little protection for
> simple containers.
> I support either of those options.
What's the flaw in using isnan()?
--
Adam Olsen, aka Rhamphoryncus
__
On Sat, Mar 27, 2010 at 18:27, Robert Kern wrote:
> On 2010-03-27 13:36 , Adam Olsen wrote:
>> What's the flaw in using isnan()?
>
> There are implicit comparisons being done inside list.__contains__() and
> other such methods. They do not, and should not, know about
as NaN has no precision. Extending with
complex numbers instead gives enough precision to show how this can
happen.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
;
Sure, it doesn't give me a warm-fuzzy feeling of knowing why it works,
but we can expect that it magically does. My understanding is that
threading in general is the same way...
Of course that doesn't preclude bugs in the various implementations,
but those trump the standards anyw
hings (not reproducible by you of course).
That said, I do hope we can get 100%, or at least enough nines that we
can increase the timeout significantly.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
tempts to ensure
atomic access to the Handlers data structure. Is the current code
broken, at least on non-x86 platforms?
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 9/8/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Ensuring modifications to that array are atomic would be tricky, but I
> think it would be doable if we use a read-copy-update approach (with
> two alternating signal handler functions). Not sure how to ensure
> there'
d, we'd rather it just check a variable.
Is it possible to set/clear a flag in a sufficiently portable
(reentrant-safe, non-blocking, thread-safe) fashion?
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On 9/11/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > This much would allow a GUI's poll loop to wake up when there is a
> > signal, and give control back to the python main loop, which could
> > then r
ave any way to do it from
an interrupt context..
A possible alternative is to keep a set of flags for every thread, but
that requires the threads poll their variable regularly, and possibly
a wake-up pipe for each thread..
--
Adam Olsen, aka Rhamphoryncus
__
On 9/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > That brings you back to how you access the flags variable.
>
> The existing signal handler sets a flag, doesn't it?
> So it couldn't be any more broken than the current
> implemen
On 9/12/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > My previous mention of using a *single* flag may survive corruption
> > simply because we can tolerate false positives. Signal handlers would
> > writ
On 9/12/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/12/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > My previous mention of using a *single* flag may survive corruption
> > simply because we can tolerate false positives. Signal handlers would
> > writ
efine
your own PosInf/NegInf singletons and PosInfType/NegInfType classes,
giving them the appropriate special methods.
NaN is a bit iffier, but in your case it's sufficient to raise an
exception whenever it would be created.
Consider submitting it to the P
to have
very poor performance for larger lists. My post includes some
timings, demonstrating this.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
the inner code is finished.
This would also let you wrap sys.stdout.write() in a nested event loop
so as to allow print statements to still work while you use have it
set to non-blocking mode, but I could see it argued that using print
statements at all i
tation detail, not
exposed to the interface?
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 2/15/07, Joachim König-Baltes <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> >> I have implemented something like the above, based on greenlets.
> >
> > I assume greenlets would be an internal implementation detail, not
> > exposed to the interface?
>
On 2/15/07, Joachim König-Baltes <[EMAIL PROTECTED]> wrote:
> Adam Olsen schrieb:
> > I don't think we're on the same page then. The way I see it you want
> > a single async IO implementation shared by everything while having a
> > collection of event loo
ut and was
unable to find it. If I had I may not have bothered to update my own
microthreads to use python 2.5 (my proof-of-concept was based on real
threads).
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http:
On 2/25/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Adam,
>
> On Thu, Feb 15, 2007 at 06:17:03AM -0700, Adam Olsen wrote:
> > > E.g. have a wait(events = [], timeout = -1) method would be sufficient
> > > for most cases, where an event would specify
> >
it).
It sounds like we should always copy the exception given to raise, and
that not doing so is an optimization (albeit a commonly hit one).
Not arguing for or against, just making an observation.
On second thought, we could check that the refcount is 1 and avoid
copying in the common case of
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > It sounds like we should always copy the exception given to raise,
>
> I don't like that either, for all the reasons that
> make it infeasible to copy an arbitrary object in a
> genera
t be to optimize all exception instantiation?
Perhaps use slots and a freelist for everything inheriting from
BaseException and not inheriting from other builtin types?
> On 2/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > How plausible would it be to optimize all exception instantiation?
> > Perhaps use slots and a freelist for everything inheriting from
> > BaseException and not inheriting from other builtin
benefit simply by using a default
__init__ rather than a python one. If you need custom attributes but
they're predefined you could subclass the exception and have them as
class attributes. Given that, is there really a need to pre-create
exceptions?
--
Adam Olsen, aka Rhampho
bout the file transfer?
>
> Think of it this way. "Timeout" doesn't mean the whole thing needs to
> be completed in 10 secs. It means that over 10 secs of no activity
> causes it to be aborted.
IOW, It's an idle timeout.
--
Adam Olsen, aka Rhamphoryncus
_
On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > IOW, It's an idle timeout.
>
> That's not in wikipedia. :-)
I know, I checked before posting. ;)
> It's the only timeout that is availa
On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I think calling it "timeout" in the API is fine. The documentation
> > can then clarify that it's an idle timeout, except it only appli
On 3/21/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > super() has always felt strange to me.
>
> When used in __init__? Or in general? If the former, that's because
> it's a unique Python wart to eve
On 3/21/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> > wrote:
> > >See python.org/sf/1683368. I'd like to invite
object.
>
> Since without diamonds, naive "by-name" upcalling works, I assume that
> super() is actually intended to be used with diamonds, so this seems
> relevant.
>
> I hope I've just overlooked something. Writing this email feels very
> strange.
super() has always felt strange to me. Now, with PEP 3102 and the
strict __init__, not so much.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 3/22/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 3/22/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > In general. Too many things could fail without errors, so it wasn't
> > obvious how to use it correctly. None of the articles I've read
> >
ne (perhaps with specialty options rarely used). It was not
in reference to my previous argument against positional arguments.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
items = 'acabbacba'
>>> counts = countunique(items)
>>> for item in 'abcd':
... print item, counts[item]
...
a 4
b 3
c 2
d 0
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 30-Apr-2007
> Python-Version: 2.6
> Post-History:
You need a section on alternate proposals.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
P
on every incref/decref. Deletion must be
delayed. This lets you share (thread-safe) objects.
B) Don't share *any* objects. This is a process model (even if
they're lightweight like erlang). For the near future, it's much
easier to do this
On 9/13/07, Justin Tulloss <[EMAIL PROTECTED]> wrote:
>
>
> On 9/13/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > Basically though, atomic incref/decref won't work. Once you've got
> > two threads modifying the same location the costs skyrocke
s out refcounts in batches to
reduce contention. The initial cost is much higher, but it scales
better too. I've currently got it to just under 50% cost, meaning two
threads is a slight net gain.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mai
On 9/14/07, Justin Tulloss <[EMAIL PROTECTED]> wrote:
>
> On 9/14/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > Could be worth a try. A first step might be to just implement
> > > the atomic refcounting, and run that single-threaded to see
> > >
t;refcount back to maxint/2. Done.
> >
>
> So, eg, replace the Py_FatalError in none_dealloc with an assignment to
> ob_refcnt? Good point, sounds like it could work (I'm pretty sure you
> know more about deallocation in CPython than I :).
As I've said, this is all moot.
it's hard to decide which one,
> because they both sound too narrow in scope.
>
> I don't like EMError either, btw. Maybe EnvError?
> Although that sounds like it has something to do
> with the unix environment variables.
ExternalError? Pretty vague though.
--
A
#x27;t true at all. It's triggered by heuristics based on the
total number of allocated objects. It doesn't know how much memory is
available and is not called if an allocation fails.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing l
On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > This isn't true at all. It's triggered by heuristics based on the
> > total number of allocated objects.
>
> Hmmm, all right, it seems I don't know what I'm
> talking
omplete implementation of this idea with nothing but a
> > simple decorator. Check it out!
>
> With yet another 10 seconds, I realized my quick implementation actually
> does nothing to optimize tail calls. Working on a fix.
Since they're not going to be accepted into python any
n.org/pipermail/python-dev/2004-July/046150.html
> [2] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/474088
> [3] http://www.voidspace.org.uk/python/weblog/arch_d7_2007_09_22.shtml#e833
> ___
> Python-Dev mailing
On 10/19/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> 2007/10/19, Adam Olsen <[EMAIL PROTECTED]>:
>
> > The solution then is, if your python file will ever be imported, you
> > must write a main function and do all the work there instead. Do not
> > wri
nd creating threads then violates
their safety assumptions.
The solution then is, if your python file will ever be imported, you
must write a main function and do all the work there instead. Do not
write it in the style of a script (with significant work in the global
scope.)
--
Adam Olsen, aka
make sense as a codec. The decoding phase of an XML parser
> has to turn a byte stream into a unicode stream. That's the job of a codec.
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pi
g it
inside a codec seems like the wrong subdivision of responsibility.
(An example using streams would end up closer, but it still seems
wrong to me. Encoding detection is always one way, while codecs are
always two way (even if lossy.))
--
Adam Olsen, aka Rhamphoryncus
_
stream (which may or may not be possible depending on the
> nature of the stream).
io.BufferedReader() standardizes a .peek() API, making it trivial. I
don't see why we couldn't require it.
(As an aside, .peek() will fail to do what det
a command to eval/exec, and doesn't necessarily reflect
your current builtins (which are canonically accessible as an
attribute of your frame.)
[1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html
--
Adam Olsen, aka Rhamphoryncus
_
On Nov 28, 2007 11:50 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Nov 28, 2007 10:46 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Nov 28, 2007 8:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > I'm sending this mail to Python
#x27;ll provide
a plan B: my threading patch[1] will have a dedicated signal handler
thread, allowing them to be processed regardless of one blocked
thread. I'm also providing an interrupt API the gtk bindings could
use to support wakeups, while keeping the poll+fd details private.
[1] http:/
jump completely out of the operation.
This is evil and unportable, but probably works.
Additionally, this only gets SIGINT with the default behaviour to work
right, as it can be entirely implemented in C. If you want to handle
arbitrary signals running arbi
al gets delivered twice if it gets
> > sent quickly twice in a row?
>
> Good point.
Note that we may drop a new signal, not the same one we got several
times. I don't know if Unix will do that. Then again, I've been
unable to find documentation promising it'd deliver any si
nly reason to use C for a low-level handler here is
give access to sigatomic_t and avoid needing locks. If you ran the
signal handler in a background thread (using sigwait to trigger them)
you could use a python handler.
--
Adam Olsen, aka Rhamphoryncus
_
On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > > On 05:20 pm, [EMAIL PROTECTED] wrote:
> > > >The be
On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM
re the pipe is provided by Python code.
>
> I think this is most balanced approach of all.
Yeah, use the existing Handlers array to record which signals have
come in, rather using the byte passed through the pipe.
And I missed a problem in bug #1643738: Handlers[...].tripped should
b
On Dec 8, 2007 6:54 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 5:30 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Hm... Does this mean you're *always* creating
On Dec 10, 2007 4:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Adam & I are now on #python-dev. Can you join?
>
> I think we successfully resolved this. Adam Olsen will produce a patch
> that allows one to specify a single file descriptor to which a zero
> b
g
> significant improvements in laptop power consumption as a result of that work.
There's a known issues page on there, on the bottom of which is
sealert, which used python, gtk, and threads. It has since been
rewritten to not use threads, but it did exhibit the problem
set_wakeup_fd fixes
resented, I'll review them and
> make a decision.
I can't speak for the others, but I know I've decided not to pursue it.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
al and not a bug
>works for me - bug could not be replicated from bug report
>out of date - bug is already fixed in later Python version
>wont fix - valid bug, but not fixable in CPython (very rare)
>
># Common resolutions
> duplicate - same as ano
roposed title for
> that reason.
Such a division would make it unnecessarily hard to find documentation
on True, False, None, etc. They've become keywords for pragmatic
purposes (to prevent accidental modification), not because we think
they ideally s
On Tue, Mar 4, 2008 at 5:04 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Adam Olsen wrote:
> >> Such a division would make it unnecessarily hard to find documentation
> >> on True, False, None, etc. They've become keywords fo
On Tue, Mar 4, 2008 at 8:03 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Adam Olsen writes:
> > On Tue, Mar 4, 2008 at 3:13 PM, Stephen J. Turnbull <[EMAIL PROTECTED]>
> wrote:
>
> > > I would like to see the clear division between the language (i
the 'self', but still compute its hash from the hash of
> 'self'...)
They should only compare equal if interchangeable. In the case of a
mutable container (ie list), a value comparison of self is irrelevant
garbage, so it should always be compare
t;x.append" is interchangeable with "x.append" even if
> "x.append is not x.append", so let's go for the least surprizing
> behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func".
> Objection?
+1
--
Adam Olsen, aka Rhamphoryncus
___
on't think the languages
needs to guarantee any particular performance, yet it's worth
documenting that CPython has a rather good implementation.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
efit but without as much performance hit.
If it works, but is still too much hit, try tuning the checkinterval
to see if you can find an acceptable throughput/responsiveness
balance.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Pytho
On Wed, Mar 19, 2008 at 10:09 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>
> > Can you try with a call to sched_yield(), rather than nanosleep()? It
> > should have the same benefit but without as much performance hit.
> >
&
On Wed, Mar 19, 2008 at 10:42 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
>
> On Mar 19, 2008 05:24 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 19, 2008 at 10:09 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> > > Adam Olsen gmail.com> wr
On Wed, Mar 19, 2008 at 11:25 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>
>
> > So you want responsiveness when idle but throughput when busy?
>
> Exactly ;)
>
>
> > Are those calculations primarily python code, or do
ent-driven. Worse,
we'd likely to be stuck maintaining both APIs for a long time, if not
forever.
Twisted may be one of the best (if not *the* best) ways of writing
concurrent programs today, but it doesn't need to be in the stdlib for
that. If safethread is go
On Mon, Mar 24, 2008 at 3:37 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 24, 2008 at 10:21 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > Twisted may be one of the best (if not *the* best) ways of writing
> > concurrent programs today, but
stage, it doctest passes
it to the compiler again, and it defaults to iso-8859-1. Thus
u'あ'.encode('utf-8').decode('latin-1') -> u'\xe3\x81\x82'.
Possible solutions:
1. Make the docstring itself unicode, assuming doctest allows this.
2. Call doctest exp
... more code ...") completely breaks generators since we might
> potentially be blowing away "yield" statements during the elimination
> process.
Also breaks various sanity checks relating to the global statement.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Thu, May 8, 2008 at 5:54 PM, Thomas Lee <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>>
>> On Thu, May 8, 2008 at 5:22 PM, Thomas Lee <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Nick Coghlan wrote:
>>>
>>>>
>>>> T
r full collection a few times.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
1 - 100 of 230 matches
Mail list logo
