[issue7467] The zipfile module does not check files' CRCs, including in ZipFile.testzip

[Douglas Turk]

New submission from Douglas Turk :

The zipfile module does not calculate the CRC of files in a zipfile as
they are read as of Python 2.6. The old ZipFile.read function in Python
2.5 used to do this, and ZipFile.testzip appears to rely on ZipFile.read
to check the CRC. This means that ZipFile.testzip does not check the CRC
as it is documented to.

It would be useful if ZipExtFile could check the CRC once it had read
all the data, because this would mean that e.g. ZipFile.extract would
also automatically check the CRC. Perhaps ZipExtFile.read could raise a
BadZipFile exception if it reaches EOF and the CRC is wrong.

Steps to reproduce:
-Create a zip file, then change a byte in a file's contents (easiest if
files are stored, not deflated).
-Run ZipFile.testzip on the edited file. Note that it does not report a
CRC failure, but other zip tools do.

I can provide a patch in a couple of days if that's useful.

--
components: Library (Lib)
files: test.zip
messages: 96194
nosy: dougturk
severity: normal
status: open
title: The zipfile module does not check files' CRCs, including in 
ZipFile.testzip
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15515/test.zip

___
Python tracker 

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

[issue6692] asyncore kqueue support

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> josiahcarlson
nosy: +josiahcarlson
priority:  -> normal
stage:  -> needs patch

___
Python tracker 

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

[issue7465] Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times

[R. David Murray]

R. David Murray  added the comment:

Heh, that first b = baseClass(); del b wasn't supposed to be there and
doesn't change the result, just in case you were wondering.

--

___
Python tracker 

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

[issue7465] Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times

[R. David Murray]

R. David Murray  added the comment:

Yes, this working as intended.  Consider:

Python 2.7a1+ (trunk:76725, Dec  9 2009, 09:26:36)
[GCC 4.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class baseClass(object):
... def __init__(self, testList=[]):
... self.testList = testList
... def insertItem(self):
... self.testList.append("testing from baseClass")
...
>>> a = baseClass()
>>> b = baseClass()
>>> del b
>>> a.insertItem()
>>> print a.testList
['testing from baseClass']
>>> b = baseClass()
>>> print b.testList
['testing from baseClass']


See
http://docs.python.org/faq/design.html#why-are-default-values-shared-between-objects
for an explanation of why.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue7466] Segmentation fault after about 20 seconds on lenovo T500

[David W. Lambert]

David W. Lambert  added the comment:

Further isolation, following change removes segmentation fault: 

digital_roots = tuple(map(digital_root,factorization))

becomes

digital_roots = [digital_root(factor) for factor in 
factorization]

--

___
Python tracker 

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

[issue7465] Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times

[Aaron Altman]

Changes by Aaron Altman :


--
title: Call to another class's constructor in unittest.TestCase.setUp returns 
the same instance -> Call to another class's constructor in 
unittest.TestCase.setUp returns the same instance multiple times

___
Python tracker 

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

[issue7466] Segmentation fault after about 20 seconds on lenovo T500

[David W. Lambert]

New submission from David W. Lambert :

'''
This brute [possibly a] solution to

http://projecteuler.net/index.php?section=problems&id=159

causes segmentation fault.


$ p3 # an AMD 64 bit build.
Python 3.1.1 (r311:74480, Oct  2 2009, 12:29:57) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>>


The block between "load_primes" and "print(result)" can be written
as a single statement using various comprehensions.  sum(max(...))
The program does not seg-fault this way, but the result was wrong.
I unrolled the code to fix my algorithm, disclosing the segmentation 
fault.
'''

import functools
import operator
import itertools
import array

PrimeQ = Primes = 'use load_primes(n) function'

def load_primes(n):
global PrimeQ,Primes
PrimeQ = sieve(1+n)
Primes = array.array('L',(i for (i,Q,) in enumerate(PrimeQ) if Q))

def sieve(n):
a = array.array('b',(True,))*n
a[0] = a[1] = False
for (i,j) in enumerate(a):
if j:
for k in range(i**2,n,i):
a[k] = False
return a

def PrimeRange(a):
'''
see "load_primes"
'''
n = 1+int(a**(1/2))
for p in Primes:
if n < p:
raise StopIteration
yield p

def PrimeFactor(a):
'''
see "load_primes"

>>> load_primes(30)
>>> print([PrimeFactor(x)for x in (6,7,)])
[[2, 3], [7]]
'''
if (a < len(PrimeQ)) and PrimeQ[a]:
return [a]
for p in PrimeRange(a):
(q,r,) = divmod(a,p)
if not r:
return [p]+PrimeFactor(q)
return [a]

