Hi Amar, and welcome.
You might find that you get a more productive response if you write a
meaningful subject line and actually tell us what the PRs are about.
Nobody has the time or interest to look at every single PR, so if you
want to bring your PRs to the attention of those who will care a
On 2018-04-04 00:34, Ethan Furman wrote:
This behavior was recently brought to my attention [1]:
--> 1 in 'hello'
Traceback (most recent call last):
File "", line 1, in
TypeError: 'in ' requires string as left operand, not int
However, in any other collection (set, dict, list, tuple, etc),
:
On 3 April 2018 at 20:34, Ethan Furman wrote:
> This behavior was recently brought to my attention [1]:
>
> --> 1 in 'hello'
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'in ' requires string as left operand, not int
>
> However, in any other collection (set, dict,
It's because when the rhs is a string, 'in' tests for a substring rather
than simple containment. E.g. "ab" in "abc" gives True. So here 'in' is not
a collection membership, it only operates on two strings.
On Tue, Apr 3, 2018 at 4:34 PM, Ethan Furman wrote:
> This behavior was recently brought
On Tue, Apr 3, 2018 at 7:34 PM Ethan Furman wrote:
> This behavior was recently brought to my attention [1]:
>
> --> 1 in 'hello'
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: 'in ' requires string as left operand, not int
>
> However, in any other collection (set, d
This behavior was recently brought to my attention [1]:
--> 1 in 'hello'
Traceback (most recent call last):
File "", line 1, in
TypeError: 'in ' requires string as left operand, not int
However, in any other collection (set, dict, list, tuple, etc), the answer
would be False.
Does anyone re
Amar,
Loved that joke!
I had a quick look at these PR’s and commented. I do not see any worthwhile
improvement to Python by merging these, and there are significant problems with
the details in both patches. Hopefully your intent was to learn about the
process of contributing to Python, and
On 04/03/2018 01:16 PM, Barry Warsaw wrote:
On Apr 3, 2018, at 13:08, Brett Cannon wrote:
Are we at the PEP/language summit topic point yet in this discussion
>> since Guido has said he's not interested in changing the status quo?
>> ;) Versioning is like naming variables, so this thread coul
On Apr 3, 2018, at 13:08, Brett Cannon wrote:
> Are we at the PEP/language summit topic point yet in this discussion since
> Guido has said he's not interested in changing the status quo? ;) Versioning
> is like naming variables, so this thread could go on forever.
Yeah probably so. And if yo
On Tue, 3 Apr 2018 at 11:18 Barry Warsaw wrote:
> On Apr 3, 2018, at 05:51, Paul G wrote:
>
> > Switching to CalVer is a pretty clear sign that there is now a "rolling
> backwards compatibility window", and it allows Python to skip right over
> the mythical "Python 4" and directly to "Python 21"
On Apr 3, 2018, at 05:51, Paul G wrote:
> Switching to CalVer is a pretty clear sign that there is now a "rolling
> backwards compatibility window", and it allows Python to skip right over the
> mythical "Python 4" and directly to "Python 21". Additionally, since the
> version number will be t
On 2018-04-03 18:09, Paul G wrote:
On 04/03/2018 12:36 PM, Brett Cannon wrote:
On Tue, 3 Apr 2018 at 07:39 Paul G wrote:
Paul's point is that he knows e.g. code working in 3.6.0 will work when he
upgrades to 3.6.5, and if his code is warning-free and works with all
__future__ statements i
On 04/03/2018 12:36 PM, Brett Cannon wrote:
> On Tue, 3 Apr 2018 at 07:39 Paul G wrote:
> Paul's point is that he knows e.g. code working in 3.6.0 will work when he
> upgrades to 3.6.5, and if his code is warning-free and works with all
> __future__ statements in 3.6 that it will work fine in
On Tue, 3 Apr 2018 at 01:19 Serhiy Storchaka wrote:
> 03.04.18 01:57, Lukasz Langa пише:
> >> On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
> >> On Mon, 2 Apr 2018 13:48:46 -0700
> >> Lukasz Langa wrote:
> >>> Pickle protocol version 4.0 was originally defined back in PEP 3154
> and shipped
I personally see no reason to change anything.
On Tue, Apr 3, 2018 at 9:36 AM, Brett Cannon wrote:
>
>
> On Tue, 3 Apr 2018 at 07:39 Paul G wrote:
>
>> > When programs use calendar-based versioning, I'm left with no
>> > information as to whether it's breaking changes or not. In fact, it
>> > m
On Tue, 3 Apr 2018 at 07:39 Paul G wrote:
> > When programs use calendar-based versioning, I'm left with no
> > information as to whether it's breaking changes or not. In fact, it
> > might as well have no version numbers whatsoever. If I care about
> > backward compatibility, I just have to stic
Hi, all. Quick joke, Do you know why all functional programmers are anarchists?
Because they want to get rid of the state! :D
I know there are a lot more important issues than this, but i feel this is
important too. I wish some people could take a look at Python/Cpython pull
request #6343[1] an
On 04/03/2018 10:10 AM, Nick Coghlan wrote:
> The reason for sticking with 3.x for a while is because of the corner
> \*nix systems have gotten stuck into regarding the "python" symlink,
> and the fact it currently still points to "python2" (if it exists at
> all). Once we've updated PEP 394 to rec
> When programs use calendar-based versioning, I'm left with no
> information as to whether it's breaking changes or not. In fact, it
> might as well have no version numbers whatsoever. If I care about
> backward compatibility, I just have to stick with the exact same
> unpatched version that I had
On Tue, Apr 3, 2018 at 10:51 PM, Paul G wrote:
> Breaking this off from the pickle thread because it seems unrelated:
>
> On 04/02/2018 06:57 PM, Lukasz Langa wrote:
>> I think we need to get past thinking about "Python 2" vs. "Python 3". This
>> frame of mind creates space for another mythical r
On 3 April 2018 at 23:24, Paul G wrote:
> That documentation seems like a "layman's explanation" of how semantic
> versioning works. I suspect anyone familiar with semantic versioning will
> read that and think, "Ah, yes, this is a semantic versioning scheme."
Anyone that reads the porting sect
That documentation seems like a "layman's explanation" of how semantic
versioning works. I suspect anyone familiar with semantic versioning will read
that and think, "Ah, yes, this is a semantic versioning scheme."
Regardless of the semantics (har har) of whether Python "follows strict
semanti
On Tue, Apr 3, 2018 at 5:51 AM, Paul G wrote:
> Maybe this has already been discussed ad nauseum, but is the idea here that
> Python will stay on Python 3.x, but also start breaking backwards
> compatibility with old versions? That would seem to be a violation of
> semantic versioning.
Python'
On 3 April 2018 at 13:51, Paul G wrote:
> Maybe this has already been discussed ad nauseum, but is the idea here that
> Python will stay on Python 3.x, but also start breaking backwards
> compatibility with old versions? That would seem to be a violation of
> semantic versioning.
Python's vers
Breaking this off from the pickle thread because it seems unrelated:
On 04/02/2018 06:57 PM, Lukasz Langa wrote:
> I think we need to get past thinking about "Python 2" vs. "Python 3". This
> frame of mind creates space for another mythical release of Python that will
> break all the compatibili
03.04.18 01:57, Lukasz Langa пише:
On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
On Mon, 2 Apr 2018 13:48:46 -0700
Lukasz Langa wrote:
Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped
as part of Python 3.4 back in 2011. Yet it's still not the default.
Becau
On Mon, 2 Apr 2018 15:57:11 -0700
Lukasz Langa wrote:
> > On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
> >
> > On Mon, 2 Apr 2018 13:48:46 -0700
> > Lukasz Langa wrote:
> >> Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> >> shipped as part of Python 3.4 back i
27 matches
Mail list logo