[issue1225769] Proposal to implement comment rows in csv module

[Andrew McNamara]

Andrew McNamara <[EMAIL PROTECTED]> added the comment:

I think it's a reasonable enough request - I've certainly had to 
process CSV files with comments. Iain - appologies for not looking at 
your request before now - 3 years is a pretty poor response time.

Some thoughts:
 * this should target 2.6, not 2.5 (as 2.5 is in maintenance only)?
 * the check that disallows "space" - I wonder what other things it 
should disallow - the delimiter?
 * should it support multicharacter comments, like the C++ //-style 
comment? I think no.
 * any implications for the py3k port?

Skip - are you happy making the changes, or should I dust off my 
working copy?

_
Tracker <[EMAIL PROTECTED]>

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

[issue1225769] Proposal to implement comment rows in csv module

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

-1 on the change.  Comments in CSV files are not a common use case.  
I'm less worried about cluttering the C code and more concerned about 
cluttering the API, making the module harder to learn and remember.

Also, it is already trivial to implement filtering using str.startswith
().  This proposed patch is not worth the rare case where it saves a 
line or two code that was already crystal clear.

--
nosy: +rhettinger

_
Tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Bob Atkins]

Bob Atkins <[EMAIL PROTECTED]> added the comment:

Martin,

Martin v. Löwis wrote:

It does not when link stage specific options are required that are not 
valid for compilation stages.

My mistake. I was thinking of another package - you can scratch that 
comment.

There is no hard and fast rule that specifying the CFLAGS or other 
configure variables have to override /_*all*_/ of the compile flags that 
a developer chooses to use in their build process. Most open source 
packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the 
compile and link flags and not completely override them. My patch 
follows the same philosophy that I have seen in the majority of other 
open source packages.

On the contrary - it does /_*not*_/ make it more complex and it 
/_*does*_/ provide a solution to a number of compile and link failures 
that have been reported over and over again. When I first posted this 
bug I read through the various forums and bug reports and I noticed 
quite a bit of complaining regarding this issue and I acknowledged that 
by noting in my report that what I was opening a bug report on what was 
clearly a sore subject within the Python community. To be specific the 
complaints were regarding the symptoms (unusual compile and link 
problems) related to this issue, not the specific cause of the problem 
which is why I filed the bug as I did.

The patch that I submitted will allow a build of Python to be performed 
the /_exact_/ same way it is today without any modifications to CFLAGS 
or LDFLAGS, etc. Those of us that /need/ to use these variables will be 
able to modify the build options to the configure script as necessary 
/_*without*_/ any complexity and without losing 'important' compile 
options that are currently generated by configure. All of your 
suggestions to use the CC variable in lieu of using the more appropriate 
CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard 
approach you are claiming you want top avoid.

Again, I don't see what your concerns are. My patch is a completely 
non-affecting change to the way Python is built today /_*but*_/ it does 
add the necessary fixes so that those that require specific compile and 
link options can specify them to the configure script.

In addition, while you are fixing the build/compile options, I noticed 
that you are missing the -fPIC compile option. Without it you can't link 
shared libraries and the build fails. You should probably be including 
-fPIC as a standard compile option so it is not required to be passed 
into the build via the configure script.

---
Bob

Added file: http://bugs.python.org/file10033/unnamed

_
Tracker <[EMAIL PROTECTED]>

_


  
  


Martin,

Martin v. Löwis wrote:

  Martin v. Löwis mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]> added the comment:

  
  
Your suggestion for using the CC variable to fix the problem 
that I 
reported won't work - I already tried it and based on what others are 
reporting, you are beating a dead horse. Believe me I would rather not 
modify anyone's code in order to build something. The problem is that 
the CC variable doesn't fix the link stages

  
  
Why is that? It should work fine.
  

It does not when link stage specific options are required that are not
valid for compilation stages.

  
  
  
and overall your autconf 
build is broken particularly as it relates to flowing variables down to 
sub builds.

  
  
This I don't understand. What is a sub build?
  

