In the mypy project we've definitely experienced the problem with
"beginner" issues that they would be fixed by disinterested folks who just
wanted to score some GitHub points, and we stopped doing that. While we've
not kept track carefully, my impression is that we've not seen the quantity
of
Steve Dower writes:
> I'm sympathetic to wanting to have tasks for the PyCon sprints, but at
> the same time it feels exclusionary to "save" them from people who want
> to volunteer at other times.
It's already possible to do this sub rosa. Just get a mentor to
"claim" the issue, and have
Barry Warsaw writes:
> On Feb 21, 2019, at 10:34, Raymond Hettinger
> wrote:
> >
> > I think that anything that raises the cost of filing a bug report
> > will work to our detriment. Ideally, we want the barriers to
> > reporting to be as low as possible.
A template is probably
> I'm 100% in favor of discouraging regular contributors from fixing them
>
This would be nice too. Speaking from my experience, it's hard to leave
the comfort of what looks to be a quick win (by submitting a PR on an easy
issue) and moving on to something where you're more unsure. But...
> -
Cheryl, thanks for starting this thread and for helping to find easy issues
to be worked on.
I'm sympathetic to wanting to have tasks for the PyCon sprints, but at
> the same time it feels exclusionary to "save" them from people who want
> to volunteer at other times. Having paid to attend PyCon
On 21Feb2019 1258, Cheryl Sabella wrote:
I agree completely. We normally add the "Easy" or "Easy (C)"
keywords to
mark these (the latter for issues that involve C code), and these are
collected under the "Easy issues" link at the left hand side of the
tracker.
Any reason
On Thu, Feb 21, 2019 at 6:01 AM Armin Rigo wrote:
> Hi,
>
> On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote:
> > Please don't use _GET_ITEM() or _PyTuple_ITEMS(). It prevents
> > to use a more efficient storage for tuple. Something like:
> >
>
On Thu, Feb 21, 2019 at 9:59 PM Cheryl Sabella wrote:
> I agree completely. We normally add the "Easy" or "Easy (C)" keywords to
>> mark these (the latter for issues that involve C code), and these are
>> collected under the "Easy issues" link at the left hand side of the
>> tracker.
>>
>> Any
>
> I agree completely. We normally add the "Easy" or "Easy (C)" keywords to
> mark these (the latter for issues that involve C code), and these are
> collected under the "Easy issues" link at the left hand side of the
> tracker.
>
> Any reason to change from this process?
>
>
Thanks for asking
+1
> Le 21 févr. 2019 à 21:06, Steve Dower a écrit :
>
>> On 21Feb2019 1117, Barry Warsaw wrote:
>>> On Feb 21, 2019, at 10:34, Raymond Hettinger
>>> wrote:
>>>
>>> I think that anything that raises the cost of filing a bug report will work
>>> to our detriment. Ideally, we want the
On 21Feb2019 0557, Cheryl Sabella wrote:
If you find anything you think is suitable, please add a comment with
'good first issue' and nosy me or Mariatta on it. If you're unsure,
then nosy us anyway. It would be awesome to have too many issues to
choose from than not enough. If an issue
On 21Feb2019 1117, Barry Warsaw wrote:
On Feb 21, 2019, at 10:34, Raymond Hettinger
wrote:
I think that anything that raises the cost of filing a bug report will work to
our detriment. Ideally, we want the barriers to reporting to be as low as
possible.
`python -m reportbug` could make
On 2019-02-21 12:53, Antoine Pitrou wrote:
On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner wrote:
Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C
On Feb 21, 2019, at 10:34, Raymond Hettinger
wrote:
>
> I think that anything that raises the cost of filing a bug report will work
> to our detriment. Ideally, we want the barriers to reporting to be as low as
> possible.
`python -m reportbug` could make the process even easier (too easy?).
On Feb 21, 2019, at 6:53 AM, Stephane Wirtel wrote:
>
> What do you think if we suggest a "template" for the new bugs?
99% of the time the template would be not applicable. Historically, we asked
for more information when needed and that wasn't very often.
I think that anything that raises
Hi,
I wrote "python -m test.pythoninfo", but I wrote it to debug buildbot
failures. It produces a large output. Only very few info are useful,
but previously it was hard to get these info. I wouldn't suggest to
start to request it. Or if you want it, it should be attached as a
file to not pollute
On Feb 21, 2019, at 06:53, Stephane Wirtel wrote:
>
> What do you think if we suggest a "template" for the new bugs?
>
> For example:
> * Python version (exact version)
> * Operating System * on Linux -> Distribution (python can have some patches)
> * Add a script for the reproduction of the
Hello!
Due to the upcoming sprints at PyCon, there will be issues marked in the
bug tracker as 'Good first issues'. Please do *not* submit pull requests
for these as it is difficult to find suitable issues.
Instead of working on these issues, I'd like to propose a much more
difficult challenge
Victor Stinner wrote:
> Premature optimization is the root of all evil. Most C extensions use
> premature optimization which are causing us a lot of troubles nowadays
> when we want to make the C API evolve and cause issues to PyPy which
> has issues to reimplement the C API on top of their
Just letting everyone know that I'm intending to restart this discussion
over in capi-sig, as I feel like I've got an informational-PEP worth of
"vision", "ideas" and "direction" and nomenclature for our C API (*not*
talking about a rewrite, but the principles we should be following
now... and
Hi,
What do you think if we suggest a "template" for the new bugs?
For example:
* Python version (exact version)
* Operating System
* on Linux -> Distribution (python can have some patches)
* Add a script for the reproduction of the bug
* Eventually, try with the docker images (on
Hi,
On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote:
> Please don't use _GET_ITEM() or _PyTuple_ITEMS(). It prevents
> to use a more efficient storage for tuple. Something like:
> https://pythoncapi.readthedocs.io/optimization_ideas.html#specialized-list-for-small-integers
>
> PyPy already
On 2019-02-21 12:18, Victor Stinner wrote:
What I also would like to see is the creation of a group of people who
work on the C API to discuss each change and test these changes
properly.
I don't think that we should "discuss each change", we should first have
an overall plan. It doesn't make
On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner wrote:
> Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
> >
> > On Thu, 21 Feb 2019 12:13:51 +0100
> > Victor Stinner wrote:
> > >
> > > Premature optimization is the root of all evil. Most C extensions use
> > > premature
On Thu, Feb 21, 2019 at 9:23 PM Paul Moore wrote:
>
> On Thu, 21 Feb 2019 at 12:12, Antoine Pitrou wrote:
>
> > Actually, it would be interesting to have some kind of survey of C
> > extensions (through random sampling? or popularity?) to find out why the
> > developers had to write a C
Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C extensions use
> > premature optimization
>
> How do you know it's premature? Some extensions _are_ meant for
On Thu, 21 Feb 2019 at 12:12, Antoine Pitrou wrote:
> Actually, it would be interesting to have some kind of survey of C
> extensions (through random sampling? or popularity?) to find out why the
> developers had to write a C extension in the first place and what their
> concerns are.
Indeed.
Le 21/02/2019 à 12:58, Paul Moore a écrit :
> On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote:
>>
>> On Thu, 21 Feb 2019 12:13:51 +0100
>> Victor Stinner wrote:
>>>
>>> Premature optimization is the root of all evil. Most C extensions use
>>> premature optimization
>>
>> How do you know it's
On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote:
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C extensions use
> > premature optimization
>
> How do you know it's premature? Some extensions _are_ meant for speed.
On 16/02/2019 23:34, Steve Dower wrote:
> I like that we're taking (small) steps to reduce the size of our API.
I consider myself - an "outsider", so an "outsider's" view is that
anything that makes it more clear about what is intended aka supported
as the Python API is an improvement.
Without
On Thu, 21 Feb 2019 12:13:51 +0100
Victor Stinner wrote:
>
> Premature optimization is the root of all evil. Most C extensions use
> premature optimization
How do you know it's premature? Some extensions _are_ meant for speed.
Regards
Antoine.
Hi Eric,
IMHO the main blocker issue for any C API change is that nobody is
able to measure the risk these changes. To better control the risk, I
propose to select a list of popular C extensions, and build a CI to
run their test suite on top of the development version of Python. Such
CI wouldn't
Le mar. 19 févr. 2019 à 21:15, Stefan Behnel a écrit :
> What I would ask, though, and I think that's also Jeroen's request, is to
> be careful what you lock up behind Py_BUILD_CORE. Any new functionality
> should be available to extension modules by default, unless there is a good
> reason why
My focus is AIX - and I believe I found a bug in AIX include files in
64-bit mode. I'll take that up with IBM and AIX support. However, this
issue might also be valid in Python3.
The following is from Centos, not AIX
Python 2.7.5 (default, Jul 13 2018, 13:06:57)
[GCC 4.8.5 20150623 (Red Hat
On 20/02/2019 18:58, Victor Stinner wrote:
> If Python 3.4 was the current version when a bug was reported, I would
> expect the version field of the bug set to Python 3.4. Maybe the bug
> has been fixed in the meanwhile, maybe not. Closing all bugs affected
> to 3.4 is a risk of loosing useful
35 matches
Mail list logo
