[issue4888] misplaced (or misleading) assert in ceval.c

[Raymond Hettinger]

Raymond Hettinger  added the comment:

IIRC, I think I put this here a long while ago when replacing or
removing a corresponding if-test that had always been compiled-in.  The
assertion was a way of validating that the refactoring and elimination
of tests had not broken anything.  If that was the case, I prefer to
leave this in, perhaps with some comment.  The control flow and known
conditions at each step are a bit hairy in this part of the code.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue4889] difflib

[Pratik Potnis]

New submission from Pratik Potnis :

While using function HtmlDiff() from Library difflib, if there is
difference in caps of two strings it does not provide proper diff results.
Two strings in two different files in this context that I used are:
hostname vaijain123 and (this string is in small caps)
hostname CAVANC1001CR1 (This one is in large caps)

Expected behavior after diffing : It should show hostname changed (and
highlight it with Yellow color)

instead of this it is showing Added in one file and deleted in another
file. (Highlighting them with green and red color respectively)

When tried with same caps (either small or large) it shows expected
behavior(highlighting the strings in yellow color). Also with numbers it
works well.

I think its an issue with the CAPS of letters. difflib is not able to
differentiate between the caps of letters.

--
components: Library (Lib)
files: c1.ios
messages: 79455
nosy: pratik.potnis
severity: normal
status: open
title: difflib
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12659/c1.ios

___
Python tracker 

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

[issue4888] misplaced (or misleading) assert in ceval.c

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

Sounds like a fine change to me.

--
nosy: +jyasskin

___
Python tracker 

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

[issue4888] misplaced (or misleading) assert in ceval.c

[Skip Montanaro]

New submission from Skip Montanaro :

There is what I believe is a misplaced - or at least misleading - assert
in the while loop following the fast_block_end label.  If why != WHY_YIELD
before the loop starts I don't see how that relationship could change
within the loop.  Proposed patch against py3k branch attached.

(Yes, I realize this is trivial and that the assert is compiled away in
non-debug builds.)

--
files: assert.diff
keywords: patch
messages: 79453
nosy: skip.montanaro
severity: normal
status: open
title: misplaced (or misleading) assert in ceval.c
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12658/assert.diff

___
Python tracker 

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

[issue4881] Python's timezon handling: daylight saving option

[Daniel Diniz]

Daniel Diniz  added the comment:

Pablo,
As Martin says, Python does support DST changes. But it might not have
enough information about your timezone. If that's the case, take a look
at these links to see how adding (up-to-date) support for your tz can be
achieved:

Building a tzinfo class ->
http://svn.python.org/view/python/trunk/Doc/includes/tzinfo-examples.py?rev=62214&view=auto

Using the TZ environment variable ->
http://docs.python.org/dev/library/time.html#time.tzset

HTH, Daniel

--
nosy: +ajaksu2

___
Python tracker 

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

[issue4876] Incorrect detection of module as local

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r68422.

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

done in r68415

--
status: open -> closed

___
Python tracker 

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

[issue4705] python3.0 -u: unbuffered stdout

[STINNER Victor]

STINNER Victor  added the comment:

Updated patch: clear raw on error
+   if (!Py_UnbufferedStdioFlag)
+   Py_XDECREF(raw);

Question: Should we use line_buffering in unbuffered mode?

Added file: http://bugs.python.org/file12657/unbufferedstdout-5.patch

___
Python tracker 

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

[issue4887] environment inspection and manipulation API is buggy, inconsistent with "Python philosophy" for wrapping native APIs

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone :

According to a recent thread on python-dev, Python APIs with the same
name as native APIs can be trusted to just pass through to the platform
API call
(). 
This isn't the case for the environment APIs in the os module.  For
example, os.getenv doesn't always return the actual value of a key in
the environment.  Instead, it looks in the os.environ pseudo-dict to get
the answer.  This can be wrong because os.environ is a *copy* of the
environment which any non-Python API will use, and as a copy it can get
out of sync with the real environment.  One way it can get out of sync
is via os.environ.pop (at least on POSIX - os.environ has different
implementations on different platforms, I find the way an implementation
is selected to be rather confusing and I have not tracked down the
precise behavior for all platforms):

