> "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
> "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
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
> "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
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
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
> "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
> "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.
>>>>> "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
>>>>> "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
>
> "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
>>>>> "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
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
___
> "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
> "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
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
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
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
18 matches
Mail list logo
