Paul Moore writes:
> [S]ubjecting a newcomer to the need to [deal with extra
> requirements from other participants] right up front isn't exactly
> fair or helpful.
But avoiding that is what core-mentorship is for. Perhaps we can
advertise that list better, and maybe more people can mentor there.
But a proposal that comes to Python-Ideas is going to be presumed the
object of public discussion for the benefit of Python, not mentorship
for the benefit of newcomers (and in the long run for Python). People
will have their say, and much of that will be pretty abrupt from this
point of view. I don't think it's a good idea to impede discussion.
> But people *think* of ideas because they hit a problem of their
> own. And they come here out of a sense that sharing a possible
> solution would help the community. It's not very encouraging if
> they get treated as if they are simply saying "solve my problem for
> me".
I don't think I've seen that as a matter of general attitude (though I
have seen it said explicitly to obnoxiously pushy would-be
contributors or people clearly unwilling or unable to do the work
themselves, but unwilling to take "maybe" or "later" or "no" for an
answer). Definitely, new contributors get asked why their problem is
so important it needs to be in the stdlib or language, but they also
get help with that ("what are *your* use cases? are there others that
you know of? is the three-line implementation easy to get wrong for
some reason?" And closest to "solve my problem for me" is "is this
the only specification, or would other use cases prefer a different
one?")
My feeling is that very few contributors originally come to give to
Python what it needs. They're here to give what they need to Python.
There's nothing wrong with that. Very often it's a shared need. But
as you point out, there are often other requirements, and the bar is
higher than many projects. I don't think it's possible to pretend
that's not true, outside of mentoring environments.
> We probably need to get better at helping such people to polish
> their ideas, *without* focusing too heavily on their original
> problem (or worse still, on criticising their original solution of
> that problem). The original problem is the initial use case for a
> new feature, of course, but focusing on "how does your original
> problem generalise, so we can see what common features a solution
> should have"
In a word, we need to be prepared to mentor every newcomer. Would be
nice, but I don't think it's practical.
In fact, I think this thread is one where the discussion went about as
you say you would want it to. That is, we fairly quickly focused on
the issue of precisely representing all valid JSON (specifically
high-precision numbers), it got generalized to __json__ to handle not
only Decimal but user-defined types. Then it was pointed out that the
generated language will be valid ECMA 434 JSON with no way to specify
how to convert back to to the original Python types, so Wes suggested
JSON-LD. The general response to that was "nope, nope! out of scope!"
(for now, anyway), so the proposal reverted to "implement simplejson's
use_decimal API", and now it's pretty much tabled as the OP has
decided simplejson is sufficient for his purposes. The main problem
was at the very start where we hung up on the red herring of
round-tripping JSON, which I agree went on too long, and was in large
part extended by Python-Ideas regulars, not the OP.
I guess the main takeway for me is avoiding the red herring. The
principle is something pretty straightforward like "find something
Python can't do, is doing wrong, or really should provide more
performance, in the original issue, and don't discuss how weird the
use case is." Even if weird, it's probably simplified and taken out
of context. Focus on how it indicates Python can be improved. If
there seems to be a TOOWTDI already, describe it and ask if it
satisfies the need and if not, why not.
> rather than on "why do you think your problem is important enough
> to need solving in the core language/stdlib" (I exaggerate
> somewhat, but sadly I suspect not a lot :-() would be a much more
> welcoming approach.
The question "why is it important enough?", like most of the points
you raise, often exposes a genuine point of difference between the
patch the Python project needs, and the proposals of many would-be new
contributors. I don't see a way to avoid that discussion, because
it's the fundamental reason why we insist on finding use cases, and it
underlies the rationale for generalization and finding commonalities.
Maybe we can find more pleasant ways to ask that question, but I don't
think it's fair to the contributor or to the Python-Ideas regulars to
do much work without asking it in some variation or other.
Steve
_______________________________________________
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 at
https://mail.python.org/archives/list/python-ideas@python.org/message/KYS3NZLEFVDE6TZAXW2QXQFPUJ4MFLA2/
Code of Conduct: http://python.org/psf/codeofconduct/
