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]

Re: 2 GB files


"Elbert Lev" <elbertlev@hotm ail.com> wrote in message
news:9418be08.0 408221427.182a4 d30@posting.goo gle.com...[color=blue]
> 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[/color]

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]

Re: 2 GB files

At some point, "David Pokorny" <davebrok@soda. csua.berkeley.e du> wrote:
[color=blue]
> "Elbert Lev" <elbertlev@hotm ail.com> wrote in message
> news:9418be08.0 408221427.182a4 d30@posting.goo gle.com...[color=green]
>> 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[/color]
>
> 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.[/color]

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

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)phy sics(dot)mcmast er(dot)ca

[Brad Tilley]

Re: 2 GB files

David M. Cooke wrote:[color=blue]
> At some point, "David Pokorny" <davebrok@soda. csua.berkeley.e du> wrote:
>
>[color=green]
>>"Elbert Lev" <elbertlev@hotm ail.com> wrote in message
>>news:9418be08 .0408221427.182 a4d30@posting.g oogle.com...
>>[color=darkred]
>>>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[/color]
>>
>>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.[/color]
>
>
> 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...)[/color]

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

[Elbert Lev]

Re: 2 GB files

> Elbert: you might get a positive response if you rephrased your post.[color=blue]
>
> "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[/color]

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.
[color=blue]
> Or you could pray to the OSS gods.[/color]

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.

[Martin v. Löwis]

Re: 2 GB files

Elbert Lev wrote:[color=blue]
> 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.[/color]

Why do you say that? This is not true.
[color=blue]
> I believe, that automatic 64 bit support (large files) can and should
> be included in standard library (on platforms which support this
> feature).[/color]

And indeed, this is how Python works.

Regards,
Martin

[Josef Meile]

Re: 2 GB files

Elbert Lev wrote:[color=blue]
> 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![/color]
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).
[color=blue]
>
> I believe, that automatic 64 bit support (large files) can and should
> be included in standard library (on platforms which support this
> feature).[/color]
It's already there.

[Bart Nessux]

Re: 2 GB files

Elbert Lev wrote:[color=blue][color=green]
>>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[/color]
>
>
> 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.
>
>[color=green]
>>Or you could pray to the OSS gods.[/color]
>
>
> 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.[/color]

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

[Paul McGuire]

Re: 2 GB files

"Bart Nessux" <bart_nessux@ho tmail.com> wrote in message
news:cgcv5v$sjq $1@solaris.cc.v t.edu...
<snip>[color=blue]
> Oh, I forgot, Python is free. Perhaps the developers are willing to
> provide a refund to dissatisfied users ;)[/color]

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

-- Paul

[Michael Hudson]

Re: 2 GB files

elbertlev@hotma il.com (Elbert Lev) writes:
[color=blue]
> 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![/color]

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

--
Java sucks. [...] Java on TV set top boxes will suck so hard it
might well inhale people from off their sofa until their heads
get wedged in the card slots. --- Jon Rabone, ucam.chat

[Elbert Lev]

Re: 2 GB files

Bart Nessux <bart_nessux@ho tmail.com> wrote in message news:<cgcv5v$sj q$1@solaris.cc. vt.edu>...
[color=blue][color=green]
> > I suggest start discussing additions to the library. This will improve
> > the package and make it easier to administer.
> >
> > 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.[/color]
>
> 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).
>[/color]

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.

[color=blue]
> 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...[/color]

For windows I consider this a part of standard distribution. Additions
you are using depend on what you are douing most.
[color=blue]
> Oh, I forgot, Python is free. Perhaps the developers are willing to
> provide a refund to dissatisfied users ;)[/color]

They do not :(

[Martin v. Löwis]

Re: Free software (Was: 2 GB files)

Elbert Lev wrote:[color=blue]
> Java and .NET are also free.
>
> Java run-time and development are free.
> .NET run-time is free.[/color]

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