This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jason.Scheirer
Recipients Jason.Scheirer, amaury.forgeotdarc, brian.curtin, gfe, josiahcarlson, loewis, tim.golden, tim.peters
Date 2010-12-17.22:56:27
SpamBayes Score 5.40068e-13
Marked as misclassified No
Message-id <1292626590.62.0.611321018155.issue1449496@psf.upfronthosting.co.za>
In-reply-to
Content
I would like to see this reopened: we have a very large class of users that are not ready to entirely port to 64-bit and need this now.

When running a Python script from within a desktop application (which embeds Python and has /LARGEADDRESSAWARE set) or outside in Python.exe (which does not) results in the outputs from the tools calling out to these 32 bit libraries to produce different outputs because the amount of data they are able to allocate and process at the same time. The same Python script that gives correct output on a large dataset in this desktop app will not yield the same quality of results when run overnight as a stand-alone Python script. Essentially this discounts Python scripts as an option for automation in this case.

I understand that yes, applications still cannot allocate more CONTIGUOUS memory, but this is not a regression if it continues to be so. Allowing the process to allocate more TOTAL memory is a net benefit, especially on on complex software systems that can't simply be rebuilt in 64 bit mode due to third-party restraints (tied to a specific library version, lack of access to source, lengthy software approvals processes, etc.)
History
Date User Action Args
2010-12-17 22:56:30Jason.Scheirersetrecipients: + Jason.Scheirer, tim.peters, loewis, josiahcarlson, amaury.forgeotdarc, gfe, tim.golden, brian.curtin
2010-12-17 22:56:30Jason.Scheirersetmessageid: <1292626590.62.0.611321018155.issue1449496@psf.upfronthosting.co.za>
2010-12-17 22:56:27Jason.Scheirerlinkissue1449496 messages
2010-12-17 22:56:27Jason.Scheirercreate