[issue7017] os.listdir behaviour

[Chris Adamson]

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(temporaryDirectory)

for curFile in fileList:
   # print the file list to see if it is indeed growing
   print FileList
   fp = file(os.path.join(temporaryDirectory, "." + curFile), 'w')
   # write stuff
   fp.close()

Here is the output:

['a', 'b', 'c']
['a', 'b', 'c', '.a']
['a', 'b', 'c', '.a', '.b']
['a', 'b', 'c', '.a', '.b', '.c']

So the list is growing and eventually curFile iterates through the list
of files that were created. This behaviour was unwanted in my case and I
couldn't find any documentation about this.

--
components: None
messages: 93255
nosy: bigaddo
severity: normal
status: open
title: os.listdir behaviour
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7014] Logging incompatible with IronPython

[Vinay Sajip]

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) when
-X:Frames is not specified with IronPython.

The "fix" in CodePlex work item 24714 would be suboptimal, because frame
information would be unavailable even if -X:Frames were to be specified.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7012] Tabs is better than spaces for indentation

[Rohde Fischer]

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 
enlighten me here?

> > Then some of the arguments I've heard is that some editors shows
> > tabs badly, although true, then most proper editors it's possible
> > to adjust that to your personal preference
> That is no option for Python. In Python, it is part of the LANGUAGE
> SYNTAX that a tab is 8 columns. Changing that may change the very
> meaning of a Python program (i.e. an editor configured to four column
> tabs may render a program to MEAN something different than when
> formatted to eight column tabs).
I fail to see that this is possible, simply from the following reason 
(space after \t added for readability)
if a > In a program with 200 lines of code we have roughly 600 extra
> > keystrokes with spaces, unless using a proper editor which shows
> > tabs nicely.

> I think you should get a different editor then. I press tab in my
> editor and still get four spaces.
Ok I though I managed to make it clear that I know the possibilities of 
editors, but ok. I'm perfectly aware of that possibility, but so far 
I'm not interested. I see no reasons for spaces apart from making a lot 
of things harder without benefits (I still fail to see any benefit)

> > Tabs use less space, which is usable when uploading and downloading
> > code a lot (which you do when using version control).

> That's negligible, compared to the rest of the file.

Might be true, but with the present speed of most free svn server even 
little gained is useful. I'm actually disappointed of how bad their 
download is (just in case someone wonders: I have tested my upload)

> Wow. You (rohdef) really do sound like you are a time capsule from
> the eighties. Tabs would save keystrokes and bandwidth, and are not
> confusing? The keystrokes argument is wrong for most editors;
I'm aware (I'm surprised that it's unclear from what I wrote that I'm 
aware of the most basic capabilities of an IDE, but ok that's besides 
the point), but I'm probably not the only one in the world being forced 
to work on crappy editors from time to time, even though I try to avoid 
it.

> the bandwidth argument doesn't matter due to disk size, network
> speed, and compression;
Although it might not be much I still feel that it's a waste, but as 
far as I see this is the only point where I'm like a time capsule from 
the 80's. But still even little saved matters when using SF og Google 
Code for svn (I was a bit shocked on how slow they are, and to be 
honest I use another that's nice and fast in stead).

> and the confusion is absolutely real.
But none has pointed it out yet, the only confusion I've seen so far is 
from people having contradicting beliefs on the tabs vs spaces. So far 
I've never seen a reason to change my opinion, since I've only seen 
spaces as trouble.

> Pretty much every time I volunteer to help out a group of Python
> newbies there is at least one baffling problem due to tabs/spaces.
> There are hundreds of different text editors that people use on a
> regular basis to edit Python source code. They all display spaces
> the same way; not so for tabs.
The beauty of flexibility :) Besides that I've never seen problems due 
to tabs shown differently as long as it's not treated in some insane 
way that would be inappropriate for an IDE, so I won't consider those.

> Most of them have configurable behavior for tabs, and most of the
> time the users are not aware of even the existence of those settings,
> let alone what setting is currently being used.
And since most developers is unaware of things like compile options in 
compiled languages, should we remove that too? Even though most people 
aren't aware (either because of the lack of need or interest to change 
it) of the settings, there's no reason to remove that for us who know 
and care.


