On Wed, Mar 11, 2020 at 6:59 AM Rhodri James wrote:
> I disagree. We've headed off down the rabbit-hole of filenames for
> justification here, but surely pathlib is the correct tool if you are
> going to be chopping up filenames and path names?
Does pathlib work correctly for paths in unknown
> On 11 Mar 2020, at 19:03, Rhodri James wrote:
>
> On 11/03/2020 18:45, Stephen J. Turnbull wrote:
>> Rhodri James writes:
>> > We've headed off down the rabbit-hole of filenames for
>> > justification here, but surely pathlib is the correct tool if you
>> > are going to be chopping up
On Wed, Mar 11, 2020 at 07:06:20PM +0200, Serhiy Storchaka wrote:
> 11.03.20 12:39, Steven D'Aprano пише:
> >https://bugs.python.org/issue35712
> >
> >I am disappointed because, to me, it is a fundamental part of Python's
> >object model that *everything* can be interpreted as a truthy/falsey
>
On 11/03/2020 18:45, Stephen J. Turnbull wrote:
Rhodri James writes:
> We've headed off down the rabbit-hole of filenames for
> justification here, but surely pathlib is the correct tool if you
> are going to be chopping up filenames and path names?
This isn't obvious to me. The
On 03/11/2020 11:16 AM, Andrew Barnert via Python-ideas wrote:
On Mar 11, 2020, at 02:42, Steve Jorgensen wrote:
Take the following example:
```
def __lt__(self, other):
return not self.__ge__(other):
def __le__(self, other):
return not self.__gt__(other):
def
Rhodri James writes:
> We've headed off down the rabbit-hole of filenames for
> justification here, but surely pathlib is the correct tool if you
> are going to be chopping up filenames and path names?
This isn't obvious to me. The majority of people (among those for
whom my respect is "very
On Mar 11, 2020, at 02:42, Steve Jorgensen wrote:
>
> Take the following example:
>
> ```
>def __lt__(self, other):
>return not self.__ge__(other):
>
>def __le__(self, other):
>return not self.__gt__(other):
>
>def __ge__(self, other):
>
> ```
Usually you
On Mar 11, 2020, at 03:07, Steven D'Aprano wrote:
>
> But bytes are useful for more than just file names!
The paradigm example of this is HTTP. It’s mostly people working on HTTP
clients, servers, middleware, and apps who pushed for the bytes methods in
Python 3.x. IIRC, the PEP for
11.03.20 12:39, Steven D'Aprano пише:
https://bugs.python.org/issue35712
I am disappointed because, to me, it is a fundamental part of Python's
object model that *everything* can be interpreted as a truthy/falsey
object (in the absence of bugs).
NotImplemented is special. It is more special
Looks like NotImplemented is widely misunderstood. It should *ONLY* be
returned from binary operator overloads, like __add__.
On Wed, Mar 11, 2020 at 03:49 wrote:
> Steven D'Aprano wrote:
> > On Wed, Mar 11, 2020 at 09:42:15AM -, Steve Jorgensen wrote:
> > > I realize this is probably
On 10/03/2020 20:18, Christopher Barker wrote:
...much about file naming in theory and practice under Unix, concluding
with:
But bytes has a pretty full set of "string like" methods now, so I suppose
it makes sense to add a couple new ones that are related to ones that are
already there.
I
Steven D'Aprano wrote:
> On Wed, Mar 11, 2020 at 09:42:15AM -, Steve Jorgensen wrote:
> > I realize this is probably something that would be
> > hard to change for
> > compatibility reasons. Maybe someone can think of a way around that
> > though?
> > It seems to me that not NotImplemented
On Wed, Mar 11, 2020 at 09:42:15AM -, Steve Jorgensen wrote:
> I realize this is probably something that would be hard to change for
> compatibility reasons. Maybe someone can think of a way around that
> though?
>
> It seems to me that `not NotImplemented` should result in
>
Steve Jorgensen wrote:
> I realize this is probably something that would be hard to change for
> compatibility
> reasons. Maybe someone can think of a way around that though?
> It seems to me that not NotImplemented should result in
> NotImplemented and attempting to convert it to bool should
On Wed, Mar 11, 2020 at 9:28 PM Steven D'Aprano wrote:
>
> On Wed, Mar 11, 2020 at 07:28:06AM +1100, Chris Angelico wrote:
>
> > That's exactly what "ASCII compatible" means. Since ASCII is a
> > seven-bit encoding, an encoding is ASCII-compatible if (a) every ASCII
> > character is represented
NotImplemented is not supposed to be used in any operation. It's just
a special value used in coercion since raising exceptions would be
too costly.
In your example you would need to check for this special value using
the "is" comparison.
See https://www.python.org/dev/peps/pep-0208/ and
On Wed, Mar 11, 2020 at 9:05 PM Steven D'Aprano wrote:
> In practice, modern Unix shells and GUIs use UTF-8. UTF-8 has two nice
> properties:
>
> * Every ASCII character encodes to a single byte, so text which
> only contains ASCII values encodes to precisely the same set
> of bytes under
On Wed, Mar 11, 2020 at 07:28:06AM +1100, Chris Angelico wrote:
> That's exactly what "ASCII compatible" means. Since ASCII is a
> seven-bit encoding, an encoding is ASCII-compatible if (a) every ASCII
> character is represented by the corresponding byte value, and (b)
> every seven-bit value
Christopher, I'm not sure how much of the following you already know, so
excuse me in advance if I'm covering old ground for you. But hopefully
it will be helpful for someone!
On Tue, Mar 10, 2020 at 01:18:22PM -0700, Christopher Barker wrote:
> Getting a bit OT, but I *think* this is the
I realize this is probably something that would be hard to change for
compatibility reasons. Maybe someone can think of a way around that though?
It seems to me that `not NotImplemented` should result in `NotImplemented` and
attempting to convert it to `bool` should raise a `TypeError`
20 matches
Mail list logo
