[issue7017] os.listdir behaviour

New submission from Chris Adamson : When I iterate through a list created using os.listdir it seems to grow as I create files in that directory. I want a static copy of the list of files in the directory prior to me writing new files into it. Here is my code: fileList = os.listdir(temporaryDire

[issue7014] Logging incompatible with IronPython

Vinay Sajip added the comment: Fix checked into trunk and release26-maint. Please verify. Note - the problem is not just to do with availability of sys._getframe in Python - it's actually because sys.exc_traceback.tb_frame.f_back is None (even though sys.exc_traceback.tb_frame is a frame object

[issue7012] Tabs is better than spaces for indentation

Rohde Fischer added the comment: > Python started out using tabs, for some of the reasons you elaborate. > Years of practical experience have shown that using tabs causes pain. > Our recommendation is not going to change. I can't actually see why this should be the case, could you please enligh

[issue7008] str.title() misbehaves with apostrophes

Marc-Andre Lemburg added the comment: Guido van Rossum wrote: > What's a realistic use case for .title() anyway? The primary use is when converting a string to be used as title or sub-title of text - mostly inspired by the way English treats titles. The implementation follows the rules laid ou

[issue7005] ConfigParser does not handle options without values

Mats Kindahl added the comment: Adding patch with the changes requested by Fred. -- Added file: http://bugs.python.org/file14993/cfgparser-2.patch ___ Python tracker ___

[issue7008] str.title() misbehaves with apostrophes

Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > > Regarding the apostrophe: the Unicode standard doesn't appear to > include any rule regarding that character and its use in titles > or upper-case versions of text. The apostrophe itself is a > non-cased code point. > > It's l

[issue7008] str.title() misbehaves with apostrophes

Ezio Melotti added the comment: > Patches to enhance the code to support those additional rules are welcome. #6412 has a patch. -- assignee: -> gvanrossum ___ Python tracker __

[issue7008] str.title() misbehaves with apostrophes

Antoine Pitrou added the comment: > To make things even more complicated, the usual typewriter apostrophe > that you find in ASCII is not the only one in Unicode: > > http://en.wikipedia.org/wiki/Apostrophe#Unicode Yup, and the right one typographically isn't necessarily the ASCII one :-) That

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

Marc-Andre Lemburg added the comment: The patch looks good, but it doesn't include the few extra characters that are also considered case-ignorable: * U+0027 APOSTROPHE * U+00AD SOFT HYPHEN (SHY) * U+2019 RIGHT SINGLE QUOTATION MARK Could you add those as well ? Thanks. -- nosy: +lem

[issue7008] str.title() misbehaves with apostrophes

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti added the comment: > >> Patches to enhance the code to support those additional rules > are welcome. > > #6412 has a patch. That patch looks promising. -- ___ Python trac

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

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 hardcoded (see below) I hardcoded some characters into Tools/unicode/makeunicode

[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

[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 >

[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

[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 ___

[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 ___ _

[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

[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

[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

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

[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

[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

[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

[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

[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. --

[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

[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

[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

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

[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

[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: > 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: 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: > 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: > 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

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: > 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

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

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

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

[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: > 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

[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.

[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

[issue7008] str.title() misbehaves with apostrophes

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

[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

[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

[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 ___

[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

[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 __

[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

[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? --

[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: 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

[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

[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

[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.

[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 ___ __

[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: 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

[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: 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 ___

[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:

[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 ___ __

[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 _

[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

[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

[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

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 ___ _

[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

[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 ___ _

[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

[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

[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 ___ ___

[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

[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

[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

[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

[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

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

[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

[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

[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. --

[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 ___ __

[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

[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 ___ _

[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

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: 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

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

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 __

[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

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

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

[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 <

[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 ___ ___

[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 __

[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

[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

[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

  1   2   >