I'll try to say what I indirectly said. Show my why things are like you 
say it is. Why is tabs confusing? Why is spaces better? I can't use 
empty arguments without any proof. I can't use a "it's just like that"-
argument, only thing I can use that for is wasting my time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Marc-Andre Lemburg]

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 out in UTR#21:

http://unicode.org/reports/tr21/tr21-3.html

The Python version only implements the basic set of rules, i.e.
"If the preceeding letter is cased, chose the lowercase mapping; otherwise 
chose the titlecase
mapping (in most cases, this will be the same as the uppercase, but not 
always)."

It doesn't implement the special casing rules, since these would
require locale and language dependent context information which
we don't implement/use in Python.

It also doesn't implement mappings that would result in a change of
length (ligatures) or require look-ahead strategies (e.g. if the casing
depends on the code point following the converted code point).

Patches to enhance the code to support those additional rules
are welcome.

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 likely that the special use of the apostrophe in English
is actually a language-specific use case. For those, it's (currently)
better to implement your own versions of the conversion functions,
based on the existing methods.

Regarding the idea to add an option to define which characters to
regard as cased/non-cased: This would cause the algorithm to no longer
adhere to the Unicode standard and most probably cause more problems
than it solves.

--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7005] ConfigParser does not handle options without values

[Mats Kindahl]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Marc-Andre Lemburg]

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 likely that the special use of the apostrophe in English
> is actually a language-specific use case. For those, it's (currently)
> better to implement your own versions of the conversion functions,
> based on the existing methods.

Looking at the many different uses in various languages, this
appears to be the better option:

http://en.wikipedia.org/wiki/Apostrophe

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Ezio Melotti]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Antoine Pitrou]

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's why Microsoft Word automatically inserts a non-ASCII apostrophe
when you type « ' », at least in certain languages (apparently
OpenOffice doesn't).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Marc-Andre Lemburg]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christoph Burgmer]

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/makeunicodedata.py:
>>> print ' '.join([u':', u'\xb7', u'\u0387', u'\u05f4', u'\u2027',
u'\ufe13', u'\ufe55', u'\uff1a'] + [u"'", u'.', u'\u2018', u'\u2019',
u'\u2024', u'\ufe52', u'\uff07', u'\uff0e'])
: · · ״ ‧ ︓ ﹕ ： ' . ‘ ’ ․ ﹒ ＇ ．

Those cannot currently be extracted automatically, as neither
DerivedCoreProperties.txt nor the source file for property
"Word_Break(C) = MidLetter or MidNumLet" are provided in the script.

As I said, the patch is only a second best solution, as the correct
path would be implementing the word breaking algorithm as described in
the newest standard. This patch is just an improvement over the current
situation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7017] os.listdir behaviour

[Mark Dickinson]

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 necessary to reproduce
(e.g. "First create a directory 'tmp' containing files 'a', 'b' and 'c'").

--
nosy: +mark.dickinson
resolution:  -> works for me
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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
> hardcoded (see below)
> 
> I hardcoded some characters into Tools/unicode/makeunicodedata.py:
 print ' '.join([u':', u'\xb7', u'\u0387', u'\u05f4', u'\u2027',
> u'\ufe13', u'\ufe55', u'\uff1a'] + [u"'", u'.', u'\u2018', u'\u2019',
> u'\u2024', u'\ufe52', u'\uff07', u'\uff0e'])
> : · · ״ ‧ ︓ ﹕ ： ' . ‘ ’ ․ ﹒ ＇ ．
> 
> Those cannot currently be extracted automatically, as neither
> DerivedCoreProperties.txt nor the source file for property
> "Word_Break(C) = MidLetter or MidNumLet" are provided in the script.

As long as those code points are defined somewhere in the Unicode
standard files, that's ok.

It would be good to add a comment explaining the above in the code.

BTW: It's better to use "if ()" instead of \-line joining. The
parens will automatically have Python do the line joining for you
and it looks better.

