[issue7022] Doc update for io module

New submission from Pascal Chambon : *Propositions of doc update* *RawIOBase*.read(n: int) -> bytes Read up to n bytes from the object and return them. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If 0 bytes are returned, and n was not 0, this indi

[issue4192] Subprocess error with I/O redirection to Pipes

Changes by Pascal Chambon : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue7020] regression in pywin32 build due to 2.6.3rc1

Sridhar Ratnakumar added the comment: Replacing the distutils packages with the Lib/distutils from 2.6.2 fixed the issue. So this was introduced by a change in distutils. Tarek, any insight into this issue? -- ___ Python tracker

[issue7020] regression in pywin32 build due to 2.6.3rc1

Sridhar Ratnakumar added the comment: Quite note: I am able to repro this freshly using pywin32 212 version. http://sourceforge.net/projects/pywin32/files/pywin32/Build%20212/ pywin32-212.zip/download (214 goes past the copying part, but I could not complete the build to some missing executab

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: My apologies, I clicked the wrong button and deleted my test. There is no change in the newly uploaded one. -- Added file: http://bugs.python.org/file15005/zipfile-6972-test.diff ___ Python tracker

[issue6972] zipfile.ZipFile overwrites files outside destination path

Changes by Thomas W. Barr : Removed file: http://bugs.python.org/file15002/zipfile-6972-test.diff ___ Python tracker ___ ___ Python-bugs-list m

[issue7020] regression in pywin32 build due to 2.6.3rc1

Ned Deily added the comment: Is this a release blocker problem for 2.6.3? -- nosy: +barry, ned.deily ___ Python tracker ___ ___ Python

[issue7021] subprocess.Popen doesn't work without "executable="

Konstantin M. Khankin added the comment: Sorry, it's my fault. I must write it as list, not as string -- status: open -> closed ___ Python tracker ___ ___

[issue7021] subprocess.Popen doesn't work without "executable="

Konstantin M. Khankin added the comment: And I still can't make it works. Now sendmail is called but says that "Recipient addresses must be specified on the command line or via the - -- ___ Python tracker _

[issue7005] ConfigParser does not handle options without values

Fred L. Drake, Jr. added the comment: I just looked at some MySQL configuration examples, and wonder if the guys that made that configuration-style choice were on crack. MySQL's syntax is sufficient justification for this feature (however abhorrent I consider it). (I've not read the patch.) -

[issue7021] subprocess.Popen doesn't work without "executable="

New submission from Konstantin M. Khankin : I'm need to call sendmail. So I wrote: http://paste.org.ru/?imuoia os.stat there is to confirm that python can have access to sendmail executable That code returned an exception: http://paste.org.ru/?jbxadp But documentation says, that I can write execu

[issue6186] test_thread occasionally reports unhandled exceptions on OS X

Ned Deily added the comment: Also seen on Python 2.6.3rc1. -- versions: +Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue7020] regression in pywin32 build due to 2.6.3rc1

Sridhar Ratnakumar added the comment: Note the line: /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd In 2.6.2, it was: /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes26.dll -- ___ Python tracker

[issue7020] regression in pywin32 build due to 2.6.3rc1

New submission from Sridhar Ratnakumar : Today's 2.6.3rc1 introduced an regression in building pywin32. Peruse the following error: = creating build\lib.win32-2.6\pywin32_system32 C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe

[issue7017] os.listdir behaviour

Chris Adamson added the comment: I think I found my problem. Since I didn't *COPY* the array that I created with os.listdir I was actually appending to it, my bad. -- status: pending -> closed ___ Python tracker __

[issue6071] no longer possible to hash arrays

Antoine Pitrou added the comment: > I would prefer if I opened a separate issue for this bug. if /you/ opened, of course... -- ___ Python tracker ___ ___

[issue6071] no longer possible to hash arrays

