On Mon, Dec 19, 2022 at 05:53:38PM -0800, Ethan Furman wrote:
> Personally, every other time I've wanted to subclass a built-in data type,
> I've wanted the built-in methods to return my subclass, not the original
> class.
Enums are special. But outside of enums, I cannot think of any useful
s
On Tue, 20 Dec 2022 at 20:20, Steven D'Aprano wrote:
>
> On Mon, Dec 19, 2022 at 05:53:38PM -0800, Ethan Furman wrote:
>
> > Personally, every other time I've wanted to subclass a built-in data type,
> > I've wanted the built-in methods to return my subclass, not the original
> > class.
>
> Enums
This is somewhat inspired by the "Tagged strings in python" thread, but from a
different approach.
Specifically, rather than messing with runtime python, using static type
analysis to help the usability of specific kinds of string literals.
It would be useful to take advantage of the `LiteralStr
Chiming in to say this is a really neat idea and I would definitely have
used this in the past, especially when doing programming where it would
have been much more useful to know about errors at coding time and not at
runtime.
This isn't to say it should definitely be added to the language, that'
On 19Dec2022 22:45, Chris Angelico wrote:
On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano wrote:
> But this much (say with a better validator) gets you static type checking,
> syntax highlighting, and inherent documentation of intent.
Any half-way decent static type-checker will immediately fai
On 20Dec2022 20:16, Steven D'Aprano wrote:
On Mon, Dec 19, 2022 at 05:53:38PM -0800, Ethan Furman wrote:
Personally, every other time I've wanted to subclass a built-in data
type, I've wanted the built-in methods to return my subclass, not the original
class.
Enums are special. But outside o
On Wed, 21 Dec 2022 at 09:30, Cameron Simpson wrote:
>
> On 19Dec2022 22:45, Chris Angelico wrote:
> >On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano wrote:
> >> > But this much (say with a better validator) gets you static type
> >> > checking,
> >> > syntax highlighting, and inherent documentat
As has been said, a builtin *could* be written that would be "friendly to
subclassing", by the definition in this thread. (I'll stay out of the
argument for the moment as to whether that would be better)
I suspect that the reason str acts like it does is that it was originally
written a LONG time
On Tue, Dec 20, 2022 at 5:38 PM Christopher Barker
wrote:
> But collections.UserString does exist -- so if you want to subclass, and
> performance isn't critical, then use that. Steven A pointed out that
> UserStrings are not instances of str though. I think THAT is a bug. And
> it's probably tha
On Tue, Dec 20, 2022 at 6:20 PM Lucas Wiman wrote:
> On Tue, Dec 20, 2022 at 5:38 PM Christopher Barker
> wrote:
>
>> But collections.UserString does exist -- so if you want to subclass, and
>> performance isn't critical, then use that. Steven A pointed out that
>> UserStrings are not instances
Ricky Teachey writes:
> This isn't to say it should definitely be added to the language, that's a
> tough hurdle. But boy would I have used it.
IIUC, Mathew's idea doesn't need to be added to *the* language (the
one defined by the Language Reference). It needs to be added to the
languages used
Christopher Barker writes:
> But collections.UserString does exist -- so if you want to subclass, and
> performance isn't critical, then use that. Steven A pointed out that
> UserStrings are not instances of str though. I think THAT is a bug.
I guess, although surely the authors of that class
On Tue, Dec 20, 2022 at 8:21 PM Stephen J. Turnbull > UserStrings are not instances of str though. I think THAT is a bug.
>
> I guess, although surely the authors of that class thought about it.
Well, kind of — the entire reason for UserString was that at the time, str
itself could not be subcl
On Wed, Dec 21, 2022 at 09:42:51AM +1100, Cameron Simpson wrote:
> With str subtypes, the case that comes to my mind is mixing str
> subtypes.
[...]
> So, yes, for many methods I might reasonably expect a new html(str). But
> I can contrive situations where I'd want a plain str
The key word the
I'm on my tablet, so cannot test at the moment. But is `str.upper()` REALLY
wrong about the Turkish dotless I (and dotted capital I) currently?!
That feels like a BPO needed if true.
On Wed, Dec 21, 2022, 1:04 AM Steven D'Aprano wrote:
> On Wed, Dec 21, 2022 at 09:42:51AM +1100, Cameron Simpson
On Wed, 21 Dec 2022 at 17:20, David Mertz, Ph.D. wrote:
>
> I'm on my tablet, so cannot test at the moment. But is `str.upper()` REALLY
> wrong about the Turkish dotless I (and dotted capital I) currently?!
>
> That feels like a BPO needed if true.
It's wrong about the ASCII i and I, which upper
On Wed, 21 Dec 2022 at 17:03, Steven D'Aprano wrote:
> The status quo mostly hurts *lightweight*
> subclasses:
>
> class TurkishString(str):
> def upper(self):
> return TurkishString(str.upper(self.replace('i', 'İ')))
> def lower(self):
> return TurkishS
On 21Dec2022 17:00, Steven D'Aprano wrote:
On Wed, Dec 21, 2022 at 09:42:51AM +1100, Cameron Simpson wrote:
With str subtypes, the case that comes to my mind is mixing str
subtypes.
[...]
So, yes, for many methods I might reasonably expect a new html(str). But
I can contrive situations where
Oh yeah. Good points! Do we need a PEP for str.upper() to grow an optional
'locale' argument? I feel like there are examples other than the Turkish
i's where this matters, but it's past my bedtime, so they aren't coming to
mind.
Maybe Koine Greek which had not adopted the miniscule/majuscule disti
On Wed, 21 Dec 2022 at 17:39, David Mertz, Ph.D. wrote:
>
> Oh yeah. Good points! Do we need a PEP for str.upper() to grow an optional
> 'locale' argument? I feel like there are examples other than the Turkish i's
> where this matters, but it's past my bedtime, so they aren't coming to mind.
>
On Wed, Dec 21, 2022 at 01:18:46AM -0500, David Mertz, Ph.D. wrote:
> I'm on my tablet, so cannot test at the moment. But is `str.upper()` REALLY
> wrong about the Turkish dotless I (and dotted capital I) currently?!
It has to be. Turkic languages like Turkish, Azerbaijani and Tatar
distinguish
@property
def data(self):
return f"{self}"
Not at a workstation but this should be faster than join() while still
using syntax and not builtin functions.
~ Jeremiah
On Tue, Dec 20, 2022 at 5:38 PM Christopher Barker
wrote:
> As has been said, a builtin *could* be written that
22 matches
Mail list logo