> As I said, the patch is only a second best solution, as the correct
> path would be implementing the word breaking algorithm as described in
> the newest standard. This patch is just an improvement over the current
> situation.

We could handle the work-breaking in a separate new method.

For .title(), I think your patch is an improvement and it will
fix most of the cases that issue7008 mentions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Ralf Schmitt]

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 default operation.
I even think that there should be *no* option to allow overriding files
outside the destination path (on unix one can always use / as
destination if he feels like overwriting his /etc/passwd)
The documentation should also mention that it's unsafe to use this
method in python <2.6.2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Ralf Schmitt]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6790] httplib and array do not play together well

[Antoine Pitrou]

Antoine Pitrou  added the comment:

issue6790-python2.6.diff is ok, can you commit to trunk and then merge?

--
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Christoph Burgmer]

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 implemented anyway, to properly solve
issue6412.

--
nosy: +christoph

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Antoine Pitrou]

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 another method, however, will just confuse and annoy
existing users.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christoph Burgmer]

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 header files.

Note though, that with this patch str and unicode objects will not
behave equally:
>>> s = "This isn't right"
>>> s.title() == unicode(s).title()
False

--
Added file: http://bugs.python.org/file14994/unicodeobject.titlecase.3.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Marc-Andre Lemburg]

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.

> 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 implemented anyway, to properly solve
> issue6412.

Simple word breaking would be nice to have in Python as new
Unicode method, e.g. .splitwords().

Note however, that word boundaries are just as complicated as casing:
there are lots of special cases in different languages or locales
(see the notes after the word boundary rules in the TR29).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Antoine Pitrou]

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 the /old/ buffer API instead of the new one (that is, by using
a '#' typecode), we have to accept these choices.

Here's a patch for trunk, combining the new buffer API for `array` and
the checks removal in getargs.c.

--
Added file: http://bugs.python.org/file14995/hasharray.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 typecodes by family: numbers, strings/buffers, objects; also,
there are so many choices that it's confusing which ones should be
preferred)

--
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 93276
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Recommend "*" over "#" in getargs.c typecodes
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Christoph Burgmer]

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

Marc-Andre Lemburg wrote:
> Note however, that word boundaries are just as complicated as casing:
> there are lots of special cases in different languages or locales
> (see the notes after the word boundary rules in the TR29).

ICU already has the full implementation, so Python could get away with
just supporting the default implementation (as seen with other case
mappings).

>>> from PyICU import UnicodeString, Locale, BreakIterator
>>> en_US_locale = Locale('en_US')
>>> breakIter = BreakIterator.createWordInstance(en_US_locale)
>>> s = UnicodeString("There's a hole in the bucket.")
>>> print s.toTitle(breakIter, en_US_locale)
There's A Hole In The Bucket.
>>> breakIter.setText("There's a hole in the bucket.")
>>> last = 0
>>> for i in breakIter:
... print s[last:i]
... last = i
...
There's

A

Hole

In

The

Bucket
.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Amaury Forgeot d'Arc]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7012] Tabs is better than spaces for indentation

[Tim Peters]

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 millions of words
of debate on this topic have already taken place, mostly in the early to
mid 90's.  Nobody has anything new to say on this topic :-(

Note that nobody objects if you want to use tabs, or even mix tabs and
spaces, in your own code.  The Python "spaces only" standard is for
distributed code.  Years of early experience taught us beyond doubt that
tabs caused endless problems for /shared/ code, to the extent that the
Python distribution contains utilities to detect when mixing tabs and
spaces can cause semantic differences (tabnanny.py) and to reformat
source files to replace all tabs with spaces (reindent.py).

Indeed, if you want to contribute to the Python distribution and insist
on using tabs, that's fine:  simply run your code through reindent.py
before submitting your patch.  Otherwise, just like this feature
request, your patch will be rejected ;-)

--
nosy: +tim_one

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Skip Montanaro]

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 if you try ./test.py I presume you also get an error in this trivial
case.  If your .py file is not meant to be executed, why set the execute
bit?  I do agree it's a little strange to also set the execute bit on the
.pyc file though.

