This was more of a core-mentorship question (tracker management) than a
pydev question (Python development). But since we are here...
On 6/10/2019 11:41 PM, Mariatta wrote:
Hmm, I personally would still consider the additional issues as
duplicates. So I would make note in each of the duplicate
On Jun 10, 2019, at 23:41, Mariatta wrote:
> On Mon, Jun 10, 2019 at 8:19 PM Jeffrey Kintscher
> wrote:
>> A hypothetical example would be two different issues whose descriptions
>> appear to be for different behaviors, but are actually caused by the same
>> underlying chunk of problematic cod
Hmm, I personally would still consider the additional issues as duplicates.
So I would make note in each of the duplicate issue saying "this is caused
by the same problem as bpo-X", and close them, and attach the PR only to
one bpo ticket.
To decide which one I would keep open, perhaps the oldest o
A hypothetical example would be two different issues whose descriptions
appear to be for different behaviors, but are actually caused by the
same underlying chunk of problematic code being called in different
ways. It could be something trivial like a corner case not being handled.
//Jeff
On
On Mon, Jun 10, 2019 at 6:44 PM Steve Dower wrote:
>
> I'd expect people coming from other languages to get it wrong this way too:
>
> class Status(Enum):
> on
> off
>
> Which will of course raise NameError and be just as opaque to the naive
> user as the AttributeError later on. I'm not
Usually we prefer 1 PR per 1 bpo ticket. The smaller the PR is, the easier
it is for us to review, and less likely to cause conflict when it comes to
auto-backporting.
When you say it resolves multiple issues, are these the same issue reported
multiple times?
ᐧ
On Mon, Jun 10, 2019 at 7:52 PM Jef
When I create a PR that resolves multiple issues, should I add it to
each issue, or just to one issue and add relevant comments to the others?
//Jeff
--
-
From there to here, from here to there,
funny things are everywhere.
-- Theodore Geisel
On Mon, Jun 10, 2019 at 02:29:56PM -0700, Ethan Furman wrote:
> Greetings!
>
> I saw my first annotation mix-up with regards to Enum today:
[...]
I don't think this is particular to Enums. I think this is going to be a
stumbling block for any class.
py> class X:
... a: 1
... b: 2
...
py
On 10Jun2019 1429, Ethan Furman wrote:
I saw my first annotation mix-up with regards to Enum today:
https://stackoverflow.com/q/56532591/208880
#enum import:
from enum import Enum
# enum definition:
class Status(Enum):
on: 1
off: 2
For those who don't
Greetings!
I saw my first annotation mix-up with regards to Enum today:
https://stackoverflow.com/q/56532591/208880
#enum import:
from enum import Enum
# enum definition:
class Status(Enum):
on: 1
off: 2
My question for the group:
Is this worth "fixing" or s
[Neil Schemenauer ]
> I've done a little testing the pool overhead. I have an application
> that uses many small dicts as holders of data. The function:
>
> sys._debugmallocstats()
>
> is useful to get stats for the obmalloc pools. Total data allocated
> by obmalloc is 262 MB. At the 4*PAGE
On 2019-06-09, Tim Peters wrote:
> And now there's a PR that removes obmalloc's limit on pool sizes, and,
> for a start, quadruples pool (and arena!) sizes on 64-bit boxes:
Neat.
> As the PR says,
>
> """
> It would be great to get feedback from 64-bit apps that do massive
> amounts of small-obj
Neil Schemenauer wrote:
> On 2019-05-31, Simon Cross wrote:
> > As the maintainer of Genshi, one the libraries
> > affected by the CodeType and
> > similar changes, I thought I could add a users perspective to the
> > discussion: [...]
>
> Thanks. I think this change to PyCode_New() could hav
13 matches
Mail list logo
