On 11/2/2019 10:02 PM, Jonathan Goble wrote:
On Sat, Nov 2, 2019 at 9:52 PM MRAB wrote:
On 2019-11-03 00:38, Chris Angelico wrote:
On Sun, Nov 3, 2019 at 11:34 AM Eric V. Smith wrote:
On 11/2/2019 7:24 PM, Steven D'Aprano wrote:
I see no reason why this shouldn't be allowed. It seems like
On 2019-11-03 00:02, Eric V. Smith wrote:
On 11/2/2019 10:02 PM, Jonathan Goble wrote:
So there's no reason in that regard to not allow it, and I'm +1 on the idea.
I disagree. I don't think there's precedent in Python for stringifying
parameters. By your logic, shouldn't we also call str() on
On Sun, Nov 3, 2019 at 12:33 AM Brendan Barnwell
wrote:
> On 2019-11-03 00:02, Eric V. Smith wrote:
> > On 11/2/2019 10:02 PM, Jonathan Goble wrote:
> >> So there's no reason in that regard to not allow it, and I'm +1 on the
> idea.
> >
> > I disagree. I don't think there's precedent in Python fo
On Sat, Nov 02, 2019 at 07:31:55PM -0400, Eric V. Smith wrote:
> On 11/2/2019 7:24 PM, Steven D'Aprano wrote:
> >I see no reason why this shouldn't be allowed. It seems like a
> >straight-forward feature request, and one that is compatible with the
> >basic idea that Path objects should be usable a
On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
> For the record, I have always thought that str.join should call str
> on all its arguments. The fact that it doesn't is really annoying.
Given:
values = ["Hello", b"World"]
would you expect ' '.join(values) to
> On 3 Nov 2019, at 10:28, Steven D'Aprano wrote:
>
> On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
>
>>For the record, I have always thought that str.join should call str
>>on all its arguments. The fact that it doesn't is really annoying.
>
> Given:
>
>va
On Sun, Nov 3, 2019 at 9:34 PM Anders Hovmöller wrote:
>
>
>
> > On 3 Nov 2019, at 10:28, Steven D'Aprano wrote:
> >
> > On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
> >
> >>For the record, I have always thought that str.join should call str
> >>on all its arguments.
On Sun, Nov 03, 2019 at 11:31:22AM +0100, Anders Hovmöller wrote:
> > Given:
> >
> >values = ["Hello", b"World"]
> >
> > would you expect ' '.join(values) to return
> >
> >"Hello b'World'"
> >
> > because that's what you'll get calling str automatically.
>
> Side note!
>
> That misf
> On 3 Nov 2019, at 12:17, Steven D'Aprano wrote:
>
> On Sun, Nov 03, 2019 at 11:31:22AM +0100, Anders Hovmöller wrote:
>
>>> Given:
>>> values = ["Hello", b"World"]
>>> would you expect ' '.join(values) to return
>>> "Hello b'World'"
>>> because that's what you'll get calling str automatic
> On 3 Nov 2019, at 11:39, Chris Angelico wrote:
>
> On Sun, Nov 3, 2019 at 9:34 PM Anders Hovmöller wrote:
>>
>>
>>
On 3 Nov 2019, at 10:28, Steven D'Aprano wrote:
>>>
>>> On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
>>>
For the record, I have always t
03.11.19 12:31, Anders Hovmöller пише:
On 3 Nov 2019, at 10:28, Steven D'Aprano wrote:
Given:
values = ["Hello", b"World"]
would you expect ' '.join(values) to return
"Hello b'World'"
because that's what you'll get calling str automatically.
Side note!
That misfeature of python 3
On Nov 3, 2019, at 13:01, Anders Hovmöller wrote:
>
> Well, the last part requires that print can coerce bytes to str, not strictly
> that it must do so via str(). repr() should return b'foo' but str() could
> have returned .
That would be very confusing. When they differ, it’s always repr th
Sorry about that. For some reason, the line got trimmed and I didn't notice
when I sent the response.
`Popen((PathLike))`
is what I meant as you mention there
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to py
On Nov 2, 2019, at 21:02, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>>
>>> throw is an expression, not a statement, in C++. I see no reason raise
>>> couldn't be an expression in Python. I
On 2019-11-03 12:24 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 2, 2019, at 21:02, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>>
>>> throw is an expression, not a statement, in
On Nov 2, 2019, at 20:33, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 03:10, Andrew Barnert wrote:
>>> On Oct 26, 2019, at 19:59, Random832 wrote:
>>>
>>> A string representation considering of (say) a UTF-8 string, plus an
>>> auxiliary list of byte indices of, say, 256-codepoint-long chun
> On 3 Nov 2019, at 13:31, Andrew Barnert wrote:
>
> On Nov 3, 2019, at 13:01, Anders Hovmöller wrote:
>>
>> Well, the last part requires that print can coerce bytes to str, not
>> strictly that it must do so via str(). repr() should return b'foo' but str()
>> could have returned .
>
> T
> On Nov 3, 2019, at 16:07, Anders Hovmöller wrote:
>
>> On 3 Nov 2019, at 13:31, Andrew Barnert wrote:
>>
>> On Nov 3, 2019, at 13:01, Anders Hovmöller wrote:
>>>
>>> Well, the last part requires that print can coerce bytes to str, not
>>> strictly that it must do so via str(). repr() shou
On Nov 3, 2019, at 15:38, Soni L. wrote:
>> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and
>> > conditional expressions) without being a general expression.
>> Just like, e.g., yield_expr is allowed in assignment statements without
>> being a general expression, an
> On 3 Nov 2019, at 16:50, Andrew Barnert wrote:
>
>
>>
>>> On Nov 3, 2019, at 16:07, Anders Hovmöller wrote:
>>>
On 3 Nov 2019, at 13:31, Andrew Barnert wrote:
>>>
>>> On Nov 3, 2019, at 13:01, Anders Hovmöller wrote:
Well, the last part requires that print can coerce
On 2019-11-03 01:21, Steven D'Aprano wrote:
On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
For the record, I have always thought that str.join should call str
on all its arguments. The fact that it doesn't is really annoying.
Given:
values = ["Hello",
On 2019-11-03 08:24, Steven D'Aprano wrote:
On Sat, Nov 02, 2019 at 07:31:55PM -0400, Eric V. Smith wrote:
On 11/2/2019 7:24 PM, Steven D'Aprano wrote:
>I see no reason why this shouldn't be allowed. It seems like a
>straight-forward feature request, and one that is compatible with the
>basic id
On Mon, Nov 4, 2019 at 3:49 AM Anders Hovmöller wrote:
> It's not a proposal though. It's way too late to change this now. I'm just
> saying the situation for the switch wasn't ideal. I think we all agree on
> that but for different reasons ;)
>
No, I don't think we do agree :) Some of us quit
On 11/03/2019 02:31 AM, Anders Hovmöller wrote:
Side note!
When switching subjects mid-thread, please re-title the subject. This
side-note sub-thread is now nearly as long as the original thread.
--
~Ethan~
___
Python-ideas mailing list -- python-
Andrew Barnert via Python-ideas wrote:
I don’t know what NIY means here,
Not Invented Yet. It's used by the time machine to prevent temporal
paradoxes due to anachronistic use of technology, for example if you
try to use van Finkelstein's algorithm for solving the halting
problem before 2186...
On 2019-11-03 2:01 p.m., Andrew Barnert wrote:
On Nov 3, 2019, at 15:38, Soni L. wrote:
>> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and conditional expressions) without being a general expression.
>> Just like, e.g., yield_expr is allowed in assignment statemen
On Mon, Nov 4, 2019 at 11:01 AM Soni L. wrote:
> In Rust, for example, one can do `let foo = unimplemented!();`. Ofc, one
> could also do:
>
> def unimplemented():
> raise NYI
>
> but having the "raise" in the assignment makes it easier for a human to
> process - you can tell from "foo = rais
On Nov 4, 2019, at 00:58, Soni L. wrote:
>
> That was meant to be NYI (Not Yet Implemented), sorry. (feel free to treat
> "NIY" as "Not Implemented Yet" :P)
Ah. I use NotImplementedError for that, because there are unit testing
frameworks that know how to count that differently from other unex
28 matches
Mail list logo