Skip

--
nosy: +skip.montanaro

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Antoine Pitrou]

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 those fields in order to accomodate for
subtle role differences. Also, I don't think PyPI is the place to record
detailed attribution information. An ad-hoc CREDITS, ACKS file or
similar is what you want IMO.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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" multi-valued field as described
previously.

Having an extra email in each Author field would be allowed but not
parsed. Each Author field would be a free string that can be "Name",
"Firstname Lastname", "Firstname Lastname " or whatever.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Antoine Pitrou]

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 existing packages? What do we gain
exactly? There are enough fields available to make the writing of a
setup.py burdensome...

If you have several authors, you can separate them with commas in the
author field and even include e-mail addresses if you want (e.g. "Tarek
Ziadé , Antoine Pitrou "). 

Not every wish for a new "feature" should be satisfied, IMO. Besides,
making metadata complex and version-dependent is the best way to make it
useless.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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 the author one
in the metadata field "Author".

To fill the "Home-url" metadata, the argument is called "url".
The "Summary" metadata is filled with the... "description" argument
The "Description" metadata is filled with the... "long_description"
argument.

So what we would gain is more clarity (as already discussed in other issues)

We are already discussing the addition of new fields in PEP 341 for
package dependencies, and making others clearer.

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. Same thing goes with the email issue.

--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Antoine Pitrou]

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 human beings to read, and a human being is perfectly
able to parse "AP , Tarek " without
the help of a computer.

While there may be some things to clear up in the current metadata, this
shouldn't be a pretext to gratuitously change things that are ok. I'm
bothered that many people currently seem to think that it's ok to break
compatibility for whatever non-critical reason. This is not the way we
will make Python a reliable platform to use and develop for.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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 Distutils just means that you
might find several lines starting with 

{{{
Author:
}}}

And that Distutils will be able to recognized both forms, exactly like
it does with Metadata v1.0 and metadata v1.1.

> I'm bothered that many people currently seem to think that it's ok 
> to compatibility for whatever non-critical reason. This is not 
> the way we will make Python a reliable platform to use and develop for.

I don't know who you are reffering to, but if you look carefully at the
work I've been doing in Distutils, I have never and I will never do any
gratuitously change whatsoever. 

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.

Any change to the metadata fields will require a PEP 341 change, so
everyone will be free to do a +1 or a -1.

But saying that making the metadata evolve "is not the way we will make
Python a reliable platform to use and develop for" is completely
wrong imho.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

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 another field for contributors is overkill, IMHO. It's common
practice to put credits into a README or separate file within the package.

I don't think we should grow the package meta-data beyond what's
reasonably needed to identify a package and its origin - otherwise we'll
end up with a reinvention of RDF.

I'd close this ticket as "works for me".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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
calculated using 'author' *or* 'maintainer' arguments. Meaning that when
you fill both, one is lost. (and leading to the current inconsistency).

So being able to have several Authors (not yet another field, an
existing one, but multi-valued) and an "authors" argument would fix this
inconsistency since we would be able to keep both.

This is not a big change on the metadata format, it just means that we
can have extra "Author:" lines, so it's backward compatible.

OTHO, deprecating "maintainer" and "maintainer_email" on setup() side,
and making it clear that there's only one Author and one email could
work too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Antoine Pitrou]

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
detail that doesn't seem to warrant a change. It is still unknown what
use case the new "author" scheme would solve that the old one doesn't
(does someone want the "author" field to be machine parsable? for what
purpose?), and this bug report itself is quite nebulous (it is unsure
what "doesn't work" since you can put human-readable info about multiple
authors in a single unicode string).
That's why I call it "gratuitous".

> But saying that making the metadata evolve "is not the way we will make
> Python a reliable platform to use and develop for" is completely
> wrong imho.

A metadata system, by definition, has to remain reasonably stable (or be
version-numbered, such that old metadata can be recognized properly).
You can certainly add fields, but replacing existing fields with others
should be sufficiently motivated.

