[M.-A. Lemburg]
> ...
> So far, I haven't heard a single argument for why not having None
> participate in an ordering scheme is a good strategy to use, except
> that it's pure.
I've tracked down plenty of program logic errors that would have been
discovered more easily if comparing None to (mostl
[M.-A. Lemburg]
> ...
> That's fine. I'm just talking about the special case for None that
> has existed in Python for years - and for a good reason.
That's overstating it a bit ;-) In Python 1.5.1, comparisons were
changed so that objects of numeric types compared smaller than objects
of non-num
[Paul Moore]
>>From a quick look, rmpyc.py is deleting .pyc and .pyo files in ..\Lib.
> This could be done (I believe) using simply
>
>cd ..\Lib
>del /S *.pyc *.pyo
>
> I haven't tested this (no time right now) but certainly on XP, the del
> command accepts a /S flag to delete recursively.
[Larry Hastings]
> I see--it's avoiding the Birthday Paradox.
It /tends/ to, yes. This wasn't a design goal of the string hash,
it's just a property observed after it was adopted, and appreciated
much later ;-)
It's much clearer for Python's small-int hash, where hash(i) == i for
i != -1. That
[Guido]
> I'd like Tim Peters's input on this before we change it. I seem to
> recall that there's an aspect of non-randomness to the existing hash
> function that's important when you hash many closely related strings,
> e.g. "0001", "0002", "0003", etc., into a dictionary. Though it's been
> so l
[Neal Norwitz]
> ...
> We have 4 windows buildbots IIRC, but 2 are offline and there are
> various problems. Given all the slight variations of Windows, I
> think it would be good to get another Windows bot.
FYI, my bot is offline now just because I'm having major HW problems
(endless spontaneous
[Tim Peters]
>> ...
>> OTOH, the "open bracket" rule is certainly sufficient by itself, and
>> is invaluable for writing "big" list, tuple, and dict literals (things
>> I doubt come up in Andrew's EFL inspiration).
[Andrew Koenig]
> If comm
...
[Guido]
> I am worried that (as no indent is required on the next line) it will
> accidentally introduce legal interpretations for certain common (?)
> typos, e.g.
>
> x = y+# Used to be y+1, the 1 got dropped
> f(x)
The Icon language also uses this rule, and I never experienced
probl
[Guido]
> Something got lost there in a last-minute edit. I meant to say:
>
> My main interest is that we should move away from just leading zero as
> octal; that we should disallow leading zero altogether because of the
> confusion it would cause for folks coming from other languagesl and
> that w
[Giovanni Bajo]
> Raymond, there is one thing I don't understand in your line of reasoning. You
> say that you prefer explicit finalization, but that implicit finalization
> still
> needs to be supported. And for that, you'd rather drop __del__ and use
> weakrefs. But why? You say that __del__ is
[Fredrik Lundh]
>> (on the other hand, "s[:len(t)] == t" is usually faster than
"s.startswith(t)" for short
>> prefixes,
[Greg Ewing]
> That's surprising. Any idea why this might be?
Perhaps it has to do with the rest of his message ;-):
>> (which reminds me that speeding up handling of optional
[Guido van Rossum]
> At today's sprint, one of the volunteers completed a patch to rip out
> find() and rfind(), replacing all calls with index()/rindex(). But now
> I'm getting cold feet -- is this really a good idea? (It's been listed
> in PEP 3100 for a long time, but I haven't thought about it
[Tim Peters]
>> ...
>> When the ctypes docs talk about passing and returning integers, they
>> never explain what "integers" /means/, but it seems the docs
>> implicitly have a 32-bit-only view of the world here. In reality
>> "integer" seem
[tomer filiba]
>> i mailed this to several people separately, but then i thought it could
>> benefit the entire group:
>>
>> http://sebulba.wikispaces.com/recipe+thread2
>>
>> it's an implementation of the proposed " thread.raise_exc",
>> ...
[Guido]
> Cool. Question: what's the problem with raisi
[Josiah Carlson]
> ...
> Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import ctypes
> >>> import threading
> >>> import time
> >>> def foo():
> ... try:
> ... while 1:
>
[back and forth on PyThreadState_SetAsyncExc(), and
the 2-year old discussion in
http://www.python.org/sf/1069160
]
[Tim]
>> [still-current deadlock & refcount issues not fixed at the time]
[Guido]
> So why didn't we check that in?
The shallow answer is that you closed the report without chec
[back and forth on PyThreadState_SetAsyncExc()]
[Tim]
>> Guido, do you have any idea now what the "number greater than one"
>> business is about?
>> ...
>> My impression has been that it would be an internal logic error if we
>> ever saw this count exceed 1.
[Guido]
> Right, I think that's it. I
[Nick Coghlan]
>> That check is already there:
>>
>> int PyThreadState_SetAsyncExc( long id, PyObject *exc)
>> Asynchronously raise an exception in a thread. The id argument is the
>> thread id of the target thread; exc is the exception object to be
raised. This
>> function does not steal any
[Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?
[Tim Peters]
>> Is it, compared to the other interpreted languages? Doesn't look like it.
[Giovanni]
> Well, it seems like one of the
[Fredrik Johansson]
> The information "n is odd" appears once as "n&1" and once in the name
> of a function. The point is that any if statement has the following
> form:
>
> if conditionX:
> consequence of conditionX
>
> So the if statement *inevitably* references conditionX twice, alth
[Giovanni Bajo]
|> Since we're at it, do you have any idea on why Python is so slow when doing
> such bit-full code?
Is it, compared to the other interpreted languages? Doesn't look like
it. The cost of going around the eval loop once utterly swamps the
cost of doing a bitwise operation on nativ
...
[Raymond Hettinger]
>> I write:
>>
>> if n&1:
>> handle_odd()
>> else:
>> handle_even()
>>
>> IMO, functions like is_even() and is_odd() are clutter. Also, the
>> performance of &1 is unlikely to be matched function calls.
[Fredrik Johansson]
> In your example, the problem is t
[Guido]
> This is way above my head. :-)
Of course it's not, but the issues are subtle and messy enough that
it's a burden to make sufficient time for them. I'm sympathetic to
that ;-)
> The only requirement *I* would like to see is that for floats that
> exactly represent ints (or longs for tha
[Aahz]
> Well, yes, but Uncle Timmy is jumping up and down and screaming for a
> change.
That's a pretty bizarre characterization, if I say so myself. But
since I've already been accused, I may as well live up to it ;-):
> Granted, I think we should show respect for our numerical
> elders, but I
[Andrew Koenig, on the counter intuitive -1e-050 % 2.0 == 2.0 example]
>> I disagree. For any two floating-point numbers a and b, with b != 0, it
>> is always possible to represent the exact value of a mod b as a
>> floating-point number--at least on every floating-point system I have ever
>> enco
[Fredrik]
>>> I don't think anyone on this list can take the "but if there's more than
>>> one argument, *I* am going to be confused" argument seriously.
[Tim]
>> Then you don't remember that the order of arguments here _was_ a
>> frequent confusion in the old days.
[Fredrik]
> nope.
>
> any poin
[Alex Martelli, suggests that a functional join's default
separator be the empty string]
>> Rationale: an emptystring joiner is the most frequent cases, but
>> several others (space, newline, space-comma, ...) occur often enough
>> to be worth allowing the joiner to be optionally specified.
[Barr
[Fredrik Lundh]
> no, because people enjoy writing readable code. doing things by exe-
> cuting methods attached to literals isn't very readable, and isn't used
> for anything else.
As Barry often says, he spells it TAB.join() or BLANK.join() (etc)
instead. That's very readable.
> I don't think
[Barry Warsaw]
>> ...
>> While I hate the way it looks, I never have gotten mixed up about the
>> order of arguments since switching to ''.join(l).
[Tim Hochberg]
> Me too on all counts including the -0.
>> ...
>> But hey, yeah, a join() builtin would be fine if it
>> took the string arg first, s
[Guido]
>>> OTOH mathematicians (whether in high school or not) write things like
>>> {x | 2 < x < 10}, which is of course the origin of our list
>>> comprehensions and generator expressions [...]
[Boris Borcic]
>> Most of the time they use it as "filter" and write something like
>>
>> {x ∈ S st.
[Guido, to Andy Sy]
> ...
> If you want to contribute a pure Python module that implements some
> useful form of futures, you don't have to wait for Python 3.0. But
> before you contribute this to Python 2.6 (it's too late for 2.5), you
> should probably have released it successfully as a separate
[Erno Kuusela]
>> The refcounting vs generational GC reasoning I've heard argues that
>> refcounting is less cache-friendly: The cache line containing the
>> refcount field of the pointed-to objects is dirtied (or at least
>> loaded) every time something is done with the reference,
[Greg Ewing]
>
[Tim Peters]
...
>>That thread should still be required reading for anyone thinking of
>> changing CPython's gc strategy:
>>
>> http://mail.python.org/pipermail/python-list/1999-July/0073.html
[Brian Harring]
> Seem to have missed a few digits in the u
[Greg Ewing]
>> Even if it [mark-sweepish gc] did become available, we might not
>> want to> use it. In recent times I've come round to the view that,
>> on modern architectures where cacheing is all-important,
>> refcounting + cyclic garbage collection may well be
>> *better* than mark-and-sweep o
[Guido]
>> ...
>> I implemented this (it was really simple to do) but then found I had
>> to fix tons of places that iterate over strings.
[Greg Ewing]
> I wonder if the stdlib might be a bit unusual here,
> since it's the place where low-level things are
> implemented. I don't think there would b
[Guido]
>> ...
>> Definitely wild. Reader beware. Now is the time to generate lots of
>> wild ideas and let them sink in. If it still seems a good idea 3
>> months from now we may select it for a code experiment (as opposed to
>> a thought experiment). BTW I want to encourage lots of code
>> experi
[Greg Ewing]
> It's been suggested before that the explicit clearing
> of a module at interpreter shutdown should be replaced
> with just letting cyclic GC do its thing. Is there any
> reason why that wouldn't work? It might lead to less of
> the unintuitive behaviour that sometimes occurs because
[Martin v. Löwis]
> Abstract: Module initialization currently has a few deficiencies.
> There is no cleanup for modules, the entry point name might give
> naming conflicts, the entry functions don't follow the usual
> calling convention, and multiple interpreters are not supported
> well. This PEP
[Tim]
>> ...
>> There's one other common surprise in Zope-land, namely that
>>
>> for key in b.keys():
>> ... possibly try to delete `key` from `b`
>>
>> "doesn't work" when `b` is a BTree. The _expectation_, derived from
>> experience with Python dicts, is that it's bulletproof, but t
[Jim Fulton]
> ...
> I'd be interested to hear if other people who have experience working
> with ZODB BTrees have been as annoyed as I've been.
Not since the first week ;-), no. Two things exacerbate this in ZODB:
- BTrees are a mapping type, but unlike other mapping types its keys()
(etc) me
[Nicola Larosa]
> ... I sometimes may have had a need for the current semantics
> of the else after loops, but I don't remember it; on the other hand, I have
> had a use for the no-iteration case a number of times. Somehow I find it
> hard to stick into my mind that's not what it means.
The primar
[Brett Cannon]
|>> Yes, please! I think for the Py3K codebase we should at least require
>> code meet the style guide. We are all guilty of having ignored it at
>> some point,
I'm not :-)
> ...
[Nick Coghlan]
> I would love it if PEP 3007 standardised on 4-space indents, the same as the
> stan
42 matches
Mail list logo
