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
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
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
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 --
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
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
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 =
> 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 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,
> 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()
> 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 .
>
>
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
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,
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.
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 -- python-ideas@python.org
To unsubscribe send an email to
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
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 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
> 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
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
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
> 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:
>
>
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)
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
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
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 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
27 matches
Mail list logo
