[issue14682] Backport missing errnos to 2.7

2012-05-16 Thread Hynek Schlawack
Hynek Schlawack added the comment: This one has been fixed together with #14662 in e12efebc3ba6. Thank you everyone for your input! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Benjamin Peterson
Benjamin Peterson added the comment: I think it's okay to just backport ENOTSUP. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Antoine Pitrou
Antoine Pitrou added the comment: > So what does that mean for issue14662? Backport only ENOTSUP, check > against “45” or “won't fix”? Then, backporting only ENOTSUP would be a reasonable solution. Or perhaps backport it as a private attribute (_ENOTSUP). -- __

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Hynek Schlawack
Hynek Schlawack added the comment: So what does that mean for issue14662? Backport only ENOTSUP, check against “45” or “won't fix”? -- ___ Python tracker ___ __

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Antoine Pitrou
Antoine Pitrou added the comment: That's like introducing a new API, and therefore it should be limited to feature releases. -- nosy: +loewis, pitrou ___ Python tracker ___ ___

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Jesús Cea Avión
Jesús Cea Avión added the comment: Benjamin should talk about this, but I am +1 to backport the missing DEFINEs. In fact, hardwired values are actually a bug, as reported in the linked issue. -- nosy: +jcea ___ Python tracker

[issue14682] Backport missing errnos to 2.7

2012-04-27 Thread Hynek Schlawack
New submission from Hynek Schlawack : In order to fix issue14662, we need to back port at least ENOTSUP to 2.7 (presuming we don’t want to check for magic numbers). The question is, whether we should back port all/most of them when we’re at it? There doesn’t seem to be much harm to it. --