My mistake. I was thinking of another package - you can scratch that
comment.

  
  
  
I don't know why you are resisting this change. I took the 
time to 
report the bug, proposed a fix /_*and*_/ contributed the patch that 
would make the Python build process more standard relative to the vast 
majority of open source packages that use autoconf.

  
  
I don't think that's the case. In autoconf, if you specify CFLAGS,
you expect that this overrides, not adds to, anything configure
computes on its own. This patch does not do that, i.e. it doesn't
allow you to override the settings that configure computes.
  

There is no hard and fast rule that specifying the CFLAGS or other
configure variables have to override all of the
compile flags that a developer chooses to use in their build process.
Most open source packages use the configure CFLAGS, LDFLAGS, etc,
variables to add to the compile and link flags and not completely
override them. My patch follows the same philosophy that I have seen in
the majority of other open source packages.

  
I'm concerned that the patch merely makes the entire setup more
complex, rather than solving an actual technical problem. That's
why I'm resisting to accept it.
  

On the contrary - it does not make it more
complex and it does provide a solution to a
number of compile and link failures that have been reported over and
over

[issue2439] Patch to add a get_data function to pkgutil

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

I should be able to review/commit this for the next alpha (looking into
it right now).

--
assignee:  -> ncoghlan

__
Tracker <[EMAIL PROTECTED]>

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

[issue2439] Patch to add a get_data function to pkgutil

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Test file added in rev 62351 (forgot to svn add it the first time around)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2439] Patch to add a get_data function to pkgutil

[Paul Moore]

Paul Moore <[EMAIL PROTECTED]> added the comment:

Thanks,
Paul.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2439] Patch to add a get_data function to pkgutil

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Commited as rev 62350

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2541] Unicode escape sequences not parsed in raw strings.

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

It's rejected because the OP wanted unicode escapes to be applied in
unicode strings, and I haven't applied the docs because nobody has told
me I should.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[Jeffrey C. Jacobs]

New submission from Jeffrey C. Jacobs <[EMAIL PROTECTED]>:

I am working on adding features to the current Regexp implementation,
which is now set to 2.2.2.  These features are to bring the Regexp code
closer in line with Perl 5.10 as well as add a few python-specific
niceties and potential speed-ups and clean-ups.

I will be posting regular patch updates to this thread when major
milestones have been reach with a description of the feature(s) added. 
Currently, the list of proposed changes are (in no particular order):

1) Fix http://bugs.python.org/issue433030";>issue 433030 by
adding support for Atomic Grouping and Possessive Qualifiers

2) Make named matches direct attributes of the match object; i.e.
instead of m.group('foo'), one will be able to write simply m.foo.

3) (maybe) make Match objects subscriptable, such that m[n] is
equivalent to m.group(n) and allow slicing.

4) Implement Perl-style back-references including relative back-references.

5) Add a well-formed, python-specific comment modifier, e.g. (?P#...);
the difference between (?P#...) and Perl/Python's (?#...) is that the
former will allow nested parentheses as well as parenthetical escaping,
so that patterns of the form '(?P# Evaluate (the following) expression,
3\) using some other technique)'.  The (?P#...) will interpret this
entire expression as a comment, where as with (?#...) only, everything
following ' expression...' would be considered part of the match. 
(?P#...) will necessarily be slower than (?#...) and so only should be
used if richer commenting style is required but the verbose mode is not
desired.

6) Add official support for fast, non-repeating capture groups with the
Template option.  Template is unofficially supported and disables all
repeat operators (*, + and ?).  This would mainly consist of documenting
its behavior.

7) Modify the re compiled expression cache to better handle the
thrashing condition.  Currently, when regular expressions are compiled,
the result is cached so that if the same expression is compiled again,
it is retrieved from the cache and no extra work has to be done.  This
cache supports up to 100 entries.  Once the 100th entry is reached, the
cache is cleared and a new compile must occur.  The danger, all be it
rare, is that one may compile the 100th expression only to find that one
recompiles it and has to do the same work all over again when it may
have been done 3 expressions ago.  By modifying this logic slightly, it
is possible to establish an arbitrary counter that gives a time stamp to
each compiled entry and instead of clearing the entire cache when it
reaches capacity, only eliminate the oldest half of the cache, keeping
the half that is more recent.  This should limit the possibility of
thrashing to cases where a very large number of Regular Expressions are
continually recompiled.  In addition to this, I will update the limit to
256 entries, meaning that the 128 most recent are kept.

