Hello,
It seems to me that people don't object to my proposal, but don't find
it useful to them either.
The question is, what to do next. I guess one possibility is to raise
this discussion again in a few months, when people will be less
occupied with 2.5 beta. This is ok, although I would prefer a decision
before that, because it might affect the design of the library -
should I find a permanent workaround, or one that I know that will be
removed in the future.
If you do want to continue the discussion to reach a decision, please
do. You can say that if nobody else on python-dev is interested, it
shouldn't be implemented. You can examine my use case, say if you
think it's reasonable, and suggest alternative solutions - or say that
you see how allowing empty subscript list solves it elegantly (yes!)
My point is, I don't want this discussion to naturally die because
nobody is interested, since I am interested. So please say what you
think should happen to it, so we can reach a conclusion.
Now, if a the discussion is to continue, Nick proposed an alternative:
2006/6/11, Nick Coghlan <[EMAIL PROTECTED]>:
> For your specific use cases, though, I'd be inclined to tweak the API a bit,
> and switch to using attributes for the single-valued data:
>
> tax_rates.income_tax = 0.18
It's probably ok, although I would prefer not having to artificially
group scalars just to make them attributes of something. I would
prefer remaining with one object, and having something like
income_tax.setvalue(), or even income_tax.value.
> Although the income tax rate should actually depend on the current financial
> year, since it can change over time as the government increases taxes ;)
But that's exactly why I prefer writing simply "income_tax[] = 0.18"
when it's a constant, which is completely analogous to
"income_tax[2005] = 0.17; income_tax[2006] = 0.18" when it depends on
something.
By the way, another thing about consistency: A friend of mine brought
the point that there isn't another example of forbidden empty brackets
- [], {}, (), x() are all allowed.
And about the other thing Nick said:
> I guess I'm really only -0 on the idea of x[] invoking x.__getitem__(), and
> allowing the class to decide whether or not to define a default value for the
> subscript. I wouldn't implement it myself, but I wouldn't object strenuously
> if Guido decided it was OK :)
I would prefer an empty tuple, since invoking __getitem__ with no
arguments would be a special case: for all other possible subscript
lists, exactly one argument is passed to __getitem__. This leaves us
with one special case: a subscript list with one item and without a
trailing comma results in __getitem__ not getting a tuple, where in
all other cases it does get a tuple. This works exactly like
parentheses: they don't mean a tuple only when there's one item inside
them and no trailing comma.
Good bye,
Noam
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
