k.
(Not suggesting this for Python, just thought it was interesting.)
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
+1
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
takes one person being careful with their
reply headers to cut out whole sub-trees of duplicate traffic, and
thereby save python.org some valuable bandwidth :)
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/li
Martin v. Löwis wrote:
>> For new code, however, there is an alternative strategy that doesn't
>> involve 2to3 at all, which is to write code in the "greatest common
>> subset" of 2.6 and 3.0.
>>
>> As Lennart Regbro pointed out earlier, this common subset is actually
>> quite large (larger than
g what things to avoid and
how to get around them.
-- That document could include a description of (or for extra credit, an
implementation of) the utility library mentioned earlier, that isolates
the difference between the two Python versions.
Any volunteers?
-- Talin
__
:
(x * x given x)
So for example:
>>> (x * x given x)(2)
4
However, the patch and the general concept were rejected. For myself, I
thought the idea was cute, but not a huge improvement, and I'm not
willing to spend any serious effort
wers is (applying the associative rule):
(x = 1, y = 2 + 3)
(x = 1 + 2, y = 3)
...and so on
Now, one final comment: PEP 342 promises that the new yield semantics
can be used to implement true coroutines. But I don't see how to
actually make that work. Has anyone actually done this?
positional-only was not part of my original 'itch', and I am curious as
to what are the use cases for it that people are envisioning.
> --
> Arnaud
>
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/talin%40acm.org
>
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Raymond Hettinger wrote:
> I've been exercising the new keyword-only arguments syntax. It is absolutely
> wonderful. I'm amazed at how many long standing problems it solves elegantly.
>
> Thanks Talin!
Well, that made my day :)
-- Talin
; Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/talin%40acm.org
>
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Guido van Rossum wrote:
> Thinking through the consequences, and noticing that using the array
> module as an ersatz mutable bytes type is far from ideal, and
> recalling a proposal put forward earlier by Talin, I floated the
> suggestion to have both a mutable and an immutable bytes
===
byteByteSequence bytes buffer
character CharSequence str strbuf
'buffer' could be an array.array, although if it's used frequently
enough an optimized special-case 'buffer' class might be better. And it
can have methods that array does
by name for fear of bringing that thread over here), that
the ultimate solution to Python concurrency won't be via patching
CPython, but to compile the meta-Python language to a back-end
representation that is inherently concurrent.
-- Talin
___
P
description of the Formatter overloaded methods may not match
your latest revisions. Feel free to point out any errors.)
Oh, and thanks to Georg for making it possible for me to actually write
library documentation :)
-- Talin
___
Python-3000 mailing
erested in suggestions as to any other standard types that
ought to have a __format__ method, other than the obvious Date/Time
classes. What kinds of things do people usually want to print?
-- Talin
___
Python-3000 mailing list
Python-3000@pytho
tes conversions with formatting, which the PEP takes
> pains not to do. I'd rather leave them separate, but I'll let Talin
> make the call.
Correct. There's no reason for 'format' to handle conversions, when its
trivial for a caller to do it themselves:
f
Eric Smith wrote:
> Eric Smith wrote:
>> Jim Jewett wrote:
>
>>> but you might want to take inspiration from the "tail" of an
>>> elementtree node, and return the field with the literal next to it as
>>> a single object.
>>>
>>> (literal_text, field_name, format_spec, conversion)
>> I think I
or component.
But I sure would like a completely "Pythonic" GUI that supported all of
the features that I need.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
ort" of Python should consist of the concatenation
of two packages, the universal Python sources, and a set of
platform-specific adapters, which may or may not be hosted on the main
Python site.
However, this just might be wishful thinking on my part...
-- Talin
t;live", so that they would reflect the new value of
> "greeting", even though it was set after the Formatter was created?
>
> -jJ
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman
done*.
I admit that part of this whole syntax discussion was my fault - I did
ask for a bit of a bikeshed discussion and I got way more than I
bargained for :)
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailma
ts put through str as a last resort
> return str(obj).__format__(spec) #last chance before throwing
> exception
The built-in 'format' function doesn't handle '!r', that's done by the
caller. The 'spec' argument passed in to 'format' is
>> Okay, I made the switch. I tagged the state of both Python branches
>> before the switch as tags/py{26,3k}-before-rstdocs/.
>
> http://docs.python.org/dev/
> http://docs.python.org/dev/3.0/
So awesome. Great job everyone!
-- Talin
_
Alex Holkner wrote:
> Talin wrote:
>> A new version is up, incorporating material from the various discussions
>> on this list:
>>
>> http://www.python.org/dev/peps/pep-3101/
>
> I've been following this thread for a few weeks, and I believe th
Eric Smith wrote:
> Talin wrote:
>> Eric Smith wrote:
>>> James Thiele wrote:
>>>> The section on the explicit conversion flag contains the following
>>>> line:
>>>>
>>>> These flags are typically placed before the format sp
Eric Smith wrote:
> James Thiele wrote:
>> The section on the explicit conversion flag contains the following line:
>>
>> These flags are typically placed before the format specifier:
>>
>> Where else can they be placed?
>
> I'd like this to say they can only be placed where the PEP describe
ame is 'out.txt'"
>
> I agree.
>
> Also, the example a couple of paragraphs down:
> "My name is {0[name]}".format(dict(name='Fred'))
> should show the expected output:
> "My name is Fred"
Those examples are kind of contrived to be
A new version is up, incorporating material from the various discussions
on this list:
http://www.python.org/dev/peps/pep-3101/
Diffs are here:
http://svn.python.org/view/peps/trunk/pep-3101.txt?rev=57044&r1=56535&r2=57044
it seems to me that once we have a *real* implementation
(which we will soon), it will be relatively easy for people to
experiment with new features and syntactical innovations.
6) Finally, Guido stressed that he wants to make sure that the
implement
e requirement that the first
> argument be equal to a certain object (e.g. 'r') rather than a
> subtype of it, so I'll just gloss over that issue.
The plan is to eventually use generic functions once we actually have an
implementation of them. That
Eric V. Smith wrote:
> Talin wrote:
>> One final thing I wanted to mention, which Guido reminded me, is that
>> we're getting short on time. This PEP has not yet been officially
>> accepted, and the reason is because of the lack of an implementation.
>> I don&#x
also feels right.
The regex for interpreting this, BTW, is something like the following:
"(?:\:([a-z])?(<|>|\^)?(+|-)?(\d+)(\.\d+))(/.)?(!r)?"
(Although it may make more sense to allow the fill and regex fields to
appear in any order. In other words, any field that is id
ld be. For uncommon cases, where the programmer is
invoking additional options, the format field can be longer, but it
should still be kept concise.
One final thing I wanted to mention, which Guido reminded me, is that
we're getting short on time. This PEP has not yet been officially
acce
s a GF. And there is some validity
to that point. But for historical reasons, we're not likely to change
it. And there's also some validity to the argument that a 'printable'
representation is the one universal converter that deserves special status.
-- Talin
__
Ron Adam wrote:
> Talin wrote:
>> Ron Adam wrote:
>>> Now here's the problem with all of this. As we add the widths back
>>> into the format specifications, we are basically saying the idea of a
>>> separate field width specifier is wrong.
>>>
&
would support the 'buffer protocol',
although in the former case it would be read-only. Other things which
are not buffers could also support this protocol.
6) Library APIs that required a byte sequence would be written to test
vs. the abstract ByteSequence type.
7) Both bytes and b
Martin v. Löwis wrote:
>> The most efficient representation of immutable bytes is quite different
>> from the most efficient representation of mutable bytes.
>
> In what way?
Well, in some runtime environments (I'm not sure about Python), for
immutables you can combine the object header and the
ble bytes is quite different
from the most efficient representation of mutable bytes.
Rather, I think that they should both share a common Abstract Base Class
defining what you can do with immutable byte strings, but the actual
storage of the bytes themselves should be implemented in the subclas
ementing this
stuff is my Python prototype of the original version of the PEP. It has
all the code you need to format floats with decimal precision,
exponents, and so on:
http://www.viridia.org/hg/python/string_format?f=5e4b833ed285;file=StringFormat.py;style=raw
-- Talin
Greg Ewing wrote:
> Talin wrote:
>> in
>> the case of an integer that is printed with leading zeros, the sign must
>> come *before* the padding: '+00010'. It's not sufficient to simply
>> apply padding blindly to the output of __format__, which woul
Ron Adam wrote:
> Talin wrote:
>> Another thing I want to point out is that Guido and I (in a private
>> discussion) have resolved our argument about the role of __format__.
>> Well, not so much *agreed* I guess, more like I capitulated.
>
> Refer to the message in
al precision quantity for any data type except
floats. So ':d10' doesn't mean anything I think, but ':d,10' is minimum
10 digits.
-- I don't have an opinion yet on where the other stuff (sign options,
padding, alignment) should go, except that sign should go next to the
t
want seems to be:
1) High precedence type coercion, i.e. 'r', which bypasses __format__.
2) Check for __format__, and let it interpret the format specifier.
3) Regular type coercion, i.e. 'd', 'f' and so on.
4) Regular formatting based on type.
-- Talin
and its because of Python syntax.
Now, in Python, ':' isn't an operator - but if it was, you would have to
consider its precedence to be very low. Because when we look at an
expression 'if x: a,b' we know that comma binds more tightly than the
colon, and so it's
to be *short*.
So we need to strike a balance between convenience and readability.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
rm the next metaclass in the chain.
There are two obvious problems here: First, we can't dispatch on 'cls'
since it's not been created yet.
Second, the metaclass machinery is deep down inside the interpreter and
operates at the very heart of Python. Which means that in order
else:
# Coerce to float
s = formatFloat(float(value), formatSpec)
else:
s = str(value)
# Now that we have 's', apply the alignment options
return applyA
hought to PEP 3115, to see
> if there is any way to at least emulate the "derived metaclass rule"
> for __prepare__, that Python currently enforces for the base classes.
I would love any improvements to PEP 3115 that you can think of.
-- Talin
__
...
In this case, I have no need to subclass the class, and I'm only doing
dynamic dispatching on the second argument.
So basically what I would propose is that we simply say that we don't
mix normal overloading and multi-method dispatch until PJE comes up with
his better solution
0x, and base64 can't encode a
number larger than 255.
Now, you *could* do both steps in a single function. However, you still
have to choose what the intermediate encoding form is, even if you never
actually see it. Usually this will be UTF-8.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
TextId = FourCharId("TEXT")
i = int(TextId) # Integer value
s = str(TextId) # String representation
some_map[TextId] = "Some Text" # Can use as dict key
The wrapper class is an immutable class that handles conversion to
integer form in the constructor, hashing, and
out excess verbiage.
Comments are welcome as usual.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
le to the calling site, which will typically be
a small fraction of the total source code for an application.
So I hope that explains why overloading regular functions is perceived
by some people to be of a different order than overloading class methods.
-- Talin
___
ocus more on the stuff that's built on top of GFs.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
pen it, but you have to open it first...
All of the popular XML parsers have self-bootstrapping code that handles
detection of the encoding, including auto-detection when no encoding is
specified.
So basically - don't worry about it, it's taken care of.
-- Talin
__
#x27;s a good
gatekeeper in these matters - if he doesn't understand it why it's
important or useful, it probably means that lots of other Python
developers won't either.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http:/
probably have to treat it as a byte array and override the encoding
detection, telling it explicitly to use UTF-16.
> James
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
&g
my Aspect implementation available separately in the
> ObjectRoles cheeseshop package, renaming them Roles instead of Aspects.
>
> (And yes, I will add all the above explanation to the PEP.)
>
>
>> AFAIK Phillip has declared that his implementation only uses (or could
>> be made to only use) isinstance()/issubclass()
and you don't
want that slowness around once your class is finished initializing.
2) A 'dict-like' object doesn't have to support all of the methods of a
real dict, wherease a class dict does. So your dict-like wrapper can be
relatively simple.
-- Talin
__
ngs manually is a PITA, mainly because it's
> so common.
>
> Georg
Actually, I was presuming that '%' would stick around for the time
being, although it might be officially deprecated.
Given that writing a 2to3 converter for format strings would be a
proje
----
>> http://www.boredomandlaziness.org
>>
>
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/talin%40acm.org
>
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
of the PEP, and in others I just write down what I think the
general consensus is.)
That being said - from what I've read so far, the evidence on both sides
of the argument seems anecdotal to me. I'd rather wait and see what more
people have to say on the topic.
-- Talin
Aurélien Cam
Eric V. Smith wrote:
> Talin wrote:
>> Other kinds of customization require replacing a much larger chunk of
>> code. Changing the "underscores" and "check-unused" behavior requires
>> overriding 'vformat', which means replacing the entire tem
Nick Coghlan wrote:
> Talin wrote:
>> What I wanted to avoid in the PEP was having to specify how all of
>> these different parts fit together and the exact nature of the
>> parameters being passed between them.
>>
>> And I think that even if we do break up vfor
n't see why the python-dev community has
to solve all of the world's problems in one go.
I would even go so far as to say that its OK to drop support for any
languages that are "hard to do".
(Note that I've done a fair bit of work supporting Bidi in my previous
job,
rgs)
> > -- vformat(format_string, args, kwargs)
> > -- get_positional(args, index)
> > -- get_named(kwds, name)
> > -- format_field(value, conversion)
>
> I've started a sample implementation to test this API. For starters,
> I'm writing it in pure Python, but my intention is to use the code in
> the pep3101 sandbox once I have some tests written and we're happy
> with the API.
Cool.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
iffs) here:
http://svn.python.org/view/peps/trunk/pep-3101.txt
Please let me know of any errors you find. Thanks.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscr
module for versions earlier than
2.6. My feeling on that is if someone wants to do that, fine, but it
doesn't need to be part of the PEP.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/pytho
an expert in the internals of the Python interpreter C
code, I would ask how feasible is this?
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
ot;))
(You can't do this with locals() because you can't keep the dict around.)
My question to the groupmind out there is: Do you find this extra syntax
too inconvenient and wordy, or does it seem acceptable?
-- Talin
___
Python-3
, simply because as a writer of a subclass I couldn't
rely on being able to use them.
The only alternative that I can see is to not use dynamic inheritance at
all, and instead have the number classes inherit from these ABCs using
the traditional mechanism. B
identifiers? My preference is to be conservative in terms of
what's allowed.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/ar
or it is.
You want to look at the module TurboJSON:
http://docs.turbogears.org/1.0/JsonifyDecorator
http://trac.turbogears.org/browser/projects/TurboJson/trunk/turbojson/jsonify.py?rev=2200
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
nes that don't fit, then sort the remaining ones by specificity.
The problem of course is that I don't know how to build an efficient
dispatch table to do that, and I'm not even sure that it's possible.
-- Talin
___
Python-3000
low the dispatcher to know that the "ShinyRobot" is a
subset of "Worker", even though the two tests are different kinds of tests.
Thus, the generic function dispatcher will need to be able to take two
tests, which might both be ty
elieve 'programming' is
about.
There is another issue to be considered as well: Many human languages
have a different grammatical structure. Even if you were to allow
non-ASCII identifiers, and more so even if you were to allow the
keywords themselves to be loc
3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/talin%40acm.org
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
ds for list, tuple, and various user-created sequence
types. (Although I can if I really need to.)
I would go further, and say that these object taxonomies should only go
so far as to provide what is needed to obtain that synergy; Any features
beyond that are mostly superfluous. But that's just my personal opinion.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
e same
one). Yes, there would still be some shared state that would have to be
managed, but I wouldn't think that the performance penalty of managing
that would be horrible.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail
ently parallelized
using processes can also be done with threads (assuming that the
infrastructure for threading is there), but the converse is not true.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mai
, and
if not then I'd say go ahead and disqualify the PEP - i.e. you lose your
"reserved" spot if you don't come up with an actual document within a
reasonable time frame.
-- Talin
___
Python-3000 mailing list
Python-30
ws about the structure of objects.
When I last worked on it, I had gotten the "young generation" collection
working, and I had just finished implementing the global heap, and was
in the process of writing unit tests for it. I hadn'
lifying
much - that is, the removals don't cascade and cause other
simplifications. The grammar file, for example, won't look dramatically
different if these changes are made. The simplification argument seems
weak to me because the change
ipulation of types to get things done fast.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
used for the Person object.
===
OK that is the description of the use case. I'd be interested to know
what uses cases people have that fall *outside* of the above.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Readability suffers as a consequence. In general, parens or grouping
operators should only be used when they *mean* something, not merely as
a hint to the parser as to how to parse something.
-- Talin
___
Python-3000 mailing list
Python-3000@python.o
Phillip J. Eby wrote:
> At 09:13 AM 5/1/2007 -0700, Talin wrote:
>> Phillip J. Eby wrote:
>>> Proceeding to the "Next" Method
>>> ~~~
>>> If the first parameter of an overloaded function is named
>>> ``__proceed_
of testing against a specially named argument.
Why couldn't you just have a different decorator, such as
"overload_chained" which triggers this behavior?
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/m
rloaded), whereas allowing method invocations is
much less safe.
So yes, theoretically attribute access can indeed run arbitrary code.
But not in a world with mostly sane people in it.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail
mitation that is also a strength: The mapping
between ABC and its bases is either built-in to the ABC or built-in to
the class, meaning that these decisions have to all be made up front -
which forces the ABC implementer to pre-decide the outcome of all such
conflicts before they happen.
--
Python at runtime,
then perhaps it is possible instead to allow for custom builds of the
Python 3000 executable with different arrangements and configurations of
these built-in classes.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.p
eir name starts with a single
> underscore (the latter should be considered implementation details, or
> perhaps definitional details).
I kind of wish that it was called "incomplete" rather than abstract, for
reasons that we've already discussed.
-- Talin
or designing things the way that
you have. However, I would suggest that you might want to consider what
your actual, practical needs are, and if there is a way to get them that
is more straightforward and easy to explain.
-- Talin
___
Python-3000 mail
ght; I guess my point is that if those "somewhat" useful implementations
>> are useful, they're useful, and there's no need to treat the corresponding
>> class as "abstract" (in the "non-instantiable" sense) in that case. For
>> example, I could pass an Iterable() to something that expected an iterable.
>
> Perhaps. Though I think it would defeat the purpose of being required
> to provide an implementation. If forced to choose, I'd rather remove
> the meaningful bodies (and replace them with "raise
> NotImplementedError") than remove the @abstractmethod decorators. But
> I prefer the current proposal.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
t are
strongly recommended.
Like all other things in Python, these promises are in the nature of a
gentlemen's agreement, which in this case means that while the language
does enforce some of the promises made in the ABC, it is up to the
implementer of the concrete class to insure that the
done more cleanly using generic functions: In the simplest
case, one can define a "category membership" generic function that
simply returns False in the base implementation, and then provide
overrides that return True for any classes of interest.
-- Talin
decomposition and methods as are defined by the new library (i.e. input
stream, output stream, and so on.)
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
r suggestion.
Hmmm.
"Countable" or "Enumerable" come to mind. "Enumerable" might be
confusing, however, since some languages use that word to mean "Iterable".
Other words that come to mind are "Dimension" and "Extent", although I
Talin wrote:
> By the way, there's something odd about the "reply-to" headers on your
> email, when I hit "reply all", it replied only to you, not the list.
Oh, duh. I'm an idiot - I didn't notice that the reply was only to me,
not the list.
Aurélien, m
Aurélien Campéas wrote:
> On Sat, Apr 14, 2007 at 10:57:28AM -0700, Talin wrote:
>> Part of the reason why I haven't volunteered to write a PEP for
ABC's is because I don't feel that I understand the various proposals
and the background discussion well enough. Howev
1 - 100 of 371 matches
Mail list logo