8) Emacs/Perl style character classes, e.g. [:alphanum:].  For instance,
:alphanum: would not include the '_' in the character class.

9) C-Engine speed-ups.  I commenting and cleaning up the _sre.c Regexp
engine to make it flow more linearly, rather than with all the current
gotos and replace the switch-case statements with lookup tables, which
in tests have shown to be faster.  This will also include adding many
more comments to the C code in order to make it easier for future
developers to follow.  These changes are subject to testing and some
modifications may not be included in the final release if they are shown
to be slower than the existing code.  Also, a number of Macros are being
eliminated where appropriate.

10) Export any (not already) shared value between the Python Code and
the C code, e.g. the default Maximum Repeat count (65536); this will
allow those constants to be changed in 1 central place.

11) Various other Perl 5.10 conformance modifications, TBD.


More items may come and suggestions are welcome.

-

Currently, I have code which implements 5) and 7), have done some work
on 10) and am almost 9).  When 9) is complete, I will work on 1), some
of which, such as parsing, is already done, then probably 8) and 4)
because they should not require too much work -- 4) is parser-only
AFAICT.  Then, I will attempt 2) and 3), though those will require
changes at the C-Code level.  Then I will investigate what additional
elements of 11) I can easily implement.  Finally, I will write
documentation for all of these features, including 6).

In a few days, I will provide a patch with my interim results and will
update the patches with regular updates when Milestones are reached.

--
components: Library (Lib)
messages: 65513
nosy: timehorse
severity: normal
status: open
title: Regexp 2.6 (modifications to current re 2.2.2)
type: feature request
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

_

[issue2630] repr() should not escape non-ASCII characters

[atsuo ishimoto]

atsuo ishimoto <[EMAIL PROTECTED]> added the comment:

I revised a patch against Python 3.0a4.

- As-per suggestion from Michael Urman, unicode_repr() 
  refers unicode database to determine characters to be 
  hex-encoded.
  
- sys.stdout doesn't use 'backslashreplace'.

Added file: http://bugs.python.org/file10034/diff2.txt

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[A.M. Kuchling]

Changes by A.M. Kuchling <[EMAIL PROTECTED]>:


--
nosy: +akuchling

__
Tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Sérgio Durigan Júnior]

Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment:

Hi Martin,

On Mon, 2008-04-14 at 20:04 +, Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> 
> > This is what you get when you try to build a 64-bit Python on a biarch
> > machine (64-bit kernel, 32-bit userspace), using a gcc that generates
> > natively 32-bit objects (therefore, you *must* pass the '-m64' option
> > for the compiler):
> 
> Or you install an additional, different, C compiler that defaults to
> AMD64.

I cannot do that. Actually, even if I could, I don't think this is the
best way to handle this *Python*'s problem.

> > 1) As you could see above, actually you need CFLAGS in order to compile
> > Python correctly. As far as I could investigate, the reason you need
> > this is because of the tests that are done by configure. Without the
> > CFLAGS, configure will think it's building a 32-bit Python, despite of
> > the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
> > through Makefile or not? IMHO, we do.
> 
> Not necessarily. I think you can achieve the same effect by specifying
> CC="gcc -m64" to configure.

I know that. But the purpose of CC flag is to define a compiler to be
used in the compilation, and not to specify compiler flags (for that, we
have CFLAGS).

> > Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
> > But again, I don't think this is a solution for this issue :-).
> 
> Why not?

See above.

Regards,

_
Tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Sérgio Durigan Júnior]

Sérgio Durigan Júnior <[EMAIL PROTECTED]> added the comment:

On Tue, 2008-04-15 at 02:01 +, Bob Atkins wrote:

> I don't know why you are resisting this change. I took the time to 
> report the bug, proposed a fix /_*and*_/ contributed the patch that 
> would make the Python build process more standard relative to the vast 
> majority of open source packages that use autoconf. I am glad to see 
> that my patch appears to be generic enough that it works on other 
> platforms as well. I didn't have to post a bug report let alone 
> contribute a patch but, I believe strongly that is what open source is 
> all about. As the maintainer you don't have to accept either the bug or 
> the patch but, resisting without good cause will discourage further 
> contributions - certainly from me because I won't waste my time 
> submitting something when I know that a maintainer of a package is being 
> closed minded. We do a lot of work with open source software here and it 
> is our policy to contribute back to the community as much as possible. 
> However, when we run into a brick wall we quickly give up because we 
> can't justify the time and effort. As an example, we have completely 
> suspended all contributions to the asterisk project. We operate a very 
> large asterisk environment with a lot of fixes and improvements that I 
> am sure lots of others would love to have but the maintainer's attitude 
> was that a Sun Solaris platform was not important. What the maintainer 
> doesn't know is that many of our fixes and changes affect /_*all*_/ 
> platforms. So now they get nothing from us and the asterisk community as 
> a whole is deprived of the benefits of our work. I also know that many 
> others have also suspended contributions for the same reason and as a 
> result the asterisk package suffers. The resistance on your part to 
> recognizing this problem and a fix is unjustified.

Bob just took the words from my mouth. Martin, with all respect, your
resistance in accepting this patch is making things much harder that
they really are. The main point here is that this pacth actually
*doesn't* break anything in Python!

Please, take a time to consider our proposal.

Thanks,

_
Tracker <[EMAIL PROTECTED]>

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

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

It was applied to 2.5-maint after 2.5.2 was released, BTW, so the change
isn't in any stable released version, only the 2.6 alphas.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2636] Regexp 2.6 (modifications to current re 2.2.2)

[A.M. Kuchling]

Changes by A.M. Kuchling <[EMAIL PROTECTED]>:


--
components: +Regular Expressions -Library (Lib)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs

[Tim Lesher]

New submission from Tim Lesher <[EMAIL PROTECTED]>:

The urllib.quote docstring implies that it quotes only characters in RFC
2396's "reserved" set.

However, urllib.quote currently escapes all characters except those in
an "always_safe" list, which consists of alphanumerics and three
punctuation characters, "_.-".

This behavior is contrary to the RFC, which defines "unreserved"
characters as alphanumerics plus "mark" characters, or "-_.!~*'()".  

The RFC also says:

  Unreserved characters can be escaped without changing the semantics
  of the URI, but this should not be done unless the URI is being used
  in a context that does not allow the unescaped character to appear.

This seems to imply that "always_safe" should correspond to the RFC's
"unreserved" set of "alphanum" | "mark".

--
components: Library (Lib)
messages: 65518
nosy: tlesher
severity: normal
status: open
title: urllib.quote() escapes characters unnecessarily and contrary to docs
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1092502] Memory leak in socket.py on Mac OS X

[Gregory P. Smith]

Changes by Gregory P. Smith <[EMAIL PROTECTED]>:


--
nosy: +gregory.p.smith

_
Tracker <[EMAIL PROTECTED]>

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

[issue2638] tkSimpleDialog Window Flashing

[Ron Longo Work]

New submission from Ron Longo Work <[EMAIL PROTECTED]>:

When a Tkinter window comes up that uses tkSimpleDialog to construct a 
dialog box, the window first flashes on the screen as an unpopulated 
top-level window, before being drawn in its completed state.

This problem is easily corrected by adding two lines of code to the 
constructor for class Dialog in tkSimpleDialog.py.  The first line of 
the constructor reads Toplevel.__init__( self, parent ).  After this 
line insert self.overrideredirect( True ).  The second line from the 
last in this constructor reads self.initial_focus.focus_set(), just 
before this line insert self.overrideredirect( False).  That's it.  
I've attached the revised version of this file.

--
components: Tkinter
files: tkSimpleDialog.py
messages: 65519
nosy: Longorh
severity: normal
status: open
title: tkSimpleDialog Window Flashing
versions: Python 2.5
Added file: http://bugs.python.org/file10035/tkSimpleDialog.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