If the ID3 spec was rewritten every five years so that you couldn't read
back the author info from the MP3s you made in 2000, you wouldn't be
very happy :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

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
> resulting metadata only contains "Author" and "Author-email", and it's
> calculated using 'author' *or* 'maintainer' arguments. Meaning that when
> you fill both, one is lost. (and leading to the current inconsistency).
>
> So being able to have several Authors (not yet another field, an
> existing one, but multi-valued) and an "authors" argument would fix this
> inconsistency since we would be able to keep both.
> 
> This is not a big change on the metadata format, it just means that we
> can have extra "Author:" lines, so it's backward compatible.
> 
> OTHO, deprecating "maintainer" and "maintainer_email" on setup() side,
> and making it clear that there's only one Author and one email could
> work too.

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

Regarding making the meta-data fields multi-valued, you have
to be aware that when parsing the meta-data using an rfc822
style module, code assuming that only one Author field
exists, will return (just) one of the available fields and
it's not at all clear which.

I still believe that we're better off with a single Author
field using comma delimited names, e-mail addresses, etc.

Adding "authors" as new keyword argument to setup() isn't
going to make things more consistent, only more complex
code-wise, so I don't think it's worth the trouble.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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 certainly add fields, but replacing existing fields with 
> others should be sufficiently motivated.

Yes, that why the proposed change is backward compatible: it doesn't
replace "Author" but turn it into a multi-valued field like
"Classifier". Either you have one author line, and the metadata is 1.0
or 1.1, Either you have several authors, and the metadata is 1.2 and
doesn't modify Author but add more of those lines.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Carl Friedrich Bolz]

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.loads('l\x02\x00\x00\x00\x00\x00\x00\x00')
>>> print x
0
>>> x == 0
False
>>> bool(x)
True
>>> x + 1
1L

I would expect this to raise an error instead.

--
components: Interpreter Core
messages: 93295
nosy: cfbolz
severity: normal
status: open
title: unmarshaling of artificial strings can produce funny longs.
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Tarek Ziadé]

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 the community usage of those since they are competng
with author and author_email on setup() side

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7012] Tabs is better than spaces for indentation

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Carl Friedrich Bolz]

Changes by Carl Friedrich Bolz :


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7008] str.title() misbehaves with apostrophes

[Guido van Rossum]

Changes by Guido van Rossum :


--
assignee: gvanrossum -> 
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] Adding a Contributor field in PEP 314

[Marc-Andre Lemburg]

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 remember what's the story behind those two fields ?

I don't really remember, but suppose that the field was
added for cases where a package is being abandoned by the
original author and then maintained by someone new.

IMHO, the maintainer could have just added the new contact
details to the author field and a mention of the changed
maintenance to the description.

> I am not sure about the community usage of those since they are competng
> with author and author_email on setup() side

PyPI just shows the "Author" field, so if a package has different
author and maintainer entries, the author field is what's displayed -
not exactly useful, since bug reports and the like should normally
go to the maintainer, not the author.

Adding the maintainer field as well would resolve the issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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.python.org/library/marshal.html

:-)

--
assignee:  -> mark.dickinson
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Carl Friedrich Bolz]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tim Flechtner]

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 like it fits the symptoms
described here.  Can anyone point me towards the patch to apply?  I
don't see it as available here (but I wouldn't be shocked if I'm just
being blind).

Thanks!
-tim