Antoine Pitrou added the comment: > I fixed the array_ass_slice for python 2.7 in the attached patch. I would prefer if I opened a separate issue for this bug. That way it will be easier to port the patch separately to py3k. -- ___ Python tracker <

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen added the comment: I wonder if there is any way to test this, aside from the tests that are already in the test suite? The bug here is that the code effectively does a blocking read on a non-blocking socket, and we can't tell the difference. The fact that this patch passes all the

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: zf.extract() is unsafe for the same reason. My patch fixes this issue, but we should mention the possible bug in the documentation there as well. They do this for the similar bug in tarfile. I've copy/pasted the mention in tarfile.extract() to zipfile.extract()

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Barry A. Warsaw added the comment: Not gonna make it for 2.6.3rc1 -- priority: release blocker -> high ___ Python tracker ___ ___ Pyth

[issue6972] zipfile.ZipFile overwrites files outside destination path

Gregory P. Smith added the comment: Documentation note added (copied from tarfile) in trunk r75149, release26-maint r75150 (hopefully in time for 2.6.3 but thats up to Barry). -- ___ Python tracker __

[issue6972] zipfile.ZipFile overwrites files outside destination path

R. David Murray added the comment: Patches to the docs, just like patches to the code (the docs are in the Doc subdirectory). Once committed, they get auto-generated and uploaded. -- nosy: +r.david.murray ___ Python tracker

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: As for the documentation, it might be a wise idea to up date the current documentation to mention this issue, until the next release. I'm not really sure what the process is for doing that, though... -- ___ Python tr

[issue6972] zipfile.ZipFile overwrites files outside destination path

Changes by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith priority: -> normal ___ Python tracker ___ ___ P

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: Uploading patch. This actually should fix my theoretical symlink bug since realpath() properly follows symlinks. The only thing that I haven't been able to test is the behavior of realpath() on case-insensitive operating systems. This should do the right thing,

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: Uploading test. -- keywords: +patch Added file: http://bugs.python.org/file15002/zipfile-6972-test.diff ___ Python tracker ___ _

[issue1759169] clean up Solaris port and allow C99 extension modules

Zooko O'Whielacronx added the comment: In msg82274 MvL wrote: "I can grudgingly accept removal of _XOPEN_SOURCE on Solaris 5.{9,10,11} (?), to work-around this system limitation." Great! That's what the attached patch does. So please apply that patch and then people can stop coming to this ti

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Barry A. Warsaw added the comment: We'll need tests to include it in 2.6.3. -- priority: high -> release blocker ___ Python tracker ___ __

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Giampaolo Rodola' added the comment: You're very welcome. My only concern is about the blocking environment. If someone is able to confirm that those exceptions aren't raised with blocking sockets then modifying the patch is very trivial and maybe we could even make it for 2.6.3. --

[issue1625] bz2.BZ2File doesn't support multiple streams

David Bonner added the comment: sorry, the previous patch was from an old version. attaching the correct version now. apologies for the noise. -- Added file: http://bugs.python.org/file15001/bz2_patch.tar.bz2 ___ Python tracker

[issue1625] bz2.BZ2File doesn't support multiple streams

Changes by David Bonner : Removed file: http://bugs.python.org/file15000/bz2_patch.tar.bz2 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Barry A. Warsaw added the comment: Thanks for the feedback Giampaolo. It sounds like this patch is not yet fully baked so I'll defer it to Python 2.6.4. -- priority: release blocker -> high ___ Python tracker

[issue1759169] clean up Solaris port and allow C99 extension modules

Changes by Skip Montanaro : -- nosy: +skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Changes by Sridhar Ratnakumar : -- nosy: +srid ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Giampaolo Rodola' added the comment: Uhm... I'm sorry but actually I'm not sure about this patch anymore. Now that I look at ssl.py again I'm noticing that send() is trapped in a "while True" loop as well and the patch doesn't cover it. Not sure if that has been added recently or it was alread