The patch does not add unit tests for hash(range(..)).  I would actually 
test that hash(range(a,b,c)) == hash((a,b,c)) for various values of a, 
b,  and c.

A nit-pick: while I personally like the coding style with line breaks 
before binary ops, python C style appears to be the opposite.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2639] shutil.copyfile() documentation is vague

[Roy Smith]

New submission from Roy Smith <[EMAIL PROTECTED]>:

The current doc says, "Copy the contents of the file named src to a file 
named dst".  Anybody used to the unix shell "cp" command would assume that 
dst could be a directory, in which case the true destination is a file in 
that directory with the same basename as src.  Experimentation shows that 
this is not true.  A note something like the following would help:

Note: unlike the "cp" shell command, dst may not be a directory; it must 
be a path to a file in that directory.

True, there's no place in the docs which actually says a directory is 
valid for dst, but the name of the module is shutil, so it's reasonable 
for people to assume that these act the same way as the corresponding unix 
shell commands.  It should be stated up front that this is not true, to 
avoid confusion.

--
assignee: georg.brandl
components: Documentation
messages: 65521
nosy: georg.brandl, roysmith
severity: normal
status: open
title: shutil.copyfile() documentation is vague
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2639] shutil.copyfile() documentation is vague

[Roy Smith]

Roy Smith <[EMAIL PROTECTED]> added the comment:

Reading closer, I see that copy() has the shell-like semantics I was 
expecting copyfile() to have.  Perhaps the right fix is to include a note in 
the copyfile() docs saying, "dst must be a file path; see also copy() for a 
version which allows dst to be a directory".

It might also make sense to move copy() to the top of the list, because it 
is the one which has the most shell-like semantics.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2640] "excel" csv option generates multiple lines

[Jeff Hall]

New submission from Jeff Hall <[EMAIL PROTECTED]>:

Current: csv.py indicates lineterminator = '\r\n'
Issue: looks fine in notepad but when pulled into excel (office 2003)
extra lines are added
Resolution: should read lineterminator = '\r'

--
components: Extension Modules
messages: 65523
nosy: laxrulz777
severity: normal
status: open
title: "excel" csv option generates multiple lines
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Code review:

Objects/rangeobject.c:

line 259-260:
AFAIK register is completely useless in this day and age; drop it.

line 296 and further:
Please move the || and && operators to the end of the previous line.

line 313 etc:
This all fits on one line.

Line 319-320:
Ditto.

Line 361:
Please make the comment line up.

Lib/test/test_builtin.py:
I'd like to see another test indicating which of the following is true:

range(0, 11, 2) == range(0, 10, 2)

or

range(0, 11, 2) != range(0, 10, 2)

(since they produce the same sequence of values).

Also, add a test for __hash__() of a range().

__
Tracker <[EMAIL PROTECTED]>

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

[issue2638] tkSimpleDialog Window Flashing

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Isn't overrideredirect only used to enable/disable borders in the window
? Why doing this fix what you described ?
Also, make a patch against python-trunk instead of sending the entire file.

--
nosy: +gpolo

__
Tracker <[EMAIL PROTECTED]>

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

[issue2504] Add gettext.pgettext() and variants support

[Franz Glasner]

Franz Glasner <[EMAIL PROTECTED]> added the comment:

I have written a patch against the current Python trunk's gettext to
add support for pgettext and friends (upgettext, npgettext, unpgettext,
...).

I have also changed Tools/i18n/msgfmt.py to recognize the "msgctxt" keyword.
Some new unittests for dgettext and lgettext and variants are also included.

If the patch will be accepted then someone should drop a message to the
maintainers of GNU gettext to add the new functions as default keywords
for xgettext. Right now you have to call xgettext with
"--keyword=pgettext:1c,2" to extract messages with context. 

Tools/i18n/pygettext.py does currently not handle context variants.

--
components: +Library (Lib) -Extension Modules
keywords: +patch
nosy: +franz_glasner
Added file: http://bugs.python.org/file10036/gettext-pgettext.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2641] setuptools gets site-packages wrong on Mac