gmake[2]: Entering directory
`/export/home/src/ThirdParty/gnu/pycairo-1.8.8/src'
/bin/bash ../libtool  --tag=CC   --mode=compile
/opt/app/g++lib6/gcc-4.4/bin/gcc -DHAVE_CONFIG_H -I. 
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/nonc++/release-1/include/cairo   -DNDEBUG  -g -O2 -std=c99
-Wall -fno-strict-aliasing -MT _cairo_la-cairomodule.lo -MD -MP -MF
.deps/_cairo_la-cairomodule.Tpo -c -o _cairo_la-cairomodule.lo `test -f
'cairomodule.c' || echo './'`cairomodule.c
libtool: compile:  /opt/app/g++lib6/gcc-4.4/bin/gcc -DHAVE_CONFIG_H -I.
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/g++lib6/python-2.6/include/python2.6
-I/opt/app/nonc++/release-1/include/cairo -DNDEBUG -g -O2 -std=c99 -Wall
-fno-strict-aliasing -MT _cairo_la-cairomodule.lo -MD -MP -MF
.deps/_cairo_la-cairomodule.Tpo -c cairomodule.c  -fPIC -DPIC -o
.libs/_cairo_la-cairomodule.o
In file included from /usr/include/limits.h:18,
 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/limits.h:122,
 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/syslimits.h:7,
 from
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/limits.h:11,
 from
/opt/app/g++lib6/python-2.6/include/python2.6/Python.h:19,
 from cairomodule.c:32:
/opt/app/g++lib6/gcc-4.4/lib/gcc/i386-pc-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h:341:2:
error: #error "Compiler or options invalid for pre-UNIX 03 X/Open
applications   and pre-2001 POSIX applications"

--
nosy: +tflecht

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Barry A. Warsaw]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 2.6.3.  :-(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Philip Jenvey]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

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

For what it's worth, OS X's BOMArchiveManager will place a file stored
as '../foo.txt' in the extract path, not the directory right outside it.

While we're on the topic, there may also be a bug in this, or the
tarfile package that would allow a malicious archive to extract a
symlink to an existing directory somewhere on the target machine, and
files extracted to that symlink. I haven't really thought that through,
but I'm sure that my fix won't correct that possible issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6790] httplib and array do not play together well

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7014] Logging incompatible with IronPython

[Michael Foord]

Michael Foord  added the comment:

Works for me - thanks Vinay.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Jan Hosang]

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 resizing of the memory basically was replaced by a call to 
array_resize with the advantage, that checking for exported memory views 
is done there (which is not necessary because it's already done in the 
function) and the code gets clearer. I think when PyMem_RESIZE is called 
the pointer to the memory might change. So in 3k this now happens in 
array_resize, so the array->ob_item pointer changes but not it's local 
copy in array_ass_slice. Isn't that potentially causing trouble in 
python 3k?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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: False is not True

--
resolution: fixed -> accepted
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Of course, I had forgotten to rebuild :-/ Sorry for the noise.

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
assignee:  -> pjenvey
keywords:  -needs review
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6790] httplib and array do not play together well

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r75134, r75135, r75137, r75142. Thanks!

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Giampaolo Rodola']

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Gaimpaolo thanks.  Please give it a try.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Philip Jenvey]

Philip Jenvey  added the comment:

applied in r75143/r75144, in time for 2.6.3. thanks!

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Jan Hosang]

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 should be moved, 
because Py_SIZE(a) was already modified by array_resize, but the function 
moves (Py_SIZE(a)-ihigh) items.

The attached patch for python 2.7 passes all unit tests for me.

--
Added file: http://bugs.python.org/file14999/hasharray.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Please apply this for 2.6.3rc1

--
priority:  -> release blocker
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Committed in r75147 (trunk) and r75148 (2.6)

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bonner]

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 2.5, but I've updated the patch to py3k
trunk, and attached it here.  If there's interest in a patch against 2.7
trunk, please let me know.

--
nosy: +dbonner
versions: +Python 2.5, Python 3.2
Added file: http://bugs.python.org/file15000/bz2_patch.tar.bz2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Giampaolo Rodola']

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 already there at the 
time I submitted the report but it's another thing that need to be 
fixed.


Moreover, I'm sure that removing the "while" loop is good for non-
blocking sockets but what about blocking ones?
Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised 
in a blocking environment?
If they aren't then the current patch just needs to take care of send() 
method too, then it's fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


--
nosy: +srid

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Skip Montanaro]

Changes by Skip Montanaro :


--
nosy: +skip.montanaro

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bonner]

Changes by David Bonner :


Removed file: http://bugs.python.org/file15000/bz2_patch.tar.bz2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bonner]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Giampaolo Rodola']

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

We'll need tests to include it in 2.6.3.

--
priority: high -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zooko O'Whielacronx]

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 ticket saying that they couldn't
compile their extension modules until they applied the patch.

Also then the Solaris folks who build an installation of Python for
Solaris can remove the perl script that searches for "#define
_XOPEN_SOURCE" and replaces it with the empty string when building Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

Thomas W. Barr  added the comment:

Uploading test.

--
keywords: +patch
Added file: http://bugs.python.org/file15002/zipfile-6972-test.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

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, the
path should be normalized, but can someone confirm this?

--
Added file: http://bugs.python.org/file15003/zipfile-6972-patch.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[R. David Murray]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Gregory P. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Not gonna make it for 2.6.3rc1

--
priority: release blocker -> high

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6972] zipfile.ZipFile overwrites files outside destination path

[Thomas W. Barr]

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()
into the diff.

--
Added file: http://bugs.python.org/file15004/extract-doc.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bill Janssen]

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 existing tests and
also seems to be a fix (through inspection) may have to be sufficient.

After all, the tests for the previous SSL support (Python 2.5 and
earlier) were extremely sketchy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6071] no longer possible to hash arrays

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I would prefer if I opened a separate issue for this bug.

if /you/ opened, of course...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7017] os.listdir behaviour

[Chris Adamson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7020] regression in pywin32 build due to 2.6.3rc1

[Sridhar Ratnakumar]

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 /DLL
/nologo /INCREMENTAL:NO
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\libs
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\PCbuild
/LIBPATH:build\temp.win32-2.6\Release "/LIBPATH:C:\Program
Files\Microsoft SDKs\Windows\v6.0\lib" advapi32.lib user32.lib ole32.lib
oleaut32.lib /EXPORT:initpywintypes
build\temp.win32-2.6\Release\win32\src\PyACL.obj
build\temp.win32-2.6\Release\win32\src\PyDEVMODE.obj
build\temp.win32-2.6\Release\win32\src\PyHANDLE.obj
build\temp.win32-2.6\Release\win32\src\PyIID.obj
build\temp.win32-2.6\Release\win32\src\PyLARGE_INTEGER.obj
build\temp.win32-2.6\Release\win32\src\PyOVERLAPPED.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_ATTRIBUTES.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_DESCRIPTOR.obj
build\temp.win32-2.6\Release\win32\src\PySID.obj
build\temp.win32-2.6\Release\win32\src\PyTime.obj
build\temp.win32-2.6\Release\win32\src\PyUnicode.obj
build\temp.win32-2.6\Release\win32\src\PyWAVEFORMATEX.obj
build\temp.win32-2.6\Release\win32\src\PyWinTypesmodule.obj
/OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd
/IMPLIB:build\temp.win32-2.6\Release\win32\src\pywintypes.lib
/MANIFESTFILE:build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
/MACHINE:x86 /BASE:0x1e7d /DEBUG
/PDB:build\temp.win32-2.6\Release\pywintypes.pdb
   Creating library
build\temp.win32-2.6\Release\win32\src\pywintypes.lib and object
build\temp.win32-2.6\Release\win32\src\pywintypes.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0\bin\mt.exe -nologo
-manifest build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
-outputresource:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd;2
Unable to import verstamp, no version info will be added
error: can't copy
'build\temp.win32-2.6\Release\win32\src\pywintypes26.lib': doesn't exist
or not a regular file
=

With 2.6.2 .. this error did not happen.

The file build\temp.win32-2.6\Release\win32\src\pywintypes.lib exists
(but without the version number). 

Was something substantial changed in distutils?

(I am currently investigating this issue; more details will follow)

--
assignee: tarek
components: Distutils
messages: 93341
nosy: srid, tarek
severity: normal
status: open
title: regression in pywin32 build due to 2.6.3rc1
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7020] regression in pywin32 build due to 2.6.3rc1

[Sridhar Ratnakumar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6186] test_thread occasionally reports unhandled exceptions on OS X

[Ned Deily]

Ned Deily  added the comment:

Also seen on Python 2.6.3rc1.

--
versions: +Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com