The JSON module’s core features are fairly straightforward.
Why should it take a third-party module to serialize and deserialize yaml files ?
How about including pyyaml, which seems pretty popular, to do that job in the standard library ?
I found no issue or thread in this topic about this and I’m very surprised.
Welp, if you keep moving topics about improvement ideas to the help section for no reason, don’t be surprised if people don’t find them and open new threads every four days.
I don’t need help with handling yaml files, I can do that with the library I mentioned, so this has nothing to do with the help section.
Thanks for the link though.
While YAML is a widely used format, it’s spec is incredibly complex and I’m not sure that maintenance burden would want to be taken on. Go has had a similar conclusion in the past: proposal: encoding/yaml: Add YAML support in the standard library · Issue #61023 · golang/go · GitHub
Oh, I didn’t know that. I expected a sort of indent-driven JSON with comments, but looking into it, it does seem quite intricate 
Me moving this topic is the result of a recent discussion that the Ideas section is getting filled with incomplete ideas that don’t show the necessary research being done beforehand. Essentially Ideas is for at least “half-finished” proposals, which this is not.
A few basic research pointers:
is another discussion of this (but I have no idea where the starting point of this thread is)
Well in this particular case, the previous thread being moved away lead to this useless thread being created - because when looking whether the idea had been proposed before, I had no interest in reading about people asking in Help for how to use pyyaml. So despite your (plural) initial goal of draining the ideas section, you may create more posts polluting the Discourse overall.
And also, this proposal is not “half-finished”. It may be bad for reasons that are simple to explain, but if you set yourself to “implementing a json-like yaml library in the stdlib” or “including pyyaml in the stdlib”, there’s no real wiggle room, it’s a pretty straightforward idea.
@MegaIng I will say, this post doesn’t really seem like it is asking for “help”, so I can see why there would be pushback, as I don’t think everyone will have that context and it may not intuitively make sense to be put in “help”. I think the distinction between what is a “finished” idea proposal is going to be a bit of an arbitrary distinction and my concern there is that presenting an unwelcoming front if someone doesn’t follow the unspoken rules of what is “finished”. Purely my 2 cents as a random person on the internet 
Read the thread I linked. The Python Help topic is sadly misnamed, it’s the general section of this website.
Absolutely, and that doesn’t make the idea itself half-finished, it only made the discussion not-started.
And whose fault is that ?
The description of the Ideas section is:
Would you like to change something in Python? This might be your feedback forum.
So how would anyone be expected to look into the Help section, or the Pyyaml issues tracker of all places (?), for something that exactly fits the description of Ideas ?
Even if the Help section were renamed to “Discussions”, it contains so much unrelated stuff, stuff that aren’t improvement ideas for Python, that I would filter it out anyway.
The thread you mentioned introduces a “Pre-ideas” section, and later revolves around a “Proto-ideas” vs “Proper ideas” sections. But until this exists, using Help as an overflow is the worst possible organization, it wastes everyone’s time : the users of Ideas who don’t see the previous arguments and write useless threads, the mods who need to triage the threads, and Help users who get even more flooded than before.
I’ll be providing feedback on that thread.
It seems like you’re not looking to make any changes—that’s my takeaway from this thread. Your main question is about why x isn’t in the standard library, which is a topic for Python Help.
That’s not what I meant (“How about” is a proposition), but I see what lead you there. And I do ask questions.
The main problem though, is that the earlier thread should have stayed in Ideas in the first place.
I can’t stress this enough: it’s you who is willing to make the change, and we will leave our feedback about it. We are all contributors here.
And Python Help is the right place for the aforementioned thread and this thread. If the conclusion is that the x library should be in the standard library, then you (or whoever is willing to make the change) need to create another thread in Ideas, explaining the whole process.
Eureka! Let’s add the x library to the standard library. It’s an idea per se, but I don’t think that Ideas is about that, based on its description.
Is it not a change in Python ? So how does it not fit the description ?
You seem to be mixing up the Ideas threads and a PEP. The discussion whose conclusion is whether or not and how x should be added to the standard library, is precisely what Ideas is for.
How can we include it? Through forking? What is the process of inclusion?
Who cares ? Those are the last things to wonder about when adding something to the stdlib. What’s relevant is typically whether there would be sufficient use for it (probably), whether there’s a benefit for it being in the stdlib (possibly), and whether an implementation can be found (sure) and later maintained (meh). And whether all that balances against the maintenance burden it adds for contributors (it doesn’t).
All of that is what’s discussed in Ideas, as is its place.
@moderators, I think we can either slow this thread down, or close it (the discussion is already way off-topic)