[Jason Orendorff]

New submission from Jason Orendorff <[EMAIL PROTECTED]>:

On my Mac, /usr/local/bin/python2.5 is a symlink to
"../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5".

When I install Mercurial from source, the "mercurial" package is
installed at "/usr/local/lib/python2.5/site-packages/mercurial", so the
installation is broken.  Since "site-packages" appears nowhere in the
Mercurial source tree, I think it's setuptools (not Mercurial) that is
getting this wrong.

Mercurial's setup.py can be seen here:

(as of this writing)
http://hg.intevation.org/mercurial/crew/file/628da4a91628/setup.py

(the latest)
http://hg.intevation.org/mercurial/crew/file/tip/setup.py

I'm not sure what the Right Thing would be, but if it's agreed that the
current behavior is a hack, then `(p for p in sys.path if
p.endswith('site-packages')).next()`, falling back to the current
behavior, seems like a better hack.

Happy to patch, if someone can advise me; MvL?

--
components: Distutils
messages: 65527
nosy: jorendorff
severity: normal
status: open
title: setuptools gets site-packages wrong on Mac
versions: Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2632] performance problem in socket._fileobject.read

[Curt Hagenlocher]

Curt Hagenlocher <[EMAIL PROTECTED]> added the comment:

At least in 2.5.2, there appear to be only two places in the standard 
library where an arbitrary and unchecked size is passed directly to 
_socketobject.recv.  _fileobject.read is one such place and the other 
is in logging/config.py.  In both cases, the pattern is something like

while len(data) < size:
data = data + sock.recv(size - len(data))

Of course, the same pattern may exist in any number of instances of 
user code that performs a socket.recv, and all of these would be 
subject to the same memory thrashing problem that originally beset 
imaplib.

As such, I now agree with Ralf that the fix ultimately belongs in 
_socketobject.  However, deploying a fix for 2.5.2 is probably easier 
if it's in socket.py than if it requires a recompile.

--
title: socket._fileobject.read(n) should ignore _rbufsize when 1 -> performance 
problem in socket._fileobject.read

__
Tracker <[EMAIL PROTECTED]>

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

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Just to repeat my concern about this patch: It gives the impression of
supporting CFLAGS, but doesn't really. There *is* a hard rule that
CFLAGS given to configure should override any options passed to
configure, and there is a reason for that: configure may guess
incorrectly, and may add options that actually conflict with the ones
that you are trying to pass in. For example, for Darwin, we add
-arch ppc -arch i386, so there is no way to not build a universal
binary anymore. Likewise, on SCO_SV, configure adds -Ki486 -DSCO5,
which may well be incorrect, and there would be no way to correct that.

Can you please agree that above description is factual wrt. the patch
you propose?

Therefore, I claim that this makes things more complex, and doesn't
solve an actual problem.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2504] Add gettext.pgettext() and variants support

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


--
assignee:  -> loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Thanks for the review! How does this look?

Added file: http://bugs.python.org/file10037/range_eq_after_review.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Close.  Just a few nits:

line 298:
These two fit on one line. Possibly the whole thing fits. If it doesn't,
the '{' should be on a line by itself.

(Are you aware of PEP 7, C code guidelines? I realize it's incomplete,
but you should still study it -- if you find things it's missing,
propose a patch to update it...!)

line 356:
Still not aligned.

Are you sure you're viewing this with a fixed-width font and tabs set to
8 spaces?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The patch uses Py_SIZE(v) on a rangeobject?
I guess you borrowed too much from the tuple implementation ;-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2483] int and float accept bytes, complex does not

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Closing this:  the consensus seems to be that things are fine as they 
are.

See the thread at

http://mail.python.org/pipermail/python-3000/2008-April/013100.html

for discussion.

--
resolution:  -> invalid

__
Tracker <[EMAIL PROTECTED]>

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

[issue2640] "excel" csv option generates multiple lines

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

What platform are you on?  Did you open the output file in
binary mode?  I sort of suspect you failed to add 'b' to the
file mode and are getting a text file.

--
nosy: +skip.montanaro

__
Tracker <[EMAIL PROTECTED]>

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