[issue1625] bz2.BZ2File doesn't support multiple streams

David Bonner added the comment: I've got a patch that fixes this. It allows BZ2File to read multi-stream files as generated by pbzip2, allows BZ2File to open files in append mode, and also updates bz2.decompress to allow it to handle multi-stream chunks of data. We originally wrote it against

[issue6957] Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x

Ronald Oussoren added the comment: Committed in r75147 (trunk) and r75148 (2.6) -- status: open -> closed ___ Python tracker ___ ___ P

[issue6957] Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x

Barry A. Warsaw added the comment: Please apply this for 2.6.3rc1 -- priority: -> release blocker resolution: -> accepted ___ Python tracker ___ ___

[issue6071] no longer possible to hash arrays

Jan Hosang added the comment: I fixed the array_ass_slice for python 2.7 in the attached patch. The problem should apply to python 3k as well: firstly the above which might stay unnoticed and secondly the function moves to much memory if the array size is increased: (Py_SIZE(a)-d-ihigh) items

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: Fixed in r75141 (trunk), r75145 (py3k) and r75146 (release31-maint). I'll apply the 2.6 fix once the release26-maint branch is unfrozen. -- versions: -Python 2.4, Python 2.7, Python 3.1, Python 3.2 ___ Python trac

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

Philip Jenvey added the comment: applied in r75143/r75144, in time for 2.6.3. thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ _

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Barry A. Warsaw added the comment: Gaimpaolo thanks. Please give it a try. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Giampaolo Rodola' added the comment: I could give it a try but I'm not sure I'll be in time for 2.6.3 release. -- ___ Python tracker ___ _

[issue6790] httplib and array do not play together well

Antoine Pitrou added the comment: Committed in r75134, r75135, r75137, r75142. Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Barry A. Warsaw added the comment: I'd like to accept this for 2.6.3, but I'd also really like a test for this change. Giampaolo, do you think you could whip up a test for this. I know it's short notice. -- ___ Python tracker

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

Changes by Barry A. Warsaw : -- assignee: -> pjenvey keywords: -needs review resolution: -> accepted ___ Python tracker ___ ___ Pyth

[issue6108] unicode(exception) behaves differently on Py2.6 when len(exception.args) > 1

Barry A. Warsaw added the comment: Since we do not yet have a patch for this, I'm knocking it off the list for 2.6.3. It seems like an annoying loss of compatibility, but do we have any reports of it breaking real-world code? -- nosy: +barry priority: release blocker -> high _

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Antoine Pitrou added the comment: Of course, I had forgotten to rebuild :-/ Sorry for the noise. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ __

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Antoine Pitrou added the comment: I get the following failure on py3k: test test_threading_local failed -- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/test/test_threading_local.py", line 107, in test_derived_cycle_dealloc self.assertTrue(passed) AssertionError:

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: Changing versions: 3.1 and 3.2 also need fixing (the trunk patch should be easily mergeable); it's not a security issue (AFAIK), so won't be fixed in 2.5. -- priority: -> normal versions: +Python 3.1, Python 3.2 -Python 2.5 ___

[issue6071] no longer possible to hash arrays

Jan Hosang added the comment: I was looking at the remaining differences between Modules/arraymodule.c in python 2.7 and the 3k branch, in particular I was testing why including the changes to the function array_ass_slice into the patch breaks the unit test of the array module. The manual re

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: And a patch for trunk. (Significantly different, because marshal for Python longs was reworked when 30-bit long digits were added.) -- Added file: http://bugs.python.org/file14998/issue7019_trunk.patch ___ Python t

[issue7014] Logging incompatible with IronPython

Michael Foord added the comment: Works for me - thanks Vinay. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: Here's a patch for Python 2.6. -- keywords: +patch Added file: http://bugs.python.org/file14997/issue7019_26.patch ___ Python tracker ___ __

[issue6790] httplib and array do not play together well

