Because it is easier to write in Python, and (as Greg explained) the
encryption is so lousy that you're unlikely to find heavy use of it.
Therefore nobody (so far) has cared to write an accelerator in C.
On Sun, Aug 23, 2009 at 9:23 PM, Shashank
Singh wrote:
> A litle off topic but the zipfile doc
A litle off topic but the zipfile doc says: "Decryption is extremely slow as
it
is implemented in native python rather than C".
Why is this limitation there? I mean, is there any specific reason for not
implementing
it in C?
On Mon, Aug 24, 2009 at 8:45 AM, Nick Coghlan wrote:
> Guido van Rossu
Mark Hammond wrote:
> On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
>>> If this becomes seen as 'my' cause, I suspect it will run out of steam
>>> very quickly. I truly hope python-dev, as a community, takes some
>>> ownership of this issue
>>
>> That certainly won't happen. python-dev, as a com
Guido van Rossum wrote:
> OMG, the use case is actually running a script without giving the user
> access to the script's source? Agreed that's a big -1.
>
> I thought it was just for running a zip containing code so secret you
> don't want to leave it around on your hard drive without encryption
On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownersh
OMG, the use case is actually running a script without giving the user
access to the script's source? Agreed that's a big -1.
I thought it was just for running a zip containing code so secret you
don't want to leave it around on your hard drive without encryption
(say, the program you use to compu
oops..sorry for the empty mail :P
On Mon, Aug 24, 2009 at 8:09 AM, Shashank Singh <
shashank.sunny.si...@gmail.com> wrote:
>
>
> On Mon, Aug 24, 2009 at 7:39 AM, Nick Coghlan wrote:
>
>> Guido van Rossum wrote:
>> > Anyway it looks like if someone wants to try this, only the code in
>> > runpy.p
On Mon, Aug 24, 2009 at 7:39 AM, Nick Coghlan wrote:
> Guido van Rossum wrote:
> > Anyway it looks like if someone wants to try this, only the code in
> > runpy.py needs to be touched.
>
> The necessary work would actually be in zipimport. runpy doesn't know
> anything about the details of where
Guido van Rossum wrote:
> Anyway it looks like if someone wants to try this, only the code in
> runpy.py needs to be touched.
The necessary work would actually be in zipimport. runpy doesn't know
anything about the details of where the module code comes from, it just
asks the relevant importer for
On Sun, Aug 23, 2009 at 5:59 PM, Gregory P. Smith wrote:
> I doubt you can even classify the zipfile module's "decryption" support as
> encryption. It is trivially stupid, easily cracked (a 32bit crc based
> "cipher"). The zipfile module does not support the various later encryption
> schemes tha
On Sun, Aug 23, 2009 at 2:24 PM, "Martin v. Löwis" wrote:
> >> No doubt this is a useful functionality to have but it would be great to
> >> have some comments on whether
> >> this can be(or even should be) feasibly added as an inbuilt support.
> >
> > MvL already asked for a patch so I suppose th
>> No doubt this is a useful functionality to have but it would be great to
>> have some comments on whether
>> this can be(or even should be) feasibly added as an inbuilt support.
>
> MvL already asked for a patch so I suppose that means he thinks it's
> useful.
I am actual skeptical that it is
> On Aug 23, 2009 2:10 PM, "Guido van Rossum" wrote:
> MvL already asked for a patch so I suppose that means he thinks it's
> useful. Personally I've never encountered an encrypted zipfile, so I
> just have questions: is there a standard encryption algorithm? What is
> encrypted? The entire file o
There is a standard for encrypting entire zip files. And I was looking at
the zip docs the other day and zipfile can already decrypt but not encrypt
(assuming my memory is accurate; doing this from my phone on vacation).
On Aug 23, 2009 2:10 PM, "Guido van Rossum" wrote:
On Sun, Aug 23, 2009 at
On Sun, Aug 23, 2009 at 9:09 AM, Shashank
Singh wrote:
> There is an interesting suggestion (http://bugs.python.org/issue6749).
> to add support to run encrypted zip files as python scripts.
>
> No doubt this is a useful functionality to have but it would be great to
> have some comments on whether
There is an interesting suggestion (http://bugs.python.org/issue6749).
to add support to run encrypted zip files as python scripts.
No doubt this is a useful functionality to have but it would be great to
have some comments on whether
this can be(or even should be) feasibly added as an inbuilt sup
> If this becomes seen as 'my' cause, I suspect it will run out of steam
> very quickly. I truly hope python-dev, as a community, takes some
> ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownership of anything. It's always individuals who t
>>> From my POV, this would be required in some form or another before such
>>> a scheme could actually work. Without it we end up with an improved
>>> win32text (good!)
>>
>> I still think this would be actually bad.
>>
>> Instead, a new extension should be written, with a name that does not
>>
18 matches
Mail list logo
