Message150228
| Author |
lars.gustaebel |
| Recipients |
jaraco, lars.gustaebel, python-dev, terry.reedy, vstinner |
| Date |
2011年12月24日.11:12:59 |
| SpamBayes Score |
1.1582918e-10 |
| Marked as misclassified |
No |
| Message-id |
<1324725180.95.0.421405208422.issue13639@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I thought about that myself, too. It is clearly no new feature, it is really more some kind of a fix.
Unicode pathnames given to tarfile.open() are just passed through to the open() function, which is why this always has been working, except for this particular case. There are 6 different possible write modes: "w:", "w:gz", "w:bz2", "w|", "w|gz" and "w|bz2". And the only one not working with a unicode pathname is "w|gz". Although admittedly tarfile.open() is not supposed to be used with a unicode path, people do it anyway, because they don't care, and because it works. The patch does not add a new broad functionality, it merely harmonises the way the six write modes work.
Neither can we retroactively enforce using string pathnames at this point, nor should we let a user run into this strange error. The patch is very small and minimally invasive. The error message you get without the patch is completely incomprehensible. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年12月24日 11:13:01 | lars.gustaebel | set | recipients:
+ lars.gustaebel, terry.reedy, jaraco, vstinner, python-dev |
| 2011年12月24日 11:13:00 | lars.gustaebel | set | messageid: <1324725180.95.0.421405208422.issue13639@psf.upfronthosting.co.za> |
| 2011年12月24日 11:13:00 | lars.gustaebel | link | issue13639 messages |
| 2011年12月24日 11:12:59 | lars.gustaebel | create |
|