Changes by Antoine Pitrou : -- assignee: -> pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue6972] zipfile.ZipFile overwrites files outside destination path

Thomas W. Barr added the comment: My working solution is to iterate through members, and ensuring that os.path.abspath(os.path.join(path, member)) always .startswith(path). This seems like a better solution than trying to trap on a pattern in the string. Presumably the same fix can be made to ta

[issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5

Philip Jenvey added the comment: Here's the doc change with a lil more clarification, and I've also applied it to the module's own docs -- Added file: http://bugs.python.org/file14996/subprocess-conversion-doc2.patch ___ Python tracker

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: On second thoughts, I think Carl was right in the first place: it's better to raise an exception. If marshal.loads is getting input that doesn't precisely match the marshal.dumps format, then something's wrong somewhere. Looks like we missed the window for

[issue7019] unmarshaling of artificial strings can produce funny longs.

Changes by Eric Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: So there are two options: (1) raise an exception, or (2) strip leading zero digits and produce a properly normalized Python long. Do you have any strong preferences? I'm inclined towards (2). How did you encounter this in the first place? --

[issue6990] threading.local subclasses don't cleanup their state and it gets recycled

Changes by Antoine Pitrou : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue6071] no longer possible to hash arrays

Barry A. Warsaw added the comment: Moving to deferred blocker to get this out of the way for 2.6.3 -- nosy: +barry priority: release blocker -> deferred blocker ___ Python tracker __

[issue1759169] clean up Solaris port and allow C99 extension modules

Tim Flechtner added the comment: Hi. I think I'm running into the problem discussed in this ticket. I'm trying to build pycairo-1.8.8 on Solaris 10 (x86) against python-2.6.2 using gcc-4.4.1. I'm afraid I'm out of my depth in understanding really what's going on, but the error I get looks lik

[issue7019] unmarshaling of artificial strings can produce funny longs.

Carl Friedrich Bolz added the comment: Yes, I know :-). I thought I'd report it anyway, as it does more than "just" give you random behavior, but actually produces a broken object. -- ___ Python tracker ___

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson added the comment: Thanks for the report; I'll take a look. Though in general, I think this comes under the heading of 'Don't do that, then.' I suspect there are many ways to produce odd behaviour by feeding malformed input to marshal. See the big pink boxes at: http://docs.p

[issue6992] Adding a Contributor field in PEP 314

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: > > Tarek Ziadé added the comment: > >> In order to clear up the inconsistency with maintainer >> not being a possible meta-data field, I think "Maintainer" >> should be added to the meta-data. Dito for "Maintainer-EMail". > > Do you

[issue7008] str.title() misbehaves with apostrophes

Changes by Guido van Rossum : -- assignee: gvanrossum -> nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue7019] unmarshaling of artificial strings can produce funny longs.

Changes by Carl Friedrich Bolz : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue7012] Tabs is better than spaces for indentation

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: > In order to clear up the inconsistency with maintainer > not being a possible meta-data field, I think "Maintainer" > should be added to the meta-data. Dito for "Maintainer-EMail". Do you remember what's the story behind those two fields ? I am not sure about

[issue7019] unmarshaling of artificial strings can produce funny longs.

New submission from Carl Friedrich Bolz : When unmarshalling a hand-written string it is possible to break the invariants of longs: Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = marshal.l

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: > A metadata system, by definition, has to remain reasonably stable > (or be version-numbered, such that old metadata can be recognized properly). That's already the case. We have 1.0 and 1.1. 1.1 is used if you add fields like "obsoletes". > You can certainl

[issue6992] Adding a Contributor field in PEP 314

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: > > Tarek Ziadé added the comment: > >> We already have authors and maintainers (which causes confusion), >> adding yet another field for contributors is overkill, > > Not on the Metadata side though. That's only on setup() side. The

[issue6992] Adding a Contributor field in PEP 314

