Anders Hovmöller wrote:
> It would have been better with a dedicated concat operator I think but just a
> little bit better.
Interesting little side note, for anyone who doesn't already know: at the C
level, Python objects have two ways of implementing addition and
multiplication. The first is
> On 17 Oct 2019, at 22:44, Steven D'Aprano wrote:
>
> On Thu, Oct 17, 2019 at 01:42:54PM +0200, Anders Hovmöller wrote:
>
>> The multiply a list/string thing is a big mistake imo. You almost
>> never use it so the cost of not having it is almost nothing while the
>> cost of having type err
On 2019-10-17 18:02, Victor Stinner wrote:
Hi,
I propose the following PEP to add
sys.set_python_compat_version(version) to introduce a partial
compatibility with Python 3.8 in the next Python 3.9 version.
I also propose this PEP in a pull request:
https://github.com/python/peps/pull/1209
(Plea
I re-read your proposal.
Please ignore my suggestion. :)
I misunderstood core concept of your proposal :)
2019년 10월 18일 (금) 오전 10:19, Victor Stinner 님이 작성:
>
> Hi,
>
> I propose the following PEP to add
> sys.set_python_compat_version(version) to introduce a partial
> compatibility with Python 3.8
On 10/17/2019 06:02 PM, Victor Stinner wrote:
I propose the following PEP to add
sys.set_python_compat_version(version) to introduce a partial
compatibility with Python 3.8 in the next Python 3.9 version.
-1
If possible, please try to read the whole PEP before replying.
Done.
TL;DR Besid
The proposal looks awesome to me. Victor :)
It could be out of scope for this proposal.
How about adding APIs about compatibility implementation in this proposal?
e.g compatibility_python_implementation
usage will be
sys.compatibility_python_implementation(('Cpython', 'PyPy', 'XXXPython'))
We ca
On Oct 17, 2019, at 16:03, Steve Jorgensen wrote:
>
> My thinking is that checking for type of `Struct` (or `Record` or whatever
> name it has) is most useful in cases when the object is also identifiable as
> a collection and is to disambiguate those that are primarily collections from
> thos
Hi,
I propose the following PEP to add
sys.set_python_compat_version(version) to introduce a partial
compatibility with Python 3.8 in the next Python 3.9 version.
I also propose this PEP in a pull request:
https://github.com/python/peps/pull/1209
(Please avoid using the temporary PEP number until
Eric V. Smith wrote:
> On 10/17/2019 2:36 PM, Steve Jorgensen wrote:
> > Andrew Barnert wrote:
> > [snip]
> > But meanwhile, you still haven’t given any
> > reason why Record would be useful. What
> > exactly is it supposed to mean? When would you want to check it? What would
> > you do with
> > a
On Thu, Oct 17, 2019 at 5:33 AM Steven D'Aprano wrote:
> On Thu, Oct 17, 2019 at 08:19:13AM -, Steve Jorgensen wrote:
>
> > Why the need for strictness of type for the operator? I get that it's
> > analogous with the behavior for `list`, but I guess I'm also not sure
> > why that should be st
+1
Been waiting a decade+ for this. Too bad it didn't get into 3.8.
Nice work on the PEP.
-Mike
p.s. A another mentioned this existing syntax does allow non-string keys:
>>> d1 = dict(one=1, two=2)
>>> d2 = {'three':3, 4:4}
>>>
>>> {**d1, **d2}
{'one': 1, 'two': 2, 'three': 3, 4: 4
On Thu, Oct 17, 2019 at 02:08:56PM +0200, Anders Hovmöller wrote:
> Well obviously never with literals. But most cases of multiplication
> aren't with literals. So how can you get a type error when doing
>
> a*b
>
> is the real question.
Actually, the real question is, why are you using such c
On Thu, Oct 17, 2019 at 01:42:54PM +0200, Anders Hovmöller wrote:
> The multiply a list/string thing is a big mistake imo. You almost
> never use it so the cost of not having it is almost nothing while the
> cost of having type errors propagate beyond the point where they
> happened is big.
I
On Thu, Oct 17, 2019 at 12:41:29AM -0700, Andrew Barnert via Python-ideas wrote:
> Less trivial, but maybe dismissible: it says one of the authors is
> going to write another PEP later to add the full complement of set
> operators to dict.
It says that one of the authors is *interested* in writ
On 10/17/2019 2:36 PM, Steve Jorgensen wrote:
Andrew Barnert wrote:
[snip]
But meanwhile, you still haven’t given any reason why Record would be useful.
What
exactly is it supposed to mean? When would you want to check it? What would you
do with an
object only if you know it’s a Record?
This i
On Fri, Oct 18, 2019 at 6:06 AM Anders Hovmöller wrote:
>
> > On 17 Oct 2019, at 20:37, Chris Angelico wrote:
> >
> > On Fri, Oct 18, 2019 at 5:25 AM Anders Hovmöller
> > wrote:
> >>
> >> No. The reason I don't know is because this is a hypothetical example. In
> >> real code I would "know" B
Steven D'Aprano wrote:
> On Thu, Oct 17, 2019 at 08:19:13AM -, Steve Jorgensen wrote:
> > Why the need for strictness of type for the operator?
> > I get that it's
> > analogous with the behavior for list, but I guess I'm also not sure
> > why that should be strict.
> > (1) Follow the precede
> On 17 Oct 2019, at 20:37, Chris Angelico wrote:
>
> On Fri, Oct 18, 2019 at 5:25 AM Anders Hovmöller wrote:
>>
>>
>>
On 17 Oct 2019, at 17:07, Andrew Barnert wrote:
>>>
>>> On Oct 17, 2019, at 05:08, Anders Hovmöller wrote:
Well obviously never with literals. But most
On Fri, Oct 18, 2019 at 5:25 AM Anders Hovmöller wrote:
>
>
>
> > On 17 Oct 2019, at 17:07, Andrew Barnert wrote:
> >
> > On Oct 17, 2019, at 05:08, Anders Hovmöller wrote:
> >>
> >> Well obviously never with literals. But most cases of multiplication
> >> aren't with literals. So how can you
Andrew Barnert wrote:
[snip]
> But meanwhile, you still haven’t given any reason why Record would be useful.
> What
> exactly is it supposed to mean? When would you want to check it? What would
> you do with an
> object only if you know it’s a Record?
> This isn’t like checking for a POD type in
> On 17 Oct 2019, at 17:07, Andrew Barnert wrote:
>
> On Oct 17, 2019, at 05:08, Anders Hovmöller wrote:
>>
>> Well obviously never with literals. But most cases of multiplication aren't
>> with literals. So how can you get a type error when doing
>>
>> a*b
>>
>> is the real question. A
Andrew Barnert wrote:
> Minor nit: the formatting is broken in some of the examples of candidates. The
> first one I noticed is the last Sphinx one.
Thanks for spotting those! I'll fix them.
> Less trivial, but maybe dismissible: it says one of the authors is going to
> write
> another PEP later
On Oct 17, 2019, at 01:35, Steve Jorgensen wrote:
>
> Along with this idea, maybe `namedtuple` should became a type (not just a
> callable as it is now) for classes produced by calling `namedtuple()`. The
> `namedtuple` type could in turn inherit from `tuple` and from `Record` (or
> `Struct` o
On Oct 17, 2019, at 05:08, Anders Hovmöller wrote:
>
> Well obviously never with literals. But most cases of multiplication aren't
> with literals. So how can you get a type error when doing
>
> a*b
>
> is the real question. And the answer is now obvious: any time the programmer
> thinks a
> On 17 Oct 2019, at 14:26, Chris Angelico wrote:
>
> On Thu, Oct 17, 2019 at 11:08 PM Anders Hovmöller
> wrote:
>>
>> So how can you get a type error when doing
>>
>> a*b
>>
>> is the real question. And the answer is now obvious: any time the
>> programmer thinks a and b are numbers bu
>
> Along with this idea, maybe `namedtuple` should became a type (not just a
> callable as it is now) for classes produced by calling `namedtuple()`. The
> `namedtuple` type could in turn inherit from `tuple` and from `Record` (or
> `Struct` or whatever name is decided for that).
>
See Raymond He
On Thu, Oct 17, 2019 at 11:08 PM Anders Hovmöller wrote:
>
> So how can you get a type error when doing
>
> a*b
>
> is the real question. And the answer is now obvious: any time the programmer
> thinks a and b are numbers but they are not.
>
If you start with the assumption that multiplication
> On 17 Oct 2019, at 13:46, Chris Angelico wrote:
>
> On Thu, Oct 17, 2019 at 10:42 PM Anders Hovmöller
> wrote:
>>
On 17 Oct 2019, at 13:26, Chris Angelico wrote:
>>>
>>> Equally subjective, of course, but I prefer to be able to use
>>> operators. There's a good reason that we use m
On Thu, Oct 17, 2019 at 10:42 PM Anders Hovmöller wrote:
>
> > On 17 Oct 2019, at 13:26, Chris Angelico wrote:
> >
> > Equally subjective, of course, but I prefer to be able to use
> > operators. There's a good reason that we use mathematical symbols for
> > non-numeric data types already (adding
> On 17 Oct 2019, at 13:26, Chris Angelico wrote:
>
> On Thu, Oct 17, 2019 at 8:54 PM Inada Naoki wrote:
>>
>> I think this PEP is very relating to language design philosophy.
>>
>> (a) Overload operator heavily for convenience.
>>
>> (b) Prefer methods over operators. Set a high bar for
On Thu, Oct 17, 2019 at 8:54 PM Inada Naoki wrote:
>
> I think this PEP is very relating to language design philosophy.
>
> (a) Overload operator heavily for convenience.
>
> (b) Prefer methods over operators. Set a high bar for
> overloading operators on core types.
>
> I prefer (b) philosop
I think this PEP is very relating to language design philosophy.
(a) Overload operator heavily for convenience.
(b) Prefer methods over operators. Set a high bar for
overloading operators on core types.
I prefer (b) philosophy. And I don't think described usefulness
is enough for adding th
On Thu, Oct 17, 2019 at 08:19:13AM -, Steve Jorgensen wrote:
> Why the need for strictness of type for the operator? I get that it's
> analogous with the behavior for `list`, but I guess I'm also not sure
> why that should be strict.
(1) Follow the precedent of existing operators.
(2) It i
Steve Jorgensen wrote:
> I feel like this proposal is not quite right, but maybe the idea will provoke
> some
> thoughts about something similar that -would- be right.
> The idea first came to me upon realizing that since namedtuple classes
> have no special base class beyond tuple, there should b
Late to the game, I like the proposal a lot but have a couple of questions
about it.
Why the need for strictness of type for the operator? I get that it's analogous
with the behavior for `list`, but I guess I'm also not sure why that should be
strict. As a compromise in regard to strictness, wh
Notes on new PEP:
The section on
{**d1, **d2}
claims "It is only guaranteed to work if the keys are all strings. If the
keys are not strings, it currently works in CPython, but it may not work
with other implementations, or future versions of CPython[2]."
That's 100% wrong. You're mixing up the
Andrew Barnert wrote:
> On Oct 17, 2019, at 00:22, Steve Jorgensen ste...@stevej.name wrote:
> > Do you know if there is an existing proposal for
> > subtraction of iterables from lists and tuples?
> > Any existing proposal would be listed in PEP 0 if it’s a PEP, on
> > bugs.python.org
> if it doe
On Oct 17, 2019, at 00:22, Steve Jorgensen wrote:
>
> Do you know if there is an existing proposal for subtraction of iterables
> from lists and tuples?
Any existing proposal would be listed in PEP 0 if it’s a PEP, on
bugs.python.org if it doesn’t need a PEP, or in a current thread in this lis
On Oct 16, 2019, at 22:35, Brandt Bucher wrote:
>
> At long last, Steven D'Aprano and I have pushed a second draft of PEP 584
> (dictionary addition):
>
> https://www.python.org/dev/peps/pep-0584/
Minor nit: the formatting is broken in some of the examples of candidates. The
first one I notic
Brandt Bucher wrote:
> At long last, Steven D'Aprano and I have pushed a second draft of PEP 584
> (dictionary
> addition):
> https://www.python.org/dev/peps/pep-0584/
> The accompanying reference implementation is on GitHub:
> https://github.com/brandtbucher/cpython/tree/addiction
Do you know if
`Record` feels good to me as a name for this concept.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived a
41 matches
Mail list logo
