> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Jeroen Ruigrok van der Werven wrote:
>> It's just nice to be able to define a single class
>> in multiple modules.
Greg> It *seems* nice until you want to track down which
Greg> source file the definition of some method comes
Greg> from.
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> And I just found out (after everyone else probably :-) that YouTube
Guido> is almost entirely written in Python. (And now I can rub shoulders
Guido> with the developers since they're all Googlers now... :-)
Are any other details
I think there are various good arguments that the current behavior of
splitext isn't optimal. But. these don't feel strong enough to me to
break existing code or to force people who happen to be in the know to go
hunt down and review old code etc. I don't see the point in doing that,
just to fi
Why not offer a Python patching tutorial at the next US/Euro PyCon? It
seems like there's plenty that could be taught. I'd attend. I'd suggest
that that specific tutorial be offered free, or be paid for by sponsors.
Similarly, the first day of the post-PyCon sprints could have a group
learning abo
> "G" == Guido van Rossum <[EMAIL PROTECTED]> writes:
G> There are different philosophies about the correct style for
G> cooperative super calls.
G> The submitter of the bug report likes to remove "consumed" arguments
G> and pass the others on, having something at the root that complains
G> a
Following up to myself, with some examples.
I probably haven't done this as cleanly as is possible, but below are a
bunch of classes and subclasses that cleanly deal with passing around
arguments, even when those args conflict in name, etc., as outlined in my
previous mail.
Here's the general cla
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> I feel left out. I have only one child and I don't qualify as
Guido> 'strange' by any stretch of the imagination... Sometimes I think I'm
Guido> the only regular guy working on Python. ;-)
Ah well, that explains a lot! :-)
Anyo
> "John" == John Barham <[EMAIL PROTECTED]> writes:
>> * import readline or emptymodule
John> This I find more problematic as "emptymodule" seems too magical.
John> Even now any code that wants to use a module that might not have been
John> successfully imported needs to check if that's the c
It might be helpful to consider how people would tackle Guido's problem by
pretending that a regular Joe (i.e., someone who couldn't consider changing
the semantics of Python itself) had asked this question.
I would suggest adding a hook to their version control system to
automatically create (and
I'm about to write some code to manage sets, and wanted to float a few
thoughts here because I have various ideas about how to implement what I
want to do, and I think one of them could be done by changing Python's set
type in useful and backward compatible way.
Apologies if this is discussed in t
A quick followup to my own posting:
I meant to say something about implementing __rand__() and pop(). I'd
either add another optional function argument to the constructor. It would
return a random element from the universe. Then for __rand__() and pop(),
you'd call until it (hopefully!) returned s
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> Hm... Without reading though all this, I expect that you'd be
Guido> better off implementing this for yourself without attempting to pull
Guido> the standard library sets into the picture (especially since sets.py
Guido> is obsol
> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> There's room in the world for alternate implementations of sets,
Raymond> each with its own strengths and weaknesses.
...
Raymond> Alternatve implementations will most likely start-off as
Raymond> third-party extension modul
That doc note should surely be removed. Perhaps it's an artifact from some
earlier shuffle algorithm.
The current algorithm (which is simple, well known, and which produces all
permutations with equal probability) only calls the RNG len(x) - 1 times.
Terry
___
>>>>> "Tim" == Tim Peters <[EMAIL PROTECTED]> writes:
Tim> [Terry Jones]
>> and which produces all permutations with equal probability)
Tim> That needs proof. Assuming a true random number generator, such a
Tim> proof is easy. Using a deterministi
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> A generator with only N possible internal states can't
Greg> possibly result in more than N different outcomes from
Greg> any algorithm that uses its results.
I don't mean to pick nits, but I do find this a bit too general.
Suppose you
>>>>> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Terry Jones wrote:
>> Suppose you have a RNG with a cycle length of 5. There's nothing to stop an
>> algorithm from taking multiple already returned values and combining them
>
>>>>> "Dan" == Dan Christensen <[EMAIL PROTECTED]> writes:
Dan> Greg Ewing <[EMAIL PROTECTED]> writes:
>> Terry Jones wrote:
>>
>>> The code below uses a RNG with period 5, is deterministic, and has one
>>> initial state. It pr
18 matches
Mail list logo