Antoine Pitrou added the comment: > I am bothered that more and more are people constantly jumping on my > back everytime I try to make Distutils evolves a bit or everytime I > discuss some feature proposals with the community. This is not "jumping on your back", this is being skeptical about a

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: > We already have authors and maintainers (which causes confusion), > adding yet another field for contributors is overkill, Not on the Metadata side though. That's only on setup() side. The resulting metadata only contains "Author" and "Author-email", and it's c

[issue6992] Adding a Contributor field in PEP 314

Marc-Andre Lemburg added the comment: Most of the meta data is parsed by humans, so I don't see any complication with adding multiple authors to the author field using standard email format: "Anatoli , Tarek ". We already have authors and maintainers (which causes confusion), so adding yet anot

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: > What does changing the type of the "author" field make clearer exactly? It "Author" not "Authors", that's the difference. Like we have "Classifiers" and not "Classifier". Plus, I am not breaking any compatibility here. A multi-value field in the metadata in D

[issue6992] Adding a Contributor field in PEP 314

Antoine Pitrou added the comment: > Replacing the author/author_email/maintainer/maintainer_email mess with > a single authors argument, that fills a multi-valued "Author" metadata > field make it clearer. What does changing the type of the "author" field make clearer exactly? It is a field for

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: The metadata are completely messy. Users are already confused. For instance, since the metadata fields are not fully corresponding to the argument names you can pass into setup.py, you can have an "author" and a "maintainer" argument and Distutils will put only th

[issue6992] Adding a Contributor field in PEP 314

Antoine Pitrou added the comment: > What about having a "Contact-email" then that would replace the > "Author-email" field, and an "Author" multi-valued field as described > previously. Why do we have to add new fields and deprecate others? Just for the sake of confusing users and breaking exis

[issue6992] Adding a Contributor field in PEP 314

Tarek Ziadé added the comment: What you are saying is that a project should have one and only one contact email. What Anatoly says is that a project should be able to have several authors. What about having a "Contact-email" then that would replace the "Author-email" field, and an "Author" mult

[issue6992] Adding a Contributor field in PEP 314

Antoine Pitrou added the comment: The good pratice, if there are several authors, is to setup a mailing-list (and put its address as official contact address). Otherwise collaboration gets inevitably messy, since authors can get contacted in private randomly. I don't think we should multiply th

[issue7016] .pyc files are set executable if the .py file is too

R. David Murray added the comment: This is a duplicate of issue 6070, and has been fixed. -- nosy: +r.david.murray priority: -> normal resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> Python 2.6 makes .pyc/.pyo bytecode files executable

[issue7015] Getting call trace while executing "modules spam" at help prompt

Antoine Pitrou added the comment: It's a problem with one of your installed modules. I don't think Python can do anything, unless you propose silencing all errors. -- nosy: +pitrou ___ Python tracker __

[issue7016] .pyc files are set executable if the .py file is too

Skip Montanaro added the comment: Steven> $ echo pass > test.py Steven> $ chmod u+x test.py Steven> $ python2.6 -c "import test" Steven> $ ls -l test.pyc Steven> -rwxrw-r-- 1 steve steve 94 2009-09-29 16:54 test.pyc Steven> $ ./test.pyc Steven> : command not found And

[issue7012] Tabs is better than spaces for indentation

Tim Peters added the comment: I understand you're annoyed, but the bug tracker is not the place to rehash arguments that were settled a decade ago. If you need to pursue this, please take it to the newsgroup comp.lang.python. Before you do, you might want to scour the newsgroup's archives, as

[issue7018] Recommend "*" over "#" in getargs.c typecodes