def product(a):
return functools.reduce(operator.mul,a,1)

def digital_root(n):
while 9 < n:
n = sum(map(int,str(n)))
return n

def partition(L, chain=itertools.chain):
'''
python recipe by Ray Hettinger
'''
s = L
n = len(s)
first, middle, last = [0], range(1, n), [n]
return [[L[a:b] for (a,b) in zip(chain(first, div), chain(div, 
last))]
for i in range(n) for div in itertools.combinations(middle, 
i)]





load_primes(1000)

s = 0
for n in range(2,10**6):
factorizations = [
[product(p)for p in group]for group in 
partition(PrimeFactor(n))]
mx = 0
for factorization in factorizations:
digital_roots = tuple(map(digital_root,factorization))
sdr = sum(digital_roots)
mx = max(mx,sdr)
s += mx

print('result!',s)

--
messages: 96190
nosy: LambertDW
severity: normal
status: open
title: Segmentation fault after about 20 seconds on lenovo T500
type: crash
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

[issue7465] Call to another class's constructor in unittest.TestCase.setUp returns the same instance

[Aaron Altman]

New submission from Aaron Altman :

Not sure if this is intended behavior.  I have a baseClass I'm writing
tests for.  My test architecture has an instance of this baseClass
assigned as a member of TestBaseClass(unittest.TestCase) in
TestBaseClass.setUp.

The problem occurs when tests in TestBaseClass modify state within the
member baseClass instance.  I think there should be a fresh new instance
of baseClass for every test that gets run, but the old state from the
last test is still there.

Example code and output from Python 2.6.2 attached.

--
components: Library (Lib), Tests
files: unittest_doesnt_reinstantiate_members.txt
messages: 96189
nosy: awaltman
severity: normal
status: open
title: Call to another class's constructor in unittest.TestCase.setUp returns 
the same instance
versions: Python 2.6
Added file: 
http://bugs.python.org/file15514/unittest_doesnt_reinstantiate_members.txt

___
Python tracker 

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

[issue7459] Magic word incorrect in Python 3

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r76731. Thanks.

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

Committed to py3k in r76730 with the suggested additional test.

--

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

Unfortunately, the SocketServer patches introduced other issues (see for
example issue 6381).  So I'm reluctant to backport those changes, since
as you say no one had reported problems.  It seems like the chance of
inadvertently breaking someone's working 2.6 code is too high given the
absence of any actual bug report that we'd be fixing.

So I'm inclined to go with your revised test for the 2.6 backport of
this bugfix.

--

___
Python tracker 

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

[issue1123727] gensuitemodule.processfile fails

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
priority: normal -> low

___
Python tracker 

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

[issue6692] asyncore kqueue support

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue7154] urllib.request system proxy configuration lookup broken for OS X in Python 3

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I agree that _scproxy should be ported to the 3.x trees. Such a port 
should be fairly straightforward, but is harder than just copying files 
over due to the str/unicode changes in the 3.x tree.

--

___
Python tracker 

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

[issue6834] use different mechanism for pythonw on osx

[Ronald Oussoren]

Ronald Oussoren  added the comment:

FWIW: I now have a 2.7 tree with the new pythonw on my machine, open 
issues are:

* Ensure IDLE.app gets build in such a way that the GUI works for
  all supported universal binaries (including a 4-way build on 10.5, 
  where the system Tk doesn't work in 64-bit mode)

* Update NEWS file

* Port to 3.2

--

___
Python tracker 

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

[issue7452] Invalid mnemonic 'fnstcw'

[Ronald Oussoren]

Ronald Oussoren  added the comment:

BTW. Am I correct when I state that this issue has been fixed and can be 
closed?

--

___
Python tracker 

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

[issue7452] Invalid mnemonic 'fnstcw'

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Ned: the best way to ensure universal builds don't get broken is through 
the buildbots. AFAIK there are no buildbots that create universal 
binaries at the moment. Sadly enough I don't have the resources to 
provide one.

Mark: Mac/README explains how to build universal binaries and 
Mac/BuildScript/build-installer.py is used to build the default binary 
installer. 

To build a universal binary framework:


../configure \
--enable-framework   \  # Creates a framework
--enable-universalsdk  # Create universal binary using 10.4 SDK
make
make install

The build can be tweaked using a number of options:

* Use an alternate SDK:
   --enable-universalsdk=PATH

  (I tend to use --enable-universalsdk=/ for my private builds,
   the 10.4u SDK is used in the default installers to ensure that
   users on 10.4 PPC can build universal extensions)

* Select architectures to include in the build:   
   --with-universal-archs=VALUE

* Pick an alternate framework name:
--with-framework-name=NAME

* Pick a different deployment target:

MACOSX_DEPLOYMENT_TARGET=X.Y

  (Default is 10.3 for 32-bit builds and 10.5 for builds that include
   a 64-bit architecture).

BTW. I agree that the current configure script sucks, it is very hard
to tweak it beyond adding simple feature tests. IIRC it has taken me
several Python releases to reliably run the feature detection tests 
because some compiler flags didn't get exported correctly to the bits
of the configure script that runs the feature tests.

One way to improve on the script is to create a number of clearly 
labeled sections, such as: compiler/platform setup,  architecture tests
(SIZEOF_* detection, X86_FPU tests, ...), platform feature tests. 

The architecture tests could then be prepended with a comment block
that explains how to deal with them for universal builds on OSX.

--

___
Python tracker 

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

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

[flox]

flox  added the comment:

Patch for the documentation. (source: upstream documentation)

--
Added file: http://bugs.python.org/file15513/issue6472_upstream_docs.diff

___
Python tracker 

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

[issue6911] Document changes in asynchat

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Scott Dial  added the comment:

It seems that on the py3k branch, the EOF situation is handled roughly
in the same manner (the broken line is returned) and ultimately the
IMAP4.abort exception is raised because b'* ' is an invalid response
(the 'OK' having been dropped). IOW, it passes the EOF test only because
trimming broke the welcome message format. If it got an EOF in the
middle of a more complicated response, it would go undetected or cause a
broken response.

I propose adding the following test case:

@reap_threads
def test_line_termination(self):

class BadNewlineHandler(SimpleIMAPHandler):

def cmd_CAPABILITY(self, tag, args):
self._send(b'* CAPABILITY IMAP4rev1 AUTH\n')
self._send('{} OK CAPABILITY
completed\r\n'.format(tag).encode('ASCII'))

with self.reaped_server(BadNewlineHandler) as server:
self.assertRaises(imaplib.IMAP4.abort,
  self.imap_class, *server.server_address)

Which silently misreads the CAPABILITY response as including "AUT" and
not "AUTH". It would be a perversely broken server, but I think this
test case demonstrates why an explicit check and exception should be
thrown always.

--

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

I'll take a look at the socketserver issue, but probably not today.

In the meantime, can you take a look at this port of the tests to py3k
when you get a chance?  The tests pass without changes to imaplib, but
the imaplib code is a bit different in py3k.  I'd like your opinion on
whether the fact that _get_line unconditionally chomps the last two
bytes is a bug waiting to happen in some other context, even though it
doesn't happen in this particular one in py3k.

--
Added file: http://bugs.python.org/file15512/test_imaplib_issue5949_py3k.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Scott Dial  added the comment:

I've revised my opinion. If you extract out only the changes to
SocketServer and ignore the others, then I would consider it a good
backport (fixes bugs only). I have attached such a patch.

BTW, with this patch, you can remove the shutdown() call in the
test_imaplib patch.

--
Added file: http://bugs.python.org/file15511/socketserver_issue_6267.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Scott Dial  added the comment:

I tracked the necessary change to r73638 and issue6267. However, I am
not sure it is in scope to backport all of that.

The only changed actually needed from this set to make SocketServer
behave correctly with a SSLSocket is:

 def close_request(self, request):
 """Called to clean up an individual request."""
+#explicitly shutdown.  socket.close() merely releases
+#the socket and waits for GC to perform the actual close.
+request.shutdown(socket.SHUT_WR)
 request.close()

Hence in my py26 patch, I have made a call to shutdown() within the
handler. I would call this a bug, but nobody seems to have noticed but
me, so I defer to you about the best solution.

--

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

Do you know which patches?  It's possible they just haven't been
evaluated for backport yet, and if that's so I'll see if I can take care
of it.

--

___
Python tracker 

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

[issue7464] circular reference in HTTPResponse by urllib2

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

in urllib2, you will find these lines:
# Wrap the HTTPResponse object in socket's file object adapter
# for Windows.  That adapter calls recv(), so delegate recv()
# to read().  This weird wrapping allows the returned object to
# have readline() and readlines() methods.

# XXX It might be better to extract the read buffering code
# out of socket._fileobject() and into a base class.

r.recv = r.read
fp = socket._fileobject(r, close=True)

This, storing a bound method in the instance, will cause a reference 
cycle that the user knows nothing about.

I propose creating a wrapper instance with a recv() method instead.  Or, 
is there a standard way of storing bound methods on instances?  A 
'weakmethod', perhaps?

--
components: Library (Lib)
messages: 96175
nosy: krisvale
severity: normal
stage: needs patch
status: open
title: circular reference in HTTPResponse by urllib2
type: resource usage
versions: Python 2.5, Python 2.6

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Changes by Scott Dial :


Removed file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Scott Dial  added the comment:

I have attached a proper backport for the 2.6 maintenance branch. There
were some features (not bugfixes) of the trunk that the tests depended
on, which are not backported.

However, the tests still hang, because there are changes to
SocketServer.py that were not backported to 2.6. The changes are needed
to properly call close() on the underlying socket of the SecureTCPServer
and thus trigger the EOF. To avoid the backporting of bits in
SocketServer, I hacked the necessary bits into this version of the tests.

--
Added file: http://bugs.python.org/file15510/test_imaplib_issue5949-py26.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Changes by Scott Dial :


Removed file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Changes by Scott Dial :


Added file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch

___
Python tracker 

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

[issue7316] Add a timeout functionality to common locking operations

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> pitrou
stage:  -> patch review

___
Python tracker 

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

[issue7452] Invalid mnemonic 'fnstcw'

[Ned Deily]

Ned Deily  added the comment:

Mark, I wasn't ranting at you or Ronald or anyone in particular.  It's no 
secret that Python's build system is complex and fragile in some areas.  
On the other hand, the build system is ambitious, covering a wide variety 
of platforms and variants, and is largely successful.  In particular, 
supporting multi-architecture builds across multiple OS levels for OS X 
is, IMO, a Good Thing to be doing. But there is a cost for all that.  It 
would be good to be able to scrape away some of the overall cruft that's 
accumulated over the many years.  Hmm, a GSOC project to implement SCons 
builds for the current platforms and to facilitate cross-platform builds?  
Anyway, I did indeed mean Include/pymacconfig.h.

--

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[Scott Dial]

Changes by Scott Dial :


Added file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch

___
Python tracker 

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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

Added skipping of the SSL tests if ssl is not available in r76727.

--

___
Python tracker 

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

[issue7459] Magic word incorrect in Python 3

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> benjamin.peterson

___
Python tracker 

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

[issue7451] improve json decoding performance

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I wonder if you can make a patch for 2.6 python branch.

No, 2.6 doesn't have the same C accelerator 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

[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

[R. David Murray]

R. David Murray  added the comment:

Applied to trunk in r76276.  However, when I tried to backport it to
2.6, the tests hang in test_connect for the SSL version.  The hang isn't
interruptible by ctl-C.  Perhaps there's some SSL fix that hasn't been
backported, and if so it would be nice to figure out if it can be
backported.  (Note, to backport the tests I removed the 'reap_threads'
context manager calls and replaced it with a reap_children call at the
end of test_main).

--
stage: patch review -> commit review

___
Python tracker 

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

[issue7451] improve json decoding performance

[Valentin Kuznetsov]

Valentin Kuznetsov  added the comment:

I wonder if you can make a patch for 2.6 python branch.

--

___
Python tracker 

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

[issue7452] Invalid mnemonic 'fnstcw'

[Mark Dickinson]

Mark Dickinson  added the comment:

A reply to Ned from the person who introduced this bug in the first
place (sorry, folks):

[Ned]
> 1. How to make core developers and patch contributors more aware of the 
> special requirements of multi-architecture builds?

I guess I was already aware of this, at least after Ned (IIRC), some
months ago, detected essentially the same problem in py3k after we'd put
the short float repr in.  So this was really just sloppiness on my part.
 I did testing of the short float repr for single-architecture builds on
OS X 10.4/PPC (32-bit), OS X 10.5/Intel (32-bit and 64-bit) and OS X
10.6/Intel (64-bit only), but still missed this.

Something that I would have found helpful at one stage would be
prominent instructions (somewhere, maybe in the python-dev FAQ?) for
creating and testing multi-architecture builds on various OS X versions.
 Perhaps all those instructions need to do is to point to the
Mac/BuildScript/README.txt?  Even now, I'm still not 100% clear on
exactly which selection of options should be supplied to the configure
scripts, and why.

> At a minimum, I would like to see a message added to configure.in that 
> is output on OS X to warn that some of the autoconf derived values for 
> architecture-specific SIZEOF and processor features are overridden in 
> Include/pyconfig.h.

Do you mean Include/pymacconfig.h?  If so, I agree such a warning would
be good to have.

As an aside, I *think* it's actually safe just to undefine
HAVE_GCC_ASM_FOR_X87 unconditionally on OS X:  the inline assembler that
it enables is only ever used for machines which suffer from double
rounding, which is a symptom of using the x87 FPU for basic arithmetic.
gcc on OS X (either Apple gcc or GNU gcc) always seems to use SSE2
instructions for arithmetic, even for 32-bit builds, so the fnstcw and
fldcw instructions aren't ever needed or used on OS X.

--

___
Python tracker 

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

[issue7459] Magic word incorrect in Python 3

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue7459] Magic word incorrect in Python 3

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think the point is more of self-documentation not being deceiving.
Here someone tries to use import.c 's embedded documentation about
existing magic numbers and he/she gets mystified because the actual
magic number doesn't seem to correspond.

Also, it's true that the "Unicode mode fixup" is obsolete and should be
removed anyway.

--
nosy: +pitrou

___
Python tracker 

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

[issue7463] PyDateTime_IMPORT() causes compiler warnings

[Murray Cumming]

New submission from Murray Cumming :

At least in Python 2.5 and 2.6 (I haven't checked newer versions), the 
PyDateTime_IMPORT() macro passes string literals to a function that
takes non-const char* parameters:

#define PyDateTime_IMPORT \
PyDateTimeAPI = (PyDateTime_CAPI*) PyCObject_Import("datetime", \
"datetime_CAPI")

This makes it impossible to build code with warnings as errors, when
using that macro.

--
components: None
messages: 96166
nosy: murrayc
severity: normal
status: open
title: PyDateTime_IMPORT() causes compiler warnings
type: compile error
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

[issue7452] Invalid mnemonic 'fnstcw'

[Ned Deily]

Ned Deily  added the comment:

I agree that adding the definitions of HAVE_GCC_ASM_FOR_X87 to 
pymacconfig.h solves the problem.

[mini-rant on]
This problem is another illustration of how easy it is to inadvertently 
introduce significant bugs in the OS X multi-architecture support, bugs 
which can currently go undetected without a lot of diligence on 
everyone's part.  We were lucky on this one.  Thanks, Sridhar.
[mini-rant off]

After digging around a lot, I see now why I hadn't noticed it before.  Always 
specifying --enable-universalsdk=/Path/To/sdk and default arch 
options (as the current installer builds do) causes configure to include 
-arch ppc and -arch i386 in CFLAGS and these get added to the gcc call 
in autoconf tests AC_TRY_COMPILE and AC_TRY_RUN.  That meant the 
autoconf test for HAVE_GCC_ASM_FOR_X87 was *always* NO because the PPC 
arch compile always failed on the Intel assembler code test.  And the 
compile failure is not obvious unless you examine configure.log in 
detail and notice that the result of the test was NO because of the 
multiple architectures.

If configure is called with just --enable-universalsdk (no path) but on 
10.5 or 10.6, the multiple archs still get added to CFLAGS, the test 
returns NO again, and the problem is still masked:

CFLAGS='-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
g -O2'

But if you make that same configure call on 10.4, the multiple archs are 
not added:

CFLAGS='-g -O2'

On a 10.4 PPC system (my case) the test *still* returns NO so the 
problem is *still* masked.  It's only if you run the build with that 
configure on a 10.4 i386 system that the test will pass, causing 
HAVE_GCC_ASM_FOR_X87 to finally be defined.  Then, during the make of 
the multi-architecture build, the root problem will finally be exposed, 
as it was here.

That also means that, for multi-arch builds on OS X, the X87 control 
word code would never be used in the python.org installers or any other 
intel/ppc multi-architecture build.

I hope that is a reasonably close to correct analysis but I could have a 
few details wrong. It's clearly easy to get wrong.

Looking elsewhere in configure.in, there are other architecture-specific 
run-time tests that could give incorrect results in a multi-arch 
environment.  The math tests immediately following appear to take a 
conservative approach so I'm guessing that, if there were conflicting 
results during the multiple arch compiles and runs, the code would work 
correctly though possibly sub-optimally.  I didn't see any other obvious 
incorrect results although it is difficult to tell when so many 
configure tests get compile or build errors by design.

There seem to be at least two issues brought out here:

1. How to make core developers and patch contributors more aware of the 
special requirements of multi-architecture builds?

2. What, if any, additions or changes to tests and testing process 
should be made to help catch problems like this (and others that might 
be lurking)?

At a minimum, I would like to see a message added to configure.in that 
is output on OS X to warn that some of the autoconf derived values for 
architecture-specific SIZEOF and processor features are overridden in 
Include/pyconfig.h.  Currently there doesn't seem to be any reference to 
this in configure.in and it so easy to be misled by the autoconf 
results.  Adding comments to the source of the overridden tests would be 
great but a bit of work.  Conditionally skipping the tests would be even 
better, if it could be made to work.  A more systematic test process 
would also help.

--

___
Python tracker 

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