[issue2630] repr() should not escape non-ASCII characters

[atsuo ishimoto]

atsuo ishimoto <[EMAIL PROTECTED]> added the comment:

I think sys.stdout need to have backslashreplace error handler. 
Without backslashreplace, print(listOfJapaneseString) prints nothing, 
but raises an exception. This is worse than Python2.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2630] repr() should not escape non-ASCII characters

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I don't think this is a good idea; I've explained why earlier on this issue.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2642] MSVCRT packing in Windows Installer (3.0a4)

[Wesley Spikes]

New submission from Wesley Spikes <[EMAIL PROTECTED]>:

I've searched and did not find any open ticket to make suggestions on, 
so I'm posting it here.

You currently have posted "The MSI installers for Python 3.0a4 are 
compiled with the new Visual Studio 2008 Professional version. 
Therefore Python depends on the -Visual C++ runtime library 9.0. We 
currently don't package this library properly, which means that non-
Administrator installation is currently not supported. Contributions to 
fix this problem are welcome."

Two potential fixes, both of which should be very readily doable. First 
one is to set the Linking option in MSVC++ to a static link to the CRT. 
This in-builds the library with Python. (Options /MT and /MTd, for 
release and debug versions, respectively.)

The other potential resolution for Non-Admin installs, which may or may 
not be more stable, is to include the MSVCRT DLLs into the directory 
containing the Python installation. If needed, you may have to register 
these files manually into the HKCU hive.

Hope that helps with your described packaging issue with the installer.

(Classified under Build and Installation, since it deals with both 
halves -- feel free to reclassify as appropriate.)

--
components: Build, Installation
messages: 65537
nosy: wesley.spikes
severity: normal
status: open
title: MSVCRT packing in Windows Installer (3.0a4)
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

[Neal Norwitz]

Neal Norwitz <[EMAIL PROTECTED]> added the comment:

So if the fix was applied to 2.5 branch and 2.6 (3.0 should have
picked up from 2.6 automatically), can we close this bug?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

I don't think the fix was acceptable.  Now python spins consuming all
cpu trying to read trivial amounts of data one byte at a time...

See the discusson at the end of http://bugs.python.org/issue1092502 as
well as a recent python-dev thread:

http://mail.python.org/pipermail/python-dev/2008-April/078613.html

--
nosy: +gregory.p.smith

__
Tracker <[EMAIL PROTECTED]>

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

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

or else i'm missing something here in the maze of three bugs talking
about the same issue..

which revisions fixed the introduced performance issue?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Attaching a new patch. I'm not really sure what to do about the hash. I
just removed the Py_SIZE parts. I hope that's OK.

Added file: http://bugs.python.org/file10038/range_eq4.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2630] repr() should not escape non-ASCII characters

[atsuo ishimoto]

atsuo ishimoto <[EMAIL PROTECTED]> added the comment:

Sorry, I missed to write "for interactive session".
I agree for sys.stdout and other files should not have default 
backslashescape, but for iteractive session, I think sys.stdout can 
have backslasespape handler to avoid exceptions.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2603] Make range __eq__ work

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Tue, Apr 15, 2008 at 10:21 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>  I'm not really sure what to do about the hash. I
>  just removed the Py_SIZE parts. I hope that's OK.

If you want to maintain hash(range(a,b,c)) == hash((a,b,c)) invariant,
you need to replace len with 3, not 0.  While I think your latest
implementation is ok, reproducing tuple hash will make correctness
more obvious.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2008] cookielib lacks FileCookieJar class for Safari

[sams.james]

sams.james <[EMAIL PROTECTED]> added the comment:

would you mind posting the read code you have? I would really like to at
least be able to import Safari cookies in an app or two I have lying
around..

--
nosy: +sams.james

__
Tracker <[EMAIL PROTECTED]>

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

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

me and amk are talking about the commit that introduced this bug (which
was meant as a fix for another bug).
neal seems to think that this commit is the fix to this bug itself.
and gregory, you are now confused :)

hope it's clear now.

__
Tracker <[EMAIL PROTECTED]>

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