2 GB files

[Elbert Lev]

From postings to this group and other resources I understood that the
only way to make Python programs to work correctly with files lager
then 2 GB is building Python interpreter with some "magic spell"
defines. For me this is ABSOLUTELY unacceptable (Not the building, but
distributing and installing on dozens of computers in my
organisation). Then every time we switch to a new release of Python
this has to be repeated over and over!

I believe, that automatic 64 bit support (large files) can and should
be included in standard library (on platforms which support this
feature).

 

[David Pokorny]

From postings to this group and other resources I understood that the
only way to make Python programs to work correctly with files lager
then 2 GB is building Python interpreter with some "magic spell"
defines. For me this is ABSOLUTELY unacceptable (Not the building, but

Elbert: you might get a positive response if you rephrased your post.

"Our corporation needs functionality ___. We would be happy to pay a
contract consultant $n000 to come up with a solution that will work with a
future trajectory of Python releases."

Or you could pray to the OSS gods.

David

 

[David M. Cooke]

Elbert: you might get a positive response if you rephrased your post.

"Our corporation needs functionality ___. We would be happy to pay a
contract consultant $n000 to come up with a solution that will work with a
future trajectory of Python releases."

Or you could pray to the OSS gods.

Or do better research, as it already has it.

My python (from Debian) has large file support, for instance. Python's
configure script will use if it can find it.

The OP doesn't mention what he's using that doesn't have large files
(OS, platform, python version...)

 

[Brad Tilley]

Or do better research, as it already has it.

My python (from Debian) has large file support, for instance. Python's
configure script will use if it can find it.

The OP doesn't mention what he's using that doesn't have large files
(OS, platform, python version...)

Yeah, many older filesystems won't go over 2GB... remeber the 2GB
partition limit in fat?

 

[Elbert Lev]

Elbert: you might get a positive response if you rephrased your post.

"Our corporation needs functionality ___. We would be happy to pay a
contract consultant $n000 to come up with a solution that will work with a
future trajectory of Python releases."


David

David!

I appreciated your sarcasm very much.

I want to assure you that our corporation is perfectly able to hack
code not worse then others can. But reading the postings, which talk
about this issue I thought, that if this feature is "half" supported
and is widely requested, why not to explain why it is needed.

IMHO the most attractive feature of Python is not its syntax, but the
library and the size of distribution. In fact, straight from the box
8-9 MB distribution is sufficient to solve many everyday
programming/administration problems. This is good, but can be
improved. There are some needed pieces missing in standard
distribution and this is one of them. By the way I (almost) do not
care about the speed: it is reasonable right now, can be improved, by
proper data structure/algorithm selection and if one really needs
speed – C is available.

I suggest start discussing additions to the library. This will improve
the package and make it easier to administer.

Or you could pray to the OSS gods.

All is about language acceptance.

In my daily programming activities there are several alternatives to
Python, f.e. Java or .NET with their comprehensive libraries of
classes (much richer then Python's). And what stops me from using it?
The size of the distributive! I understand that adding too much will
result in an increase of the size of distribution, but something has
to be done.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

From postings to this group and other resources I understood that the
only way to make Python programs to work correctly with files lager
then 2 GB is building Python interpreter with some "magic spell"
defines.

Why do you say that? This is not true.

I believe, that automatic 64 bit support (large files) can and should
be included in standard library (on platforms which support this
feature).

And indeed, this is how Python works.

Regards,
Martin

 

[Josef Meile]

From postings to this group and other resources I understood that the
only way to make Python programs to work correctly with files lager
then 2 GB is building Python interpreter with some "magic spell"
defines. For me this is ABSOLUTELY unacceptable (Not the building, but
distributing and installing on dozens of computers in my
organisation). Then every time we switch to a new release of Python
this has to be repeated over and over!

It is necessary with old python versions like 2.1.3 (The one used by
zope 2.6.x). Have you tried to install a newer version of python (ie:
2.3.4)? I think you haven't. It already supports autodetection of large
file support. If it fails, it means that your system doesn't support
large files (ie: on old versions of glibc it wasn't included).

I believe, that automatic 64 bit support (large files) can and should
be included in standard library (on platforms which support this
feature).

It's already there.

 

[Bart Nessux]

David!

I appreciated your sarcasm very much.

I want to assure you that our corporation is perfectly able to hack
code not worse then others can. But reading the postings, which talk
about this issue I thought, that if this feature is "half" supported
and is widely requested, why not to explain why it is needed.

IMHO the most attractive feature of Python is not its syntax, but the
library and the size of distribution. In fact, straight from the box
8-9 MB distribution is sufficient to solve many everyday
programming/administration problems. This is good, but can be
improved. There are some needed pieces missing in standard
distribution and this is one of them. By the way I (almost) do not
care about the speed: it is reasonable right now, can be improved, by
proper data structure/algorithm selection and if one really needs
speed – C is available.

I suggest start discussing additions to the library. This will improve
the package and make it easier to administer.




All is about language acceptance.

In my daily programming activities there are several alternatives to
Python, f.e. Java or .NET with their comprehensive libraries of
classes (much richer then Python's). And what stops me from using it?
The size of the distributive! I understand that adding too much will
result in an increase of the size of distribution, but something has
to be done.

Having never used Java or .NET... how do they compare in size to Python?
I've found that the standard Python download works for me in 95% of the
tasks in Windows (sys admin tasks). But sometimes I need Hammond's win32
extensions, but only rarely. I've also used the pexpect module a lot...
I wish that would be integrated into the main distro, but overall, I'm
very pleased with the balance of bang for the buck...

Oh, I forgot, Python is free. Perhaps the developers are willing to
provide a refund to dissatisfied users

 

[Michael Hudson]

From postings to this group and other resources I understood that the
only way to make Python programs to work correctly with files lager
then 2 GB is building Python interpreter with some "magic spell"
defines. For me this is ABSOLUTELY unacceptable (Not the building, but
distributing and installing on dozens of computers in my
organisation). Then every time we switch to a new release of Python
this has to be repeated over and over!

Did this post drop through a time warp from 2001?

You might want to check your facts more carefully before getting so
angry.

Cheers,
mwh

 

[Paul McGuire]

Oh, I forgot, Python is free. Perhaps the developers are willing to
provide a refund to dissatisfied users

Just like Microsoft - return the unused portion of the software, and we'll
return the unused portion of your money!

-- Paul

 

[Elbert Lev]

Having never used Java or .NET... how do they compare in size to Python?
I've found that the standard Python download works for me in 95% of the
tasks in Windows (sys admin tasks).

Java and .NET are also free.

Java run-time and development are free.
..NET run-time is free.
Java has a little bit better off-the-box library, then .NET, but is
much harder to use in nonsuppervised fashion (CLASSPATH junk).

Sizes: Java development 130MB, .NET development 110MB + 2GB+ for MSDN
and VS (very good). Runtime: Java 32MB and up with options, .NET 18MB.
These libraries are more universal (but lower level) then Python's.

But sometimes I need Hammond's win32
extensions, but only rarely. I've also used the pexpect module a lot...
I wish that would be integrated into the main distro, but overall, I'm
very pleased with the balance of bang for the buck...

For windows I consider this a part of standard distribution. Additions
you are using depend on what you are douing most.

Oh, I forgot, Python is free. Perhaps the developers are willing to
provide a refund to dissatisfied users

They do not

 

[=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=]

Java and .NET are also free.

Java run-time and development are free.
.NET run-time is free.

While this is OT for the original thread, I can't really let this stand.
It is true that Java and .NET are free of charge (although only for some
uses), they are, unlike Python, not free software. You don't get the
source code for them, and you are not allowed to modify it, and to
redistribute it. See

http://www.fsf.org/philosophy/free-sw.html

Regards,
Martin