disclaimer: i'm not sure this suggestion is feasible to
implement, because of the way descriptors work, but
it's something we should consider adding.
as you may remember, in iostack, we said the position
property should act like the following:
f.position = # absolute seek
f.position = # re
tomer filiba wrote:
> so my suggestion is as follows:
> data descriptors must define __get__ and __set__. if they
> also define one of the inplace-operators (__iadd___, etc),
> it will be called instead of first __get__()ing and then
> __set__()ing.
>
> however, the inplace operators would have t
well, adding bytecodes is out-of-the-question for me.
i did think of doing a position-proxy class, but it has lots of
drawbacks as well:
* lots of methods to implement (to make it look like an int)
* lazy evaluation -- should only perform tell() when requested,
not before. for example, calling __
tomer filiba wrote:
> i did think of doing a position-proxy class, but it has lots of
> drawbacks as well:
> * lots of methods to implement (to make it look like an int)
Not if you subclass it from int, and inherit all its
behaviour. The only things you'd need to add are a
reference to the base f
Here's the latest PEP 3101 - I've incorporated changes based on
suggestions from a lot of folks. This version incorporates:
-- a detailed specification for conversion type fields
-- description of error handling behavior
-- 'strict' vs. 'lenient' error handling flag
-- compound field
Talin wrote:
> Conversion Specifiers
>
> Each field can also specify an optional set of 'conversion
> specifiers' which can be used to adjust the format of that field.
> Conversion specifiers follow the field name, with a colon (':')
> character separating the two:
>
>
Nick Coghlan wrote:
>> Conversion Specifiers
By the way, good feedback. I've incorporated most of the text changes
into the PEP. I'd like to discuss a few of your suggestions in more
detail before proceeding.
>> There are several integer conversion types. All invoke int() on
>> the ob
