Guido van Rossum wrote:
> It's quite tricky to implement a fully
> transparent wrapper that supports all the special
> methods (__setitem__ etc.).
I was thinking the wrapper would only be a means of
filling the dict -- it wouldn't even pretend to
implement the full dict interface. The only metho
Stephen J. Turnbull wrote:
> What I advocate for Python is to require that the standard base64
> codec be defined only on bytes, and always produce bytes.
I don't understand that. It seems quite clear to me that
base64 encoding (in the general sense of encoding, not the
unicode sense) takes binar
Bengt Richter wrote:
> you could write
>
> d = dict()**list
Or alternatively,
ld = dict[list]
i.e. "a dict of lists". In the maximally twisted
form of this idea, the result wouldn't be a dict
but a new *type* of dict, which you would then
instantiate:
d = ld(your_favourite_args_here
Josiah Carlson wrote:
> Introducing these two new keywords is equivalent to
> encouraging nested scope use. Right now nested scope
> use is "limited" or "fraught with gotchas".
What you seem to be saying here is: Nested scope use
is Inherently Bad. Therefore we will keep them Limited
and Fraugh
Josiah Carlson wrote:
> Mechanisms which rely on manipulating variables within closures or
> nested scopes to function properly can be elegant, but I've not yet seen
> one that *really* is.
It seems a bit inconsistent to say on the one hand
that direct assignment to a name in an outer scope
is no
Jeremy Hylton wrote:
> The names of naming statements are quite hard to get right, I fear.
My vote goes for 'outer'.
And if this gets accepted, remove 'global' in 3.0.
--
Greg Ewing, Computer Science Dept, +--+
University of Cante
encoding step explicitly very often.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morn
Georg Brandl wrote:
> But why is that better than
>
> class namespace(object): pass
>
> def my_func():
> foo = namespace()
> (...)
Because then it would be extremely difficult for CPython to
optimise accesses to foo into local variable lookups.
--
Greg Ewing,
Alex Martelli wrote:
> If we call the type autodict, then having the factory attribute named
> autofactory seems to fit.
Or just 'factory', since it's the only kind of factory
the object is going to have.
--
Greg Ewing,
e_in_space notation.
>
> Isn't this suggestion that same as Greg Ewing's?
It's not quite the same, because in my scheme the namespace
statement creates a new namespace embedded in the scope
where it appears, whereas Bengt's one seems to just give
a name to the scope its
nk your design so that you don't
have to make that kind of distinction.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.)
Terry Reedy wrote:
> There were perhaps 10
> different proposals, including, I believe, 'outer'. Guido rejected them
> all as having costs greater than the benefits.
As far as I remember, Guido wasn't particularly opposed
to the idea, but the discussion fizzled out after having
failed to reach
Phillip J. Eby wrote:
>def incrementer(val):
>def inc():
>.val += 1
>return .val
>return inc
-1, too obscure.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
Mark Russell wrote:
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage the use of closures.
Well, anything that facilitates rebinding in outer scopes
is going to encourage the use of closures, so I can't
see that as being a reason to reject a parti
Just van Rossum wrote:
> Btw, PJE's "crazy" idea (.name, to rebind an outer name) was proposed
> before, but Guido wanted to reserve .name for a (Pascal-like) 'with'
> statement. Hmm,
I guess that doesn't apply any more, since we've already
used "with" for something else.
Regardless, names with
Raymond Hettinger wrote:
> Like "autodict" could mean anything.
Everything is meaningless until you know something
about it. If you'd never seen Python before,
would you know what 'dict' meant?
If I were seeing "defaultdict" for the first time,
I would need to look up the docs before I was
confi
Josiah Carlson wrote:
> In this particular example, there is no net reduction in line use. The
> execution speed of your algorithm would be reduced due to function
> calling overhead.
If there were more uses of the function, the line count
reduction would be greater.
In any case, line count and
Steve Holden wrote:
> Given that the default entries behind the non-existent keys don't
> actually exist, something like "virtual_dict" might be appropriate.
No, that would suggest to me something like
a wrapper object that delegates most of the
mapping protocol to something else. That's
even le
Fuzzyman wrote:
> cfg = ConfigObj(newfilename)
> cfg['key'] = 'value'
> cfg['key2'] = ['value1', 'value2', 'value3']
> cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenience, then I'd be inclined to require a
Stephen J. Turnbull wrote:
> Base64 is a (family of) wire protocol(s). It's not clear to me that
> it makes sense to say that the alphabets used by "baseNN" encodings
> are composed of characters,
Take a look at
http://en.wikipedia.org/wiki/Base64
where it says
...base64 is a binary to
Raymond Hettinger wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous.
I second all that. A clear case of YAGNI.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
must have thought at the time
that it was worth providing an alternative way.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning
hey manage to get into Google's
database if they're auto-generated. Anyone have any clues
what goes on?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
>
>>Efficiency is an implementation concern.
>
> It is also a user concern, especially if inefficiency overruns memory
> limits.
Sure, but what I mean is that it's better to find w
ds throught the scope hierarchy.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.)
Ron Adam wrote:
> While I prefer constructors with an explicit encode argument, and use a
> recode() method for 'like to like' coding. Then the whole encode/decode
> confusion goes away.
I'd be happy with that, too.
--
Greg Ewin
Steven Bethard wrote:
> Phillip J. Eby wrote:
>
>>Actually, "import .foo" is an abbreviation for "import myparent.foo", not
>>"import myparent.myself.foo".
Oops, sorry, you're right.
s/myself/myparent/g
--
Greg Ewing, Computer Science Dept
ng, because you'd first have to undo the default
encoding and then re-encode it using the one you wanted.
It may be reasonable to provide an easy way to go straight
from raw bytes to ascii-encoded-base64 bytes, but that should
be a different codec. The plain base64 codec should produce
to be a dubious
practice readability-wise, and I can't remember ever
using it. There are other ways of getting the same
effect, e.g. assigning it to another variable before
breaking out of the loop, or putting the loop in a
function and using return.
--
Greg Ewing, Computer Science D
than one special method is inherently ambiguous. What do
you do if both are defined? Sure you can come up with
some rule to handle it, but it's better to avoid the
situation in the first place.
--
Greg Ewing, Computer Science Dept, +--+
University of C
ions so far, it seems to me that
'outer' is the least radical and most consistent with
what we already have. How about we bung it in and see
how it goes? We can always yank it out in 3.0 if it
turns out to be a horrid mistake and we get swamped
with a terabyte of
m even with local filesystems, e.g. on MacOSX
where you can have both HFS (case-insensitive) and
Unix (case-sensitive) filesystems mounted.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christch
user-defined classes, where the
presence of a __getitem__ method causes both of these
slots to become populated.
Having two different slots for __getitem__ seems to have
been an ill-considered feature in the first place and
would probably best be removed in 3.0. I wouldn't mind if
these two function
Stephen J. Turnbull wrote:
> Please define "character," and explain how its semantics map to
> Python's unicode objects.
One of the 65 abstract entities referred to in the RFC
and represented in that RFC by certain visual glyphs.
There is a subset of the Unicode code points that
are conventionall
Michael Chermside wrote:
> The next() method of iterators was an interesting
> object lesson. ... Since it was sometimes invoked by name
> and sometimes by special mechanism, the choice was to use the
> unadorned name, but later experience showed that it would have been
> better the other way.
Any
Thomas Wouters wrote:
> __methods__ are methods that should only be
> called 'magically', or by the object itself.
> 'next' has quite a few usecases where it's
> desireable to call it directly
That's why the proposal to replace .next() with
.__next__() comes along with a function next(obj)
whic
Thomas Wouters wrote:
> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
>
>>As an aside, is there any chance that this could be
>>changed in 3.0? I.e. have the for-loop create a new
>>binding for the loop variable on each iteration.
>
> You can't
Stephen J. Turnbull wrote:
> the kind of "text" for which Unicode was designed is normally produced
> and consumed by people, who wll pt up w/ ll knds f nnsns. Base64
> decoders will not put up with the same kinds of nonsense that people
> will.
The Python compiler won't put up with that sort of
Raymond Hettinger wrote:
> Code that
> uses next() is more understandable, friendly, and readable without the
> walls of underscores.
There wouldn't be any walls of underscores, because
y = x.next()
would become
y = next(x)
The only time you would need to write underscores is
when defi
Jeremy Hylton wrote:
> The more practical complaint is that list comprehensions use the same
> namespace as the block that contains them.
> ... but I suspect we're stuck with the
> current behavior for backwards compatibility reasons.
There will be no backwards compatibility in 3.0,
so perhaps
Stephen J. Turnbull wrote:
> The reason that Python source code is text is that the primary
> producers/consumers of Python source code are human beings, not
> compilers
I disagree with "primary" -- I think human and computer
use of source code have equal importance. Because of the
fact that Pyth
Almann T. Goo wrote:
> One of the biggest points of contention to this is of course the
> backwards incompatibility with a new keyword ...
Alternatively, 'global' could be redefined to mean
what we're thinking of for 'outer'. Then there would
be no change in keywordage.
There would be potential
cter
string in some way, taking into account the assumed ascii
encoding of said bytes. My way, you just use the result
directly, with no coding involved at all.
--
Greg Ewing, Computer Science Dept, +--+
Universit
Alex Martelli wrote:
> We stole list comprehensions and genexps from Haskell
The idea predates Haskell, I think. I first saw it in
Miranda, and it may have come from something even
earlier -- SETL, maybe?
Greg
___
Python-Dev mailing list
Python-Dev@py
Stephen J. Turnbull wrote:
> Greg> I'd be perfectly happy with ascii characters, but in Py3k,
> Greg> the most natural place to keep ascii characters will be in
> Greg> character strings, not byte arrays.
>
> Natural != practical.
That seems to be another thing we disagree about --
t
Nick Coghlan wrote:
> I wouldn't mind seeing one of the early ideas from PEP 340 being resurrected
> some day, such that the signature for the special method was "__next__(self,
> input)" and for the builtin "next(iterator, input=None)"
Aren't we getting an argument to next() anyway?
Or was tha
Bill Janssen wrote:
> I use it quite a bit for image processing (converting to and from the
> "data:" URL form), and various checksum applications (converting SHA
> into a string).
Aha! We have a customer!
For those cases, would you find it more convenient
for the result to be text or bytes in P
Jason Orendorff wrote:
> I like these promises:
> - bytes(arg) works like array.array('b', arg)
> - bytes(arg1, arg2) works like bytes(arg1.encode(arg2))
+1. That's exactly how I think it should work, too.
> I dislike these promises:
> - bytes(s, [ignored]), where s is a str, works like ar
Fredrik Lundh wrote:
> moving to (basic) C++ might also be a good idea (in 3.0, perhaps). is any-
> one still stuck with pure C89 these days ?
Some of us actually *prefer* working with plain C
when we have a choice, and don't consider ourselves
"stuck" with it.
My personal goal in life right no
his was the backwards compatibility
> problems at the C level.
I'm really quite happy either way. Having the
functionality available in some way is the important
thing.
I'd still like to see next(x) / x.__next__() in
some form in 3.0 for the sake of
Bill Janssen wrote:
> bytes -> base64 -> text
> text -> de-base64 -> bytes
It's nice to hear I'm not out of step with
the entire world on this. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
Fredrik Lundh wrote:
> > My personal goal in life right now is to stay as
> > far away from C++ as I can get.
>
> so what C compiler are you using ?
Gcc, mostly. I don't mind if it's capable of
compiling C++, as long as I can choose not to
write any.
--
Greg
Bill Janssen wrote:
> Well, I can certainly understand the bytes->base64->bytes side of
> thing too. The "text" produced is specified as using "a 65-character
> subset of US-ASCII", so that's really bytes.
But it then goes on to say that these same characters
are also a subset of EBCDIC. So it s
Guido van Rossum wrote:
> Recent versions of GCC appear
> to be implementing C98 by default -- at least I didn't get complaints
> about declarations placed after non-declarations in the same block
> from any of the buildbot hosts...
As long as it doesn't complain when I *do* put all
my declaratio
Fredrik Lundh wrote:
> should we perhaps switch to (careful use of) C++ in 3.0 ?
I worry that if the Python core becomes dependent
on C++, it will force all extensions to be written
in C++, too.
Not only is this inconvenient for people who don't
know C++ or prefer not to use it, but I suspect
th
Raymond Hettinger wrote:
> -1 on the silly renaming to __next__ and adding __builtin__.next().
> We have len() because it applies to many different object types.
> In contrast, next() would apply only to iterables.
And you don't think there are many different
types of iterables? You might as well
them to just bytes and characters?
Following that through leads to giving *every*
object .encode() and .decode() methods. I
don't think we should go that far, but it's
hard to see where to draw the line. Are
bytes and strings special enough to justify
them having their own peculiar methods
Bill Janssen wrote:
> No, once it's in a particular encoding it's bytes, no longer text.
The point at issue is whether the characters produced
by base64 are in a particular encoding. According to
my reading of the RFC, they're not.
--
Greg Ewing, Com
it
> might make things clearer over decode and encode.
Another thing is that it only works if the codec
transforms between two different types. If you
have a bytes-to-bytes transformation, for example,
then
b2 = b1.tobytes('some-weird-encoding
Raymond Hettinger wrote:
> [Greg Ewing]
>
> > And you don't think there are many different
> > types of iterables?
>
> Um, I meant iterators and suspect you meant the same --
The same comment applies either way. Each type of iterable
usually has its own correspondi
Baptiste Carvello wrote:
> while manipulating binary data will happen mostly with bytes objects, some
> operations are better done with ints, like the bit manipulations with the
> &|~^
> operators.
Why not just support bitwise operations directly
on the bytes object?
--
Greg
seq, sep):
if hasattr(sep, '__join__'):
return sep.__join__(seq)
else:
# generic implementation
Then you could get nice fast type-specific implementations
for strings, bytes, etc., without being limited to those
types.
--
Greg Ewing, Computer Science Dept, +-
your strings contain piglatin and which don't.
Is this scheme any better than having encode and
decode methods/functions? I'm not sure, but it
shows that a suitably enhanced notion of "data
type" can be used to replace the notions of
encoding and decoding and maybe reduce poten
Ron Adam wrote:
> This uses syntax to determine the direction of encoding. It would be
> easier and clearer to just require two arguments or a tuple.
>
> u = unicode(b, 'encode', 'base64')
> b = bytes(u, 'decode', 'base64')
The point of the exercise was to avoid using the terms
'en
Fredrik Lundh wrote:
> someone also pointed out in private mail (I think; it doesn't seem to
> have made it to this list) that CPython's extensive use of "inheritance
> by aggregation" is invalid C.
>
> switching to C++ would be one way to address that, of course.
A rather heavyweight solution t
Stephen J. Turnbull wrote:
> What you presumably meant was "what would you consider the proper type
> for (P)CDATA?"
No, I mean the whole thing, including all the <...> tags
etc. Like you see when you load an XML file into a text
editor. (BTW, doesn't the fact that you *can* load an
XML file into
Stephen J. Turnbull wrote:
> Doesn't that make base64 non-text by analogy to other "look but don't
> touch" strings like a .gz or vmlinuz?
No, because I can take a piece of base64 encoded data
and use a text editor to manually paste it in with some
other text (e.g. a plain-text (not MIME) mail me
Ron Adam wrote:
> This would apply to codecs that
> could return either bytes or strings, or strings or unicode, or bytes or
> unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return a fixed type that you
t
enough
to find out how much of a disaster this would
have been to use, though. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a mor
7;s enough that you *can* put parentheses around
things if it helps readability.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning pe
at would be
while (next_x() as x) < threshold:
...
i.e. 'x as y' would be an expression.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christ
Oleg Broytmann wrote:
>IDEs. Edit a code in an editor, run python -i script.py, investigate the
> environment, return to the editor, get error message.
An IDE is likely to want to catch SystemExits in the
debugged script and handle them specially anyway.
--
Greg Ewing, Computer S
Steven Elliott wrote:
> One way of handling it is to
> alter STORE_ATTR (op code for assigning to mod.str) to always check to
> see if the key being assigned is one of the default builtins. If it is,
> then the module's indexed array of builtins is assigned to.
As long as you're going to all that
Raymond Hettinger wrote:
> That is going to be difficult as long as it is legal to write:
>
> True = 0
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
Greg
___
Guido van Rossum wrote:
> I don't think we should make any of these keywords.
Not even True and False? The only good reasons
I can see for anyone wanting to shadow these
are backwards compatibility ones.
Greg
___
Python-Dev mailing list
Python-Dev@pyth
Guido van Rossum wrote:
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword.
That wasn't the reason. I was thinking it
would be nice if one could use True and False
instead of 1 and 0 in the knowledge that it
wasn't costing a couple of dictionary lookup
Steven Elliott wrote:
> a pyc file referencing a global in a module may
> have been compiled with a different version of that module (that is
> "some_module.some_global" can't compiled to single fixed index since
> stuff may shift around in "some_module").
Not sure I quite follow that. Since the
Joe Smith wrote:
> LISP was a disaster to use, so I doubt your language would have been any
> worse.
At least Lisp would let you say
(* 4 a c)
and not force you to write
(* (* 4 a) c)
My language would not have been so forgiving,
unless you were willing to define a bunch of
different *
Fredrik Lundh wrote:
> > But I'm wondering if the actual "bugs" list was transmitted to Python
> > developers,
> > and verified / acted upon.
>
> and in case it wasn't clear from my previous post, the answer to
> your specific question is "yes" ;-)
Could whoever did this perhaps post a brief de
Fredrik Lundh wrote:
> return=NULL; output=junk => out of memory
> return=junk; output=-1 => cannot do this
> return=pointer; output=value => did this, returned value bytes
> I agree that the design is a bit questionable;
It sure is. If you get both NULL and -1 returned, how are
you
For Py3k, any thoughts on changing the syntax of
the except clause from
except , :
to
except as :
so that things like
except TypeError, ValueError:
will do what is expected?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
; or "license" for more information.
>>> f = open("DU", "rqwerty")
>>>
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchu
Christos Georgiou wrote:
> Well, what's the result of
>
> bytes([1,0,0])^ bytes([1,0])
>
> ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0])
> (straight conversion to base-256)? Or perhaps throw a ValueError if the
> sizes differ?
In the interests of refusing the temptation
Baptiste Carvello wrote:
> They are not *that* obvious. Logical operations on ints have allowed users to
> forget about size (and shoot themselves in the foot from time to time). Or is
> 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-)
It's about as sane as you can get in a world wh
Russell E. Owen wrote:
> Fundamentally I think what's wanted is:
> - Another level of sub-TOCs, e.g. one for "Sequence Types", "Mapping
> Types", etc. Every page that has sub-topics or intimately related should
> have a list of them at the beginning.
> - The special methods for a given type of c
Baptiste Carvello wrote:
> what about
>
> except with :
>
> a program dies "with" an error message, not "as" an error message.
No. The exception object you're catching *is* the value,
not something which *has* a value. I maintain that "as"
is the correct word to use here.
Greg
__
Georg Brandl wrote:
> I predict people will come and write
>
> except NameError as e, OtherError as f:
Then they'll learn very fast not to write that,
because they'll get a SyntaxError.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Nick Coghlan wrote:
> The former seems fairly pointless, and the latter difficult (since it has
> implications for moving the data store when the array gets resized).
I don't see why that should be a serious problem, as
long as it's understood that the address reported by
the array interface is
Barry Warsaw wrote:
> On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:
>>Unless this new proposal also includes changing the meaning of "except:" to
>>"except Error".
Then maybe it should be called "error:" rather
than "except:". :-)
Greg
___
P
Barry Warsaw wrote:
> One possible approach is to revert BaseException out of Py2.5,
> re-position KeyboardInterrupt, and add Error as an alias for
> StandardError. Then we can encourage people to start using Error as the
> base classes for their own errors.
Also maybe start issuing warnings whe
Barry Warsaw wrote:
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> | +- ImportError
> | +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)
+42! This is beautifully clear and simple, especially
compared to some of the other except
Nick Coghlan wrote:
> So, as a somewhat novel approach, what about putting the "as" *before* the
> list of exceptions types?
-1. When you're scanning down a series of except
clauses, what you're looking for foremost is the
types of exceptions being caught. The bound name
is of secondary importan
Wolfgang Langner wrote:
> try:
> something
> except NameError or OtherError as e:
I don't see that this really helps anything,
since it's no clearer how "or" and "as" should
bind than it is how "," and "as" should bind.
Also it has the disadvantage that
except E1 or E2 as e:
would *not* b
Giovanni Bajo wrote:
> The situation (in Py3k) I was thinking is when people see this code:
>
> except:
> # something
>
> and want to change it so to get a name to the exception object. I *think* many
> could get confused and write:
>
> except Exception, e:
> # something
If except clau
Things are getting a bit confusing, because it seems
that there are two different things being discussed
here:
(1) A C-level array interface that's a generalisation
of the buffer interface.
(2) A new multi-dimensional array object type which
happens to implement (1).
As I understand th
Travis E. Oliphant wrote:
> The purpose of the C-object would be so that all extension writers to
> Python can rely on a simple but general-purpose description of an array
> that Numeric has established over the past decade.
I'm not sure that this is the right direction to approach
things from.
Just van Rossum wrote:
> Greg Ewing wrote:
>
> > Also maybe start issuing warnings whenever you inherit
> > directly from Exception.
>
> Ugh. I hate it when it's made (virtually) impossible to write code that
> runs warnings-free on both Python X.Y and X.(Y+1
Giovanni Bajo wrote:
> OTOH, I also understand that people have been told that deriving from
> Exception
> is the right thing to do forever now.
Have we really being telling them to derive *directly*
from Exception, or just that deriving somehow from
Exception will become mandatory?
For the pur
Guido added them because he thought it looked
better that way.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.)
Guido van Rossum wrote:
> respond with a +1
> or -1 on the creation of the python-3000 mailing list.
+1
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Z
2001 - 2100 of 2443 matches
Mail list logo