Antoine Pitrou added the comment: This only really applies in 2.x, actually. In 3.x, "#" should be discouraged for another reason: it is overly strict and will only accept pure read-only objects (which don't have a bf_releasebuffer method); even bytearrays will be rejected. --

[issue6972] zipfile.ZipFile overwrites files outside destination path

Amaury Forgeot d'Arc added the comment: The tarfile module solved this issue with a documentation warning: http://docs.python.org/library/tarfile.html#tarfile.TarFile.extractall -- nosy: +amaury.forgeotdarc ___ Python tracker

[issue7008] str.title() misbehaves with apostrophes

Christoph Burgmer added the comment: Antoine Pitrou wrote: > capwords() itself could be deprecated, since it's an obvious one- > Replacing in with another method, however, will just confuse and annoy > existing users. Yes, sorry, I meant the semantics, where as you are right for the specific fu

[issue7018] Recommend "*" over "#" in getargs.c typecodes

New submission from Antoine Pitrou : In « Parsing arguments and building values » (c-api/arg.html), it should be made clear that "*" typecodes are recommended over the "#" typecodes, which are inherently unsafe. (more generally, the page is totally unreadable, a solution might be to group the ty

[issue6071] no longer possible to hash arrays

Antoine Pitrou added the comment: After thinking about it, we should remover the bf_releasebuffer checks when using the old typecodes '#' (the doc should also clearly state that these are unsafe and '*' is preferred). If a type chooses to implement the /old/ buffer API and if a method requires

[issue7008] str.title() misbehaves with apostrophes

Marc-Andre Lemburg added the comment: Christoph Burgmer wrote: > > Christoph Burgmer added the comment: > > I admit I don't fully understand the semantics of capwords(). string.capwords() is an old function from the days before Unicode. The function is basically defined by its implementation

[issue6412] Titlecase as defined in Unicode Case Mappings not followed

Christoph Burgmer added the comment: New patch - updated comments to reflect needed integration of DerivedCoreProperties.txt - cleaned up if(...) construct - updated (from issue7008) and integrated testcase When applying this patch, run Tools/unicode/makeunicodedata.py to regenerate the h

[issue7008] str.title() misbehaves with apostrophes

Antoine Pitrou added the comment: > This algorithm should be implemented anyway, to properly solve > issue6412. Sure, but it should be another function, which might have its place in the wordwrap module. capwords() itself could be deprecated, since it's an obvious one-liner. Replacing in with

[issue7008] str.title() misbehaves with apostrophes

Christoph Burgmer added the comment: I admit I don't fully understand the semantics of capwords(). But from what I believe what it should do, this function could be happily replaced by the word-breaking algorithm as defined in http://www.unicode.org/reports/tr29/. This algorithm should be imple

[issue6790] httplib and array do not play together well

Antoine Pitrou added the comment: issue6790-python2.6.diff is ok, can you commit to trunk and then merge? -- resolution: -> accepted ___ Python tracker ___ _

[issue6972] zipfile.ZipFile overwrites files outside destination path

Ralf Schmitt added the comment: The documentation should also mention that it's unsafe to use this method in python <= 2.6.2. 2.6.2 is also unsafe. -- ___ Python tracker ___

[issue6972] zipfile.ZipFile overwrites files outside destination path

Ralf Schmitt added the comment: I think this should clearly be fixed in the code. The current code tries to handle absolute paths by removing the first slash (unfortunately not the second), so it looks like it tries to be safe and only write to the destination directory. That should be the defau

[issue6412] Titlecase as defined in Unicode Case Mappings not followed

Marc-Andre Lemburg added the comment: Christoph Burgmer wrote: > > Christoph Burgmer added the comment: > >> * U+0027 APOSTROPHE > hardcoded (see below) >> * U+00AD SOFT HYPHEN (SHY) > has the "Format (Cf)" property and thus is included automatically >> * U+2019 RIGHT SINGLE QUOTATION MARK >

[issue7017] os.listdir behaviour

Mark Dickinson added the comment: What's 'FileList' in your code? (It's not the same as 'fileList', since Python identifiers are case sensitive.) What's 'temporaryDirectory'? Please could you cut and paste an executable code snippet that exhibits the problem, along with any other instructions

  1   2   >