On 06May2021 03:43, Dennis Sweeney wrote:
>Maybe I'm missing something, but why do you need the SimpleNamespace at all?
>Why not make your own mapping as in
>
>class StringMapper:
>...
>def __getitem__(self, s):
># Whatever arbitrary behavior you want
>
Maybe I'm missing something, but why do you need the SimpleNamespace at all?
Why not make your own mapping as in
class StringMapper:
...
def __getitem__(self, s):
# Whatever arbitrary behavior you want
# Process suffixes, etc here, for example:
On 25Apr2021 10:54, Cameron Simpson wrote:
>On 24Apr2021 22:35, Stephen J. Turnbull
>wrote:
>[...]
>> > My use case is presupplied strings, eg a command line supplied
>> > format string.
>>
>>In that case the format string is user input, and x is a variable in
>>the program that the user can hav
Cameron Simpson writes:
> First up, I have somehow missed this (":format_name") in the
> semirecursive mess which is the python format-and-friends descriptions.
> (object.__format__? str.format? str.formap_map? f''? the format
> mini-language? all in separate places, for reasonable rea
Serhiy Storchaka writes:
> Because it converts value to string, and string formatting does not
> support "g". Converters !s, !r and !a are separated from format
> specifier, and it is old and widely used feature.
And poorly documented, IMO. I'll see if I can do better.
> but if we are going
On 25Apr2021 01:01, Chris Angelico wrote:
>On Sat, Apr 24, 2021 at 11:36 PM Stephen J. Turnbull
> wrote:
>> Assuming that *exact* use case, wouldn't
>>
>> >>> class LowerableStr(str):
>> ... def __format__(self, fmt):
>> ... if fmt == 'lc':
>> ...return self.lower()
>> .
On 24Apr2021 22:35, Stephen J. Turnbull
wrote:
>Cameron Simpson writes:
> > On 23Apr2021 18:25, Stephen J. Turnbull
> > wrote:
> > >I don't understand how this is supposed to work. It looks to me
> > >like !code is a preprocessor: [...]
> > >If so,
> > >
> > >'{x} is {x!lc:foo} in lowerca
On Sat, Apr 24, 2021 at 11:36 PM Stephen J. Turnbull
wrote:
> Assuming that *exact* use case, wouldn't
>
> >>> class LowerableStr(str):
> ... def __format__(self, fmt):
> ... if fmt == 'lc':
> ...return self.lower()
> ... else:
> ...return str.__format__(self,
Cameron Simpson writes:
> On 23Apr2021 18:25, Stephen J. Turnbull
> wrote:
> >I don't understand how this is supposed to work. It looks to me like
> >!code is a preprocessor: [...]
> >If so,
> >
> >'{x} is {x!lc:foo} in lowercase'
> >
> >will fail because str doesn't implement the
21.04.21 12:14, Paul Moore пише:
> I don't have a particularly strong opinion here, other than to say I'm
> not sure I like the upper case "I". It looks far too much like a lower
> case "L" in the font I'm using here, which makes me think of C's
> "long", so it's easy to confuse. So of the two opti
23.04.21 12:22, Stephen J. Turnbull пише:
> Serhiy Storchaka writes:
>
> > Currently format strings (and f-string expressions) support three
> > conversions: !s -- str, !r -- repr and !a for ascii.
>
> It's not clear to me what these are good for, to be honest. Why not
> just have s, r, and a
On 4/23/2021 5:22 AM, Stephen J. Turnbull wrote:
But we could change int.__format__ to allow 's' as a format code[1],
automagically calling str(), just as 'efg' are allowed and
automagically call float().
...
[1] I recognize this may imply many changes, since some (all?) of the
builtin types s
On 23Apr2021 18:25, Stephen J. Turnbull
wrote:
>Cameron Simpson writes:
> > I would _frequently_ like to be able to provide custom
> > conversions. At present I'm using elaborate hacks based on
> > __getattr__ etc to recognise things like this:
> >
> > '{x} is {x_lc} in lowercase'
> >
> > whe
On Fri, Apr 23, 2021 at 7:26 PM Stephen J. Turnbull
wrote:
>
> Cameron Simpson writes:
>
> > I would _frequently_ like to be able to provide custom
> > conversions. At present I'm using elaborate hacks based on
> > __getattr__ etc to recognise things like this:
> >
> > '{x} is {x_lc} in l
On Fri, Apr 23, 2021 at 7:24 PM Stephen J. Turnbull
wrote:
>
> Serhiy Storchaka writes:
>
> > Currently format strings (and f-string expressions) support three
> > conversions: !s -- str, !r -- repr and !a for ascii.
>
> It's not clear to me what these are good for, to be honest. Why not
> just
Cameron Simpson writes:
> I would _frequently_ like to be able to provide custom
> conversions. At present I'm using elaborate hacks based on
> __getattr__ etc to recognise things like this:
>
> '{x} is {x_lc} in lowercase'
>
> where the _lc suffix is caught and a value computed from
But IIUC once a conversion was added, it could not be removed without
breaking backward compatibility. So I think we should be cautious about
building what is in effect a Domain Specific Language and take care to
get it (as) right (as possible) first time.
Rob Cliffe
On 21/04/2021 22:44, Cam
On 21Apr2021 10:14, Paul Moore wrote:
>On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka wrote:
>> Do we need support of more standard conversions? Do we want to
>> support
>> custom conversions (registered globally as encodings and error
>> handlers). re.escape, html.escape and shlex.quote could b
On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka wrote:
>
> Currently format strings (and f-string expressions) support three
> conversions: !s -- str, !r -- repr and !a for ascii.
>
> I propose to add support of additional conversions: for int, float and
> operator.index. It will help to convert au
19 matches
Mail list logo