>>> import os
>>> os.environ.pop('PATH')
'/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games'
>>> os.getenv('PATH')
>>> os.system("echo $PATH")
/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
0
>>> 

Another way is via calls to the platform environment manipulation APIs
(setenv, unsetenv or putenv).  These might be invoked by a third-party
library which is exposed to Python or via ctypes.

`environ´ itself is a C API, though it's a char**, whereas os.environ is
a Python dict.  It's probably convenient for os.environ to remain as a
dict, since that's so much simpler to manipulate and inspect than the C
data structure used.  However, it'd be good if were always in sync with
the real process environment.  A good way to do this would probably be
to stop maintaining a copy of the environment and always pass through to
one of the platform APIs to satisfy a method call onto it.

--
components: Library (Lib)
messages: 79448
nosy: exarkun
severity: normal
status: open
title: environment inspection and manipulation API is buggy, inconsistent with 
"Python philosophy" for wrapping native APIs
type: behavior

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
> 
> Marc-Andre, this patch should address your comments.
> 
> Added file: http://bugs.python.org/file12656/decode6.patch

Thanks. Much better !

BTW: I'd also change the variable name "word" to something
different, e.g. bitmap or just data. It looks too much like
a reserved word (which it isn't) ;-)

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Lukas Lueg]

Lukas Lueg  added the comment:

I'll do a patch for 2.7

--
versions: +Python 2.7 -Python 3.1

___
Python tracker 

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

[issue4074] Building a list of tuples has non-linear performance

[Collin Winter]

Collin Winter  added the comment:

Looking at gctrigger5.patch, my only thought is that it would be 
helpful for posterity to include more verbose comments about why this 
new behaviour was chosen; chunks of Martin's proposal from the 
referenced python-dev thread could be included verbatim.

Otherwise, LGTM.

___
Python tracker 

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

[issue4705] python3.0 -u: unbuffered stdout

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If `PyObject_SetAttrString(raw, "_name", text)` fails, a reference to
raw is leaked.
Other than that, the patch looks good.

___
Python tracker 

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

[issue4106] multiprocessing occasionally spits out exception during shutdown

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller
nosy: +jnoller

___
Python tracker 

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

[issue4065] _multiprocessing doesn't build on macosx 10.3

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller
nosy: +jnoller

___
Python tracker 

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

[issue3325] use of cPickle in multiprocessing

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller

___
Python tracker 

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

[issue3551] multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller
nosy: +jnoller

___
Python tracker 

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

[issue3383] ctypes.util fails to find libc in some environments

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, I did mean /usr/sbin at the time, but I don't remember why I said
that. However, I had access to Solaris and AIX machines back then, and
my comment may be related to finding out where objdump was on those
machines.

(sorry, I have a bad memory)

___
Python tracker 

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

[issue4886] test/regrtest.py contains error on __import__

[Michael Yang]

Changes by Michael Yang :


--
type:  -> behavior

___
Python tracker 

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

[issue4886] test/regrtest.py contains error on __import__

[Michael Yang]

New submission from Michael Yang :

I want to use the included test.regrtest (located in 
$pythondir/lib/python[ver]/test) to regression test some of my own 
scripts located in directory myDir.  The script has some nice 
configurability features to skip some tests based on machine 
configurations, etc. that a vanilla unittest suite doesn't include 
automatically.  However, it seems that the script regrtest.py has an 
error following the __import__ line.

Here's my setup:

/sample.py
/myDir
/__init__.py
/test_file1.py
/test_file2.py
/...

in sample.py:

{{{
#!python
#!/usr/bin/env python
import test.regrtest as rt
rt.main(tests = ['myDir.test_file1','myDir.test_file2'], \
quiet = False, verbose = True)
}}}

running sample.py yields:

{{{
#!sh
myDir.test_file1
myDir.test_file1 skipped -- No module named myDir.test_file1
myDir.test_file2
myDir.test_file2 skipped -- No module named myDir.test_file2
2 tests skipped:
myDir.test_file1 myDir.test_file2
2 skips unexpected on win32:
myDir.test_file1 myDir.test_file2
}}}

This is due to the code snippet in regrtest.py around line 554:

{{{
#!python
...
if test.startswith('test.'):
abstest = test
else:
# Always import it from the test package
abstest = 'test.' + test
the_package = __import__(abstest, globals(), locals(), [])
the_module = getattr(the_package, test)
...
}}}

should be changed to:
{{{
#!python
...
if test.startswith('test.'):
abstest = test
modName = test[len('test.'):]
else:
# Always import it from the test package
abstest = 'test.' + test
modName = test
the_package = __import__(abstest, globals(), locals(), [])
the_module = getattr(the_package, modName)
...
}}}

This way, the the_module will correctly find the module name in 
'the_package'.

A further recommendation: the main() module should be able to work with 
test directories with name other than 'test.*'.  Otherwise, users 
wishing to use the main() on other directories will have to name them 
'test.'  Depending on the user's directory's position in sys.path 
(before or after $pythondir/lib/python[ver]), regrtest.main() will 
either fail due to the 'from test import ...' statements being shadowed 
by the user's 'test' directory or the user's 'test' directory being 
shadowed by the standard library's.

--
components: Library (Lib)
messages: 79442
nosy: msyang
severity: normal
status: open
title: test/regrtest.py contains error on __import__
versions: Python 2.6, Python 3.0

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed to py3k in r68411. Please tell me if you intend to do a patch
for 2.7. Otherwise, you/I can close the issue.

--
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Haypo's last patch is ok. If you want it to be in 2.7 too, however,
you'll have to provide another patch (I won't do it myself).

--
resolution:  -> accepted
versions:  -Python 2.7

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Oops, nevermind what I said. The GIL isn't released if obj->lock isn't
there.

___
Python tracker 

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

[issue4751] Patch for better thread support in hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

There is still a potential problem.
Figure the following:
- thread A executes ENTER_HASHLIB while lock is NULL; therefore, thread
A has released the GIL and doesn't hold any lock
- thread B enters EVP_update with a large buffer (it can be there, since
A doens't hold the GIL)
- thread B allocates the lock, releases the GIL, and allocates the lock
- thread A continues running and arrives at LEAVE_HASHLIB; there,
self->lock is not NULL anymore, so it tries to release it; since it
hasn't acquired it before, this may block forever (depending on the
platform I assume)

To remove this possibility, the macros should probably look like:

#define ENTER_HASHLIB(obj) \
{ \
int __lock_exists = ((obj)->lock) != NULL; \
if (__lock_exists) { \
if (!PyThread_acquire_lock((obj)->lock, 0)) { \
Py_BEGIN_ALLOW_THREADS \
PyThread_acquire_lock((obj)->lock, 1); \
Py_END_ALLOW_THREADS \
} \
}

#define LEAVE_HASHLIB(obj) \
if (__lock_exists) { \
PyThread_release_lock((obj)->lock); \
} \
}

___
Python tracker 

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

[issue4881] Python's timezon handling: daylight saving option

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Can you provide more details? What is the specific Python source code
that you are running, what operating system you run it one, what time
zone has been configured into your system, what output do you get, what
output do you expect?

Python definitely does support daylight saving time already just fine.

--
nosy: +loewis

___
Python tracker 

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

[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed

[Martin v. Löwis]

Martin v. Löwis  added the comment:

I think you should study the preprocessor output to find out what
LONG_MAX really expands to, at the point where it is used.

In any case, I'm tempted to close this as "works for me" - 0x7FFFL
is definitely a long constant in all compilers I know of.

--
nosy: +loewis

___
Python tracker 

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

[issue4885] mmap enhancement request

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As for 2), the buffer() function is deprecated and is replaced in 3.0 by
new object called memoryview() (together with a revamped internal API
for taking and releasing buffers).

--
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.5

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Marc-Andre, this patch should address your comments.

Added file: http://bugs.python.org/file12656/decode6.patch

___
Python tracker 

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

[issue4885] mmap enhancement request

[ndbecker]

New submission from ndbecker :

I'd like to suggest some improvements from mmap

1) mmap assign to slice only accepts a string.  This is unfortunate,
because AFAIK a string can only be created by copying data, and this is
wasteful for large data transfers.  mmap should accept any object
supporting buffer protocol as well as string.

2) buffer (mmap_obj) gives a read_only buffer.  There should be a way to
make this read_write.  I suggest 'as_buffer' member.

3) mmap_obj does not support weak ref.  This is needed for proper
lifetime management using boost::python

--
components: Library (Lib)
messages: 79433
nosy: ndbecker
severity: normal
status: open
title: mmap enhancement request
type: feature request
versions: Python 2.5

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
> 
> Attached patch adds acceleration for latin1 and utf16 decoding as well. 
> 
> All three codecs (utf8, utf16, latin1) are now in the same ballpark
> performance-wise on favorable input: on my machine, they are able to
> decode at almost 1GB/s.
> 
> (unpatched, it is between 150 and 500MB/s. depending on the codec)
> 
> Added file: http://bugs.python.org/file12655/decode5.patch

A few style comments:

 * please use indented #pre-processor directives whenever possible, e.g.
   #if
   # define
   #else
   # define
   #endif

 * the conditions should only accept SIZE_OF_LONG == 4 and 8 and
   fail with an #error for any other value

 * you should use unsigned longs instead of signed ones

 * please use spaces around arithmetic operators, e.g. not a+b, but
   a + b

 * when calling functions with lots of parameters, put each parameter on
   a new line (e.g. for unicode_decode_call_errorhandler())

Please also add a comment somewhere to the bit masks explaining what
they do and how they are used. Verbose comments are always good to
have when doing optimizations such as these. Have a look at the
dictionary implementation for what I mean by this.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com



::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(PS : performance measured on UCS-2 and UCS-4 builds with gcc, and under
Windows with MSVC)

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Attached patch adds acceleration for latin1 and utf16 decoding as well. 

All three codecs (utf8, utf16, latin1) are now in the same ballpark
performance-wise on favorable input: on my machine, they are able to
decode at almost 1GB/s.

(unpatched, it is between 150 and 500MB/s. depending on the codec)

Added file: http://bugs.python.org/file12655/decode5.patch

___
Python tracker 

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

[issue4884] Work around gethostbyaddr_r bug

[Jeffrey Yasskin]

New submission from Jeffrey Yasskin :

glibc until 2.10 has a bug in gethostbyaddr_r that assumes the buffer
argument is 8-byte aligned
(http://sources.redhat.com/ml/libc-alpha/2009-01/msg0.html). gcc
seems to always provide such alignment for the call in
socketmodule.c:socket_gethostbyaddr(), but llvm-gcc (possibly only HEAD,
not 2.4) does not, which causes a segfault in test_socket.py. The llvm
bug investigating the problem is http://llvm.org/bugs/show_bug.cgi?id=3233.

The attached patch specifies the alignment so that llvm-gcc and unfixed
glibcs work together.

I'll commit this tomorrow if there are no objections.

--
components: Extension Modules
files: fix_gethostbyaddr.patch
keywords: patch
messages: 79429
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: Work around gethostbyaddr_r bug
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12654/fix_gethostbyaddr.patch

___
Python tracker 

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Ok, I had one +1 from distutils-SIG, so I am updating this patch to
commit it in 2.7 and 3.1.

--
versions:  -Python 3.0

___
Python tracker 

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

[issue3383] ctypes.util fails to find libc in some environments

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I think Antoine meant (and I was just copying him) /bin or /usr/bin. 
The specific case where I encountered the failure was one where PATH was
not set to anything.  The fix in the patch attached to this ticket would
make it much easier to track down why the failure happened, but it
wouldn't fix it.  I guess I'd be satisfied with this, but of course I'd
be happier if it actually worked. :)

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Kevin Watters]

Changes by Kevin Watters :


--
nosy: +kevinwatters

___
Python tracker 

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

[issue4871] zipfile can't decrypt

[Lukas Lueg]

Lukas Lueg  added the comment:

The default encoding is UTF8. Even without that there should be no
problems while staying in the same environment as the
character->translation is the same.

However it violates the rule of least surprise to see zipfile throwing
CRC errors because the password is something like 'u?è´´n' and encoded
by some locale-changing-nitwit in korea...

___
Python tracker 

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

[issue4871] zipfile can't decrypt

[STINNER Victor]

STINNER Victor  added the comment:

> check if 'password' is a unicode-object 
> and encode to default within zipfile. 

Hmmm... what is the default charset? :-) I think that the charset 
depends on the OS and the user locale...

___
Python tracker 

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

[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton  added the comment:

 hmmm... noo, it's already #defined to 0x7fffL in
both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h

so  this works (Include/pyports.h)

#ifdef __WINE__  /* weird: you have to typecast 0x7fffL to long */
#undef LONG_MAX
#undef LONG_MIN
#define LONG_MAX ((long)0x7FFFL)
#define LONG_MIN ((long)(-LONG_MAX-1))
#else
#ifndef LONG_MAX
#if SIZEOF_LONG == 4
#define LONG_MAX 0X7FFFL
#elif SIZEOF_LONG == 8
#define LONG_MAX 0X7FFFL
#else
#error "could not set LONG_MAX in pyport.h"
#endif
#endif

#ifndef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
#endif

#endif /* __WINE__ */

___
Python tracker 

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

[issue4871] zipfile can't decrypt

[Lukas Lueg]

Lukas Lueg  added the comment:

This is basically the same problem as with other bytes-orientated modules.

The choice is either to reject unicode and force the caller to use
.encode() on all his strings (so 'password' is an instance of bytes and
'ch' an instance of int). I'd prefer that.

Or to check if 'password' is a unicode-object and encode to default
within zipfile.

--
nosy: +ebfe

___
Python tracker 

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

[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton  added the comment:

oh, duh - 2L not 1L yes you're right :)

yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is
#defined to 7fff not 7fffL i'll double-check.

you're right that would make life a looot easier.

___
Python tracker 

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

[issue4871] zipfile can't decrypt

[Glade Diviney]

Glade Diviney  added the comment:

In this case under test, the password string had been clipped from a 
filename, so I suppose it would have been Unicode.

___
Python tracker 

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

[issue4883] Compiling python 2.5.2 under Wine on linux.

[Luke Kenneth Casson Leighton]

New submission from Luke Kenneth Casson Leighton :

messy patches which get python 2.5.2 compiling - and producing
python.exe.so - under wine.

the setup.py is presently _wholly_ unsuited to use for building
the modules - get_sysconfig("srcdir") returns None because...
it's supposed to!

but, the actual libpython2.5.a and the actual python.exe _are_
successfully built - and, amazingly, useable.

--
components: Build
files: f
messages: 79420
nosy: lkcl
severity: normal
status: open
title: Compiling python 2.5.2 under Wine on linux.
versions: Python 2.5
Added file: http://bugs.python.org/file12653/f

___
Python tracker 

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

[issue3383] ctypes.util fails to find libc in some environments

[Matthias Klose]

Matthias Klose  added the comment:

I think 4861 provides a solution for this issue. I don't see any system
where objdump is in /sbin or /usr/sbin.

--
nosy: +doko

___
Python tracker 

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

[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed

[Mark Dickinson]

Mark Dickinson  added the comment:

Interesting.  How many of those casts are actually necessary to make 
things work?  Have you figured out more precisely why this is failing?
E.g., is it somehow that LONG_MIN ends up being an unsigned constant?

It seems to me that a better fix would be to fix LONG_MIN and LONG_MAX 
somewhere in the configuration files;  there are bound to be more uses of 
LONG_MIN and LONG_MAX in the source that are going to cause problems.

P.S.  Looking at your python-dev messages, does len([1, 2]) really return 
1L?  Not 2L?

--
nosy: +marketdickinson

___
Python tracker 

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

[issue4882] Behavior of backreferences to named groups in regular expressions unclear

[alec resnick]

New submission from alec resnick :

I recently learned about named groups in Python regular expressions. 
Almost all the documentation I've found online explains what they are
and give a simple example of how to use them.  I was trying to use the
variables outside of the original regex, later in the code.  Nowhere in
the documentation I found after a couple hours of searching was it
mentioned that named groups can only be backreferenced _within_ the pattern.

In particular, the sections at
http://www.amk.ca/python/howto/regex/#SECTION00053 and
the description of the (?P) behavior at
http://docs.python.org/library/re.html could be modified to make it
clear that the named capture does not create a variable usable outside
of the pattern.

I would be happy to alter the documentation appropriately.

--
assignee: georg.brandl
components: Documentation
messages: 79417
nosy: aresnick, georg.brandl
severity: normal
status: open
title: Behavior of backreferences to named groups in regular expressions unclear
type: feature request
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

[issue4868] Faster utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Attached patch
> (utf8decode4.patch) changes this and may enter the fast loop on the
> first character.

Thanks!

> Does this idea apply to the encode function as well?

Probably, although with less efficiency (a long can hold 1, 2 or 4
unicode characters depending on the build).
The unrolling part also applies to simple codecs such as latin1.
Unrolling PyUnicode_DecodeLatin1 a bit (4 copies per iteration) makes it
twice faster on non-tiny strings. I'll experiment with utf16.

___
Python tracker 

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

[issue4881] Python's timezon handling: daylight saving option

[Pablo Castagnino]

New submission from Pablo Castagnino :

Something in python's timezone handling needs to be
updated. Python does not take into account 'daylight saving' clock time
changes.

The thing is my clock time is correct. If you
ask anyone here for the time, they will tell you it's X. However, Python
believes (correct) current time is X + 1 hour. In fact, this is the case
most of the time, but because of 'daylight saving' measures, official
time has been changed. So, without a doubt, this needs to be fixed.

A solution could be adding the possibility to set a 'daylight saving'
option which helps dealing with this. So, if I set this option to 3600
secs, then Python could +/- this remainder to the, let's call it,
'expected current time' according to the timezone.

--
components: Library (Lib)
messages: 79415
nosy: earendili510
severity: normal
status: open
title: Python's timezon handling: daylight saving option
type: feature request

___
Python tracker 

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

[issue4861] fix problems with ctypes.util.find_library

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

This seems to be a partial duplicate of 3383.  A suggestion on that
ticket was to look for objdump in PATH and then try /usr/sbin.

--
nosy: +exarkun

___
Python tracker 

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Jason Tishler]

Jason Tishler  added the comment:

Sorry for the delay, but I was on vacation and then recovering from 
vacation...

You are correct that my initial patch does not handle the case when 
DESTDIR is not specified.  Your suggestion will work, but seems hacky.

What about adding the defaulting of DESTDIR to "/" to my initial 
patch?  This seems cleaner.  See my second patch for the details.

If this approach is acceptable, then feel free to move the defaulting 
of DESTDIR to a more appropriate place in Makefile.pre.in.  I wasn't 
sure where to put this change.

Added file: http://bugs.python.org/file12652/Makefile.pre.in.diff

___
Python tracker 

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

[issue4861] fix problems with ctypes.util.find_library

[Matthias Klose]

Matthias Klose  added the comment:

new version of the patch using os instead of platform, and selecting the
correct library for biarch platforms, tested on ia64, sparc, s390,
amd64, ppc64. unsure if there's a better way to find out if the
executable is 32 or 64bit.

Added file: http://bugs.python.org/file12651/ctypes-findlib.diff

___
Python tracker 

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

[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed

[Luke Kenneth Casson Leighton]

New submission from Luke Kenneth Casson Leighton :

there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)

PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
{
return PyInt_FromLong((long)ival);
}
return _PyLong_FromSsize_t(ival);
}

--
messages: 79411
nosy: lkcl
severity: normal
status: open
title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
versions: Python 2.5

___
Python tracker 

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

[issue4879] Allow buffering for HTTPResponse

[Kristján Valur Jónsson]

Changes by Kristján Valur Jónsson :


--
title: Allo buffering for HTTPResponse -> Allow buffering for HTTPResponse

___
Python tracker 

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

[issue4862] utf-16 BOM is not skipped after seek(0)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-01-07 01:21, Amaury Forgeot d'Arc wrote:
> First write a utf-16 file with its signature:
> 
 f1 = open('utf16.txt', 'w', encoding='utf-16')
 f1.write('0123456789')
 f1.close()
> 
> Then read it twice:
> 
 f2 = open('utf16.txt', 'r', encoding='utf-16')
 print('read1', ascii(f2.read()))
> read1 '0123456789'
 f2.seek(0)
> 0
 print('read2', ascii(f2.read()))
> read2 '\ufeff0123456789'
> 
> The second read returns the BOM!
> This is because the zero in seek(0) is a "cookie" which contains both the 
> position 
> and the decoder state. Unfortunately, state=0 means 'endianness has been 
> determined: 
> native order'.
> 
> maybe a suggestion: handle seek(0) as a special value which calls 
> decoder.reset().
> The patch implement this idea.

This is a problem with the utf_16.py codec, not the io layer.
Opening a file in append mode is something that the io layer
would have to handle, since the codec doesn't know anything about
the underlying file mode.

Using .reset() will not help. The code for the StreamReader
and StreamWriter in utf_16.py will have to be modified to undo
the adjustment of the .encode() and .decode() method after using
.seek(0).

Note that there's also the case .seek(1) - I guess this must
be considered as resulting in undefined behavior.

--
nosy: +lemburg

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Very nice! It seems that you can get slightly faster by not copying the
initial char first: 's' is often already aligned at the beginning of the
string, but not after the first copy... Attached patch
(utf8decode4.patch) changes this and may enter the fast loop on the
first character.

Does this idea apply to the encode function as well?

--
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file12650/utf8decode4.patch

___
Python tracker 

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

[issue1202] zlib.crc32() and adler32() return value

[J. David Ibáñez]

J. David Ibáñez  added the comment:

I believe I have hit this bug. With Python 2.6.1 in a Gentoo Linux
64 bits.

This code:

  from zipfile import ZipFile
  inzip = ZipFile('Document.odt')
  outzip = ZipFile('out.zip', 'w')
  for f in inzip.infolist():
  if f.filename != 'content.xml':
  print f.filename, '(CRC: %s)' % f.CRC
  outzip.writestr(f, inzip.read(f.filename))
  outzip.close()

Produces this output:

  ...
  styles.xml (CRC: 3930581528)
  test_odt.py:10: DeprecationWarning: 'l' format requires -2147483648 <=
number <= 2147483647
outzip.writestr(f, inzip.read(f.filename))
  ...

The CRC is not a 32bits signed, and then the module struct complains,
here:

  zipfile.py:1098
  self.fp.write(struct.pack("

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

[issue4336] Fix performance issues in xmlrpclib

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Reopening this, since I am not entirely happy with the implementation 
that was checked in.  Please see my comments from Dec 5th onwards.

--
status: pending -> open

___
Python tracker 

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

[issue4879] Allo buffering for HTTPResponse

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

This is related to issue 4336.  While that issue finally revolved around 
fixing the Nagle problem for xmlrpc and other http clients, here I 
propose to fix another performance bottleneck with xmlrpc, reading the 
HTTP Headers.
HTTPResponse creates a socket.fileobject() with zero buffering which 
means that the readline() operations used to read the headers become 
very inefficient since individual socket.recv() calls are used for each 
character.
The reason for this is to support users who subsequently do 
socket.recv() on the underlying socket, and so we don't want to read too 
much of the headers. Note that there is no example of this in the 
standard library.
In the provided patch, I have removed some vestigial code from 
xmrlpclib.py which attempted to use recv() even though it never did 
(because the connection has been closed when HTTPConnection returns the 
response).  Even so, Guido has expressed his concern that we need to 
keep the support for this recv() behaviour in place.
Therefore, I have added a new optional argument, nobuffer=True, which 
users that promise not to call recv() can set to false.  This will then 
cause the generated fileobject from HTTPResponse to have default 
buffering, greatly increasing the performance of the reading of the 
headers.

--
components: Library (Lib)
files: nobuffer.patch
keywords: patch, patch
messages: 79406
nosy: krisvale
severity: normal
status: open
title: Allo buffering for HTTPResponse
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12649/nobuffer.patch

___
Python tracker 

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

[issue4867] crash in ctypes when passing a string to a function without defining argtypes

[Thomas Heller]

Thomas Heller  added the comment:

Fixed in release30-maint, rev. 68402 and py3k, rev. 68401.
Thanks for the patch.

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

[issue4878] post installer script's message is not shown to user with bdist_wininst

[Juha Rantanen]

New submission from Juha Rantanen :

1. Create installer with bdist_wininst with python version 2.5
2. Install it to 2.6 Python. 
3. The post installer message is not shown to user in the installer window.
4. Remove the installation from add/remove programs.
5. Messages coming from removing are not shown to the user.


This same happens if the installer is created with python 2.6 and it is
installed to 2.5 Python. See attached project, which can be used to
create the installer which contains post installer script.

--
components: Distutils
files: simple.zip
messages: 79404
nosy: rantanen
severity: normal
status: open
title: post installer script's message is not shown to user with bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12648/simple.zip

___
Python tracker 

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

[issue4867] crash in ctypes when passing a string to a function without defining argtypes

[Thomas Heller]

Thomas Heller  added the comment:

The patch is fine, no need for another diff.

--
resolution:  -> accepted
versions: +Python 3.1

___
Python tracker 

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

[issue4874] decoding functions in _codecs module accept str arguments

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-01-08 01:59, STINNER Victor wrote:
> STINNER Victor  added the comment:
> 
> Patch replacing "s*" parsing format by "y*" for:
>  - utf_7_decode()
>  - utf_8_decode()
>  - utf_16_decode()
>  - utf_16_le_decode()
>  - utf_16_be_decode()
>  - utf_16_ex_decode()
>  - utf_32_decode()
>  - utf_32_le_decode()
>  - utf_32_be_decode()
>  - utf_32_ex_decode()
>  - latin_1_decode()
>  - ascii_decode()
>  - charmap_decode()
>  - mbcs_decode()

These are fine.

>  - unicode_escape_decode()
>  - raw_unicode_escape_decode()

These changes are in line with their C API codec interfaces as well,
but those particular codecs could well also be made to work on Unicode
input, since unescaping can well be applied to Unicode as well.

I'll probably open a new item for this.

> Using run_tests.sh, all tests are ok (with 19 skipped tests). I guess 
> that there is not tests for all these functions :-/

The mbcs codec is only available on Windows.

All others are tested by test_codecs.py.

Which ones are skipped in your case ?

> Note: codecs documentation was already correct:
> 
> .. method:: Codec.decode(input[, errors])
>(...)
>*input* must be a bytes object or one which provides the read-only 
> character
>buffer interface -- for example, buffer objects and memory mapped 
> files.

That's not entirely correct: codecs are allowed to accept any
object type and can also return any object type. It up to them
to decide, e.g. a codec may accept both bytes and Unicode input
and always generate Unicode output when decoding.

I guess I have to review those doc changes...

--
nosy: +lemburg

___
Python tracker 

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

[issue4814] ftplib does not honour "timeout" parameter for active data connections

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file12552/ftplib.patch

___
Python tracker 

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