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
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
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
__
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
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
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?
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.
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
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
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
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
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
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
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
__
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
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
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
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
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
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
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
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'
help if the file repr gave the encoding:
>>> f = open('/dev/null')
>>> f
>>> import sys
>>> sys.stdout
Of course I can check .encoding manually, but it needs to be more intuitive.
--
Adam Olsen, aka Rhamphoryncus
n the file will be
>> closed; its up to the GC implementation details. Good code should never
>> depend on the GC for a timely release of scarce external resources (file
>> descriptors/handles).
>
> And buffer flushing. While I don't want to guarantee that the bu
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg wrote:
> On 2009-01-02 08:26, Adam Olsen wrote:
>> Python's malloc wrappers are pretty messy. Of your examples, only
>> unicode->str isn't obvious what the result is, as the rest are local
>> to that function. Even
On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
wrote:
> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen wrote:
> ..
>>
>> As C++ has more specific ways of allocating memory, they impose this
>> restriction to annoy you into using them.
>
> And so does
d a few standard modules.
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy you into using them. We won't be using them, and
the extra casts and nothing but noise. Figure out a way to turn off
the warnings instead.
http://www.research.att.com/~bs/b
deas
> on how to systematically find types which are defined in the core, but
> are missing an explicit PyType_Ready call? (I guess one way would be to
> remove all the implicit calls in a local build and see what blows up...
> that seems a little drastic though)
What I did with safethread w
That might mean that there are a lot of passes through
> this loop per free (i.e., that gdb is taking a long time to process
> 100,000 silent breaks), or perhaps I've made a mistake, or gdb isn't
> handling this well.
To make sure that's the correct
confident that there
> are no loops in this dict, and nothing for cyclic gc to collect.
Try putting an explicit gc.collect() at the end, with the usual
timestamps before and after.
After that try deleting your dict, then calling gc.collect(), with
timesta
On Fri, Dec 12, 2008 at 9:47 PM, André Malo wrote:
> * Adam Olsen wrote:
>> On Fri, Dec 12, 2008 at 2:11 AM, André Malo wrote:
>> > * Adam Olsen wrote:
>> >> UTF-8 in percent encodings is becoming a defacto standard. Otherwise
>> >> the browser has to
On Fri, Dec 12, 2008 at 2:11 AM, André Malo wrote:
> * Adam Olsen wrote:
>
>> UTF-8 in percent encodings is becoming a defacto standard. Otherwise
>> the browser has to display the percent escapes in the address bar,
>> rather than the intended text.
>
> Duh! The
On Fri, Dec 12, 2008 at 1:31 AM, Ulrich Eckhardt
wrote:
> On Thursday 11 December 2008, Adam Olsen wrote:
>> The simplest solution there is to have windows bytes APIs that return
>> raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
>> unicode, despite being
On Fri, Dec 12, 2008 at 12:33 AM, Toshio Kuratomi wrote:
> Adam Olsen wrote:
>> As a data point, firefox (when pointed at my home dir) DOES skip over
>> garbage files.
>>
>>
> That's not true. However, it looks like Firefox is actually broken.
> Take a l
On Thu, Dec 11, 2008 at 11:25 PM, Curt Hagenlocher wrote:
> On Thu, Dec 11, 2008 at 10:19 PM, Adam Olsen wrote:
>>
>> I doubt that UTF-16 is used very much (other than on windows).
>
> There's this other obscure platform called "Java"... ;)
Sorry,
On Thu, Dec 11, 2008 at 10:22 PM, Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
> wrote:
>> Unfortunately, even programmers experienced in I18N like Martin, and
>> those with intuition-that-has-the-force-of-law like Guido,
>> express deliberate
On Thu, Dec 11, 2008 at 10:41 PM, Toshio Kuratomi wrote:
> Adam Olsen wrote:
>> On Thu, Dec 11, 2008 at 6:55 PM, Stephen J. Turnbull
>> wrote:
>>> Unfortunately, even programmers experienced in I18N like Martin, and
>>> those with intuition-that-has-the-for
ase, as a user, if your app is creating new files, do NOT use
bytes! You have no excuse for creating garbage, and garbage doesn't
help the user any. Getting the encoding right, use the unicode APIs,
and don't pass the buck on to everything else.
The fact that the unicode is easier is a bo
hile printing the first.
Just think about how indirect refcounting bugs tend to be. Another
example is messing up GIL handling. There's heaps of things for which
we'd want good stack traces, which can't be done from Python.
--
Adam Olsen, aka Rhamphoryncus
___
bytes APIs that return
raw UTF-16 bytes (note that windows does NOT guaranteed to be valid
unicode, despite being much more likely than on linux). The only real
issue I see is that UTF-16 isn't an ASCII superset, so it won't print
nicely.
In other words, bytes can be your
in R.
>
> It may, however, be better to move further discussion to the tracker
> (I understand that the patch is at
> <http://bugs.python.org/issue3999>).
--
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
ns like
> those, recovering would be likely (caveat emptor of course).
The only safe option there is a subprocess.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
use it on certain supported platforms,
and probably disable it by default anyway (configure option? Not
sure). Still, it'd be useful to have it there.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http:
On Wed, Dec 10, 2008 at 3:39 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> On Tuesday 09 December 2008, Adam Olsen wrote:
>> The only thing separating this from a bikeshed discussion is that a
>> bikeshed has many equally good solutions, while we have no good
>> solut
s that may be used with 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
On Tue, Dec 9, 2008 at 11:31 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> On Monday 08 December 2008, Adam Olsen wrote:
>> At this point someone suggests we have a type that can store an
>> arbitrary mix of unicode and bytes, so the undecodable portions stay
>>
On Mon, Dec 8, 2008 at 2:44 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-12-08 22:32, Adam Olsen wrote:
>> On Mon, Dec 8, 2008 at 2:01 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> On 2008-12-08 21:45, Antoine Pitrou wrote:
>>>> M.-
oes it crash. Seems like the
>> best compromise with the broken nature of the real world IT
>> environment.
>
> OK, I can live with that too.
+1
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://
x27;)? I'm +1 on making that work.
> * a warning error handler that replaces the problem cases with
> a question mark and issues a warning through the warning
> framework
I dub thee errors='warnreplace'.
--
Adam Olsen, aka Rhamphoryncus
e a type that can store an
arbitrary mix of unicode and bytes, so the undecodable portions stay
in their original form. :P
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Sun, Dec 7, 2008 at 11:04 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 12/7/2008 9:11 PM, came the following characters from the
> keyboard of Adam Olsen:
>> On Sun, Dec 7, 2008 at 9:45 PM, Glenn Linderman <[EMAIL PROTECTED]>
>> wrote:
>
checked it in UTF-8, then passed
it to python. It would be nice if the library validated too, but a
major advantage of UTF-8 is older libraries (or protocols!) intended
for ASCII need only be 8-bit clean to be repurposed for UTF-8. Their
security checks continue to work, so long as nobody down
On Sun, Dec 7, 2008 at 11:18 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 11:35, Adam Olsen <[EMAIL PROTECTED]> wrote:
>>>> http://bugs.python.org/issue3672
>>>> http://bugs.python.org/issue3297
>>
>> No. Unicode *requ
8 for the binary API would not be the place to enforce it.
No. Unicode *requires* them to be treated as errors. If you want to
pass them through then you're creating a custom encoding... which you
might argue for in this case, but it needs to be clearly separate from
the real UTF-8.
--
Ad
gs.python.org/issue3672
http://bugs.python.org/issue3297
--
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
ing UTF-8, since that should be able to encode
> anything the Unicode APIs can handle.
If the Unicode APIs only have correct unicode, sure. If not you'll
get errors translating to UTF-8 (and the byte APIs are supposed to
pass bad names through unaltered.) Kinda ironic, no?
--
Adam Ols
ter is a
bikeshed.
Not only that, but we already have a solution that makes the choice
explicit, avoiding the subtle failure. This is the solution already
in use for os file & path functions. It's the solution Guido
supports.
--
Adam Olsen, aka Rhamphoryncus
ers on various Unix systems except OSX (which uses UTF8 for
> its filesystems), and perhaps the occasional developer on OSX whose
> app needs to work with files on mounted filesystems that use a
> different encoding.
--
Adam Olsen, aka Rhamphoryncus
_
;s not valid. So, it works fine as an escape character. It can
> round-trip perfectly.
The failure is more subtle, in that a path from the filesystem cannot
round trip via a different return path. i.e. list the dir via python,
pass it to an external lib
n't happen very often in practice, as having
only one encoding makes it quite clear that it's a broken file name,
not a mixed encoding environment.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
nd trip correctly at some point or
another. They're simply about shuffling the failure around to
somewhere the poster happens to like.
Please, if you have a *new* idea that doesn't have a failure mode, by
all means post it. But don't resurrect a pointless bikeshed.
--
Adam Olsen
On Thu, Dec 4, 2008 at 3:47 PM, André Malo <[EMAIL PROTECTED]> wrote:
> * Adam Olsen wrote:
>
>> On Thu, Dec 4, 2008 at 2:09 PM, André Malo <[EMAIL PROTECTED]> wrote:
>
>> > Here's an example which will become popular soon, I guess: CGI scripts
>> &g
greed solution, but it wasn't considered a common
> enough issue to delay the release of 3.0 until all of those parallel
> APIs had been implemented
Aye. IMO it's fairly clear that os.getenv()/os.putenv() should follow
suit in 3.1. I'm not so sure about adding os.env
On Thu, Dec 4, 2008 at 2:09 PM, André Malo <[EMAIL PROTECTED]> wrote:
> * Adam Olsen wrote:
>> On Thu, Dec 4, 2008 at 1:02 PM, Toshio Kuratomi <[EMAIL PROTECTED]>
> wrote:
>> > I opened up bug http://bugs.python.org/issue4006 a while ago and it was
>> > s
f controlling the environment given to a subprocess
requires os.environb, but it may be too obscure to really matter.
--
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
er all classes that might appear them.
> Showing the class name would solve this problem and could save a lot
> of time.
I'm sure you'll get support for this, unless it's a really
inconvenient spot that requires a gross hack to print the type name.
Post a patch on the bug tr
ethod?
>
> Both are awkward on numeric types in python, necessitating brackets or a
> space before the dot:
>
> (1).__doc__
> 1 .__doc__
It's only awkward on constants, which should be pretty rare for a
numbits property. The expected u
ouldn't have the option of doing that. I'd be disappointed
> if that meant I could no longer use Python for these kinds of
> games.
I consider realtime games to be an essential use case and will be
pursuing incremental GC with my experiments.
--
Adam Olsen, aka Rhamphoryncus
___
run under Jython or IronPython everyone once in a while.
I've considered making files issue a warning if they've got buffered
writes and they're not explicitly closed. Although my feeling is a
read-only file should produce the same warning, there's sit
askfibreropebobprocess is a little
too long for normal use, so I'm gonna keep calling it thread (and to
distinguish it from an OS process).
--
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 Fri, Oct 31, 2008 at 2:11 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>> Neil Schemenauer wrote:
>>>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> w
r non-core code is invoked.
Ahh, or do it per object! Convert the core to use a precise GC
references, but retain the refcount API as a sort of forced unknown
reference. Needs bodging to retain our current handling of cycles in
refcounted objects, but it
To clarify: This is *NOT* actually a form of threading, is it? It
"merely" breaks the giant dispatch table into a series of small ones,
while also grouping instructions into larger superinstructions? OS
threads are not touched at any point?
--
A
file name already using those PUA?
Looks like they get passed through untouched when decoded, but will
get translated into invalid names upon encoding. So you still have
file names you can't open, and you're incompatible with what other
libraries do.
The only thing going for Qt is that they
ut this way you don't shoot them in the
>> foot to do it.
>
> Wouldn't that require changes to the old pages?
Hopefully just to whatever common templating they're using. I'm not
familiar with how they're generated though.
--
Adam Olsen, aka Rhamphoryncus
__
hon.org/3.0/
>
> We already have archived versioned docs at http://www.python.org/doc/X.Y.
Why not use versioned URLs, but with a link at the top of old pages
saying they're outdated, linking to the new version. Either way they
should update their li
actually leads to another problem: improving
validating will change what gets escaped and what doesn't.
http://bugs.python.org/issue3297
http://bugs.python.org/issue3672
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
em of how to turn it on. I'm against
automatically Python changing the filesystem encoding, no matter how
well intentioned. Better to let the app do that, which is easy and
could be done for all apps (not just python!) if someone defined a
libc encoding of "null-escaped UTF-8".
O
On Tue, Sep 30, 2008 at 5:24 AM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Adam Olsen writes:
>
> > [1] You could argue that Unicode should add new scalars to handle all
> > currently invalid UTF-8 sequences.
>
> AFAIK there are about 2^31 of these, thou
into some
other valid unicode string. However, as that string is already valid,
you've just made any files named after it impossible to open. If you
extend unicode then you're unable to display that extended name[1].
I think Guido's right on this one. If I have to choose betw
it lossy
decode for printing, while still keeping the internal file name as
bytes.
Failing outright does have the advantage that the resulting exception
should have a half-decent approximation of the bad filename. (Thanks
to the recent choices on unicode repr() and having stderr do escapes.)
just moves around what gets treated as garbage. As
all valid unicode scalars can be round tripped, there's no way to
create a valid unicode file name without being lossy. The alternative
is not be valid unicode, but since we can't use such objects with
external libs,
filesystem encoding to be Latin-1" approach has a certain
> charm as well, but clearly would be a mistake on OSX, and probably on
> other systems too (whenever the user doesn't think in Latin-1).
Aye, it's a better hack than UTF-8b, but adding byte functions is even bet
in Python2 it was:
> * os.getcwd() -> str (bytes)
> * os.getcwdu() -> unicode
Why not do:
* os.getcwd() -> unicode
* posix.getcwdb() -> bytes
os gets the standard version and posix has an (unambiguously named)
platform-specific version.
--
Adam Olsen, aka Rha
hould expect weakrefs to be cleared at random
points, and code defensively.
One approach I've used before is to enqueue all the cleared weakrefs,
then process that queue when the WeakKeyDictionary is modified.
--
Adam Olsen, aka Rhamphoryncus
___
Pyth
silenced so as to not risk breaking backwards-compatibility?
Just silence them. The warnings are an aid for finding bugs, not an
excuse to create more bugs.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
fix it". The stdlib is definitely broken if it raises
> warnings of that kind.
Is the stdlib broken or is it the warnings that are broken? The code
is just fine in 2.6. Adding pragmas to disable warnings would be just
fine. Or we could hardcode some warnings as "already seen".
On Thu, Jul 3, 2008 at 4:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 3, 2008 at 3:00 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Thu, Jul 3, 2008 at 3:01 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>>
>>> The premise is the OP
builds as a matter of purity even though
> on it would be time-costly on 16-bit builds as a matter of practicality.
Wrong term - code units and code points are equivalent in UTF-16 and
UTF-32. What you're looking for is unicode scalar values.
--
Adam Olsen, aka Rhamphoryncus
_
On Thu, Jul 3, 2008 at 11:35 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080703 19:21], Adam Olsen ([EMAIL PROTECTED]) wrote:
>>On Thu, Jul 3, 2008 at 7:57 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>> Please remember that lone surrogate
y
> valid Unicode code points, nevertheless. Just as a lone combining
> code point is valid on its own.
That is a big part of these problems. For all practical purposes, a
surrogate is like a UTF-8 code unit, and must be handled the same way,
so why th
bage collection.
>
> Also, why would you want to move deleted objects anywhere? Their
> storage is reclaimed, and they don't occur in any list of objects.
Sorry, really poor wording on my part. I meant to move the
*counters*, so that even the first generation qualifies as a
"surv
t is an intriguing thought nevertheless. The module clearing
> causes nothing but trouble...
Already gone in python-safethread. Then again, so is __del__. ;)
(Replaced with __finalize__)
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
> while 1:
> x=[]
>
> trigger a full garbage collection fairly quickly?
"deleted" means deallocated survivors.
I could imagine wanting to move survivors and deleted up to the first
generation, to give a stronger guarantee of how often it'd run, but
that'd require a mu
;d probably don't want the full
collection pauses except from big bursts, which is trivially done by
making the deleted factor 0.0. My original proposal was assuming a
non-zero deleted factor, while yours (and the existing codebase)
assumed it'd be zero - this is how our two proposals
On Sat, Jun 28, 2008 at 12:47 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>>
>> We need two counters: one is the total number of traceable objects
>> (those we would inspect if we did a full collection) and a number of
>> &qu
t getting traced. We could also tweak when in the object
life-cycle "pending" is increased.
The first two generations would remain as they are today.
--
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
rt: the gc is tuned for typical usage. If your usage of python
> is specific,
> use gc.set_threshold and increase its values.
For very large bursts of allocation, tuning is no different from
disabling it outright, and disabling is simpler/more reliable.
--
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, Jun 19, 2008 at 3:23 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti
>> <[EMAIL PROTECTED]> wrote:
>>> Would a
inding real use cases and
exploring how best to solve them. Otherwise we might as well throw in
my OrderedSet[1] as-is, despite that it's got no comments and no
ratings. Even I don't seem to use it.
Everybody has an opinion on the colour of this bike
1 - 100 of 230 matches
Mail list logo
