[Python-Dev] zipimport to read from a file object instead of just a path?

2012-05-15 Thread Shy Shalom 
In zipimport.c, function get_data(), the zip file is opened using fopen()
and read with CLib functions.
Did anyone ever consider making it possible to read the zipped data from a
generic file object and not just using a string path?
Using StringIO, This would allow a higher degree of python embedding in an
application.
I would be able to have a zip file in memory and make python read modules
from it.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

2012-05-15 Thread Zbigniew Jędrzejewski-Szmek 
On 05/02/2012 02:24 AM, Ben Finney wrote:
> Georg Brandl  writes:
> 
>> list of possible features for 3.3 as specified by PEP 398:
>>
>> Candidate PEPs:
> […]
> 
>> * PEP 3143: Standard daemon process library

I think that http://0pointer.de/public/systemd-man/daemon.html would a
good addition to the 'see also' section. It contains a detailed listing
of steps to be taked during daemonization.

Zbyszek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Accepting PEP 3144 (the ipaddress library)

2012-05-15 Thread Nick Coghlan 
Based on the current version of PEP 3144 and its reference
implementation, I am formally accepting ipaddress into the standard
library.

I believe Peter has satisfactorily resolved the concerns previously
raised with the proposed API, and if I missed anything... well, that's
why we have alpha releases and the new provisional API status :)

There's one point that could do with better documentation, which is
the meaning of a "non-strict" Network address. In ipaddr.py,
non-strict networks filled the role now filled by the separate
Interface objects in the ipaddress module. In ipaddress, the "strict"
flag instead just selects between raising a ValueError when passed a
host address (the default) or simply coercing the host address to the
appropriate network address. That behaviour strikes me as both
reasonable and useful - the coercion aspect just needs to be mentioned
in the documentation.

The integration of the module into 3.3. will be tracked in
http://bugs.python.org/issue14814

Peter will also need to be granted commit access in order to maintain
the module.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zipimport to read from a file object instead of just a path?

2012-05-15 Thread martin 


Zitat von Shy Shalom :


In zipimport.c, function get_data(), the zip file is opened using fopen()
and read with CLib functions.
Did anyone ever consider making it possible to read the zipped data from a
generic file object and not just using a string path?


It's already possible - just write another importer. For the builtin
zipimport, this is not an option, since it seeds itself from the sys.path
entry, which will be a file name. See PEP 302.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-15 Thread Eric Snow 
At this point I'm pretty comfortable with where PEP 421 is at.  Before
asking for pronouncement, I'd like to know if anyone has any
outstanding concerns that should be addressed first.

The only (relatively) substantial point of debate has been the type
for sys.implementation.  The PEP now limits the specification of the
type to the minimum (Big-Endian vs. Little...er...attribute-access vs
mapping).  If anyone objects to the decision there to go with
attribute-access, please make your case.

>From my point of the view either one would be fine for what we need
and attribute-access is more representative of the fixed namespace.
Unless there is a really good reason to use a mapping, I'd like to
stick with that.

Thanks!

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 3144 (the ipaddress library)

2012-05-15 Thread Guido van Rossum 
Congrats Nick and Peter!

On Tue, May 15, 2012 at 5:13 AM, Nick Coghlan  wrote:
> Based on the current version of PEP 3144 and its reference
> implementation, I am formally accepting ipaddress into the standard
> library.
>
> I believe Peter has satisfactorily resolved the concerns previously
> raised with the proposed API, and if I missed anything... well, that's
> why we have alpha releases and the new provisional API status :)
>
> There's one point that could do with better documentation, which is
> the meaning of a "non-strict" Network address. In ipaddr.py,
> non-strict networks filled the role now filled by the separate
> Interface objects in the ipaddress module. In ipaddress, the "strict"
> flag instead just selects between raising a ValueError when passed a
> host address (the default) or simply coercing the host address to the
> appropriate network address. That behaviour strikes me as both
> reasonable and useful - the coercion aspect just needs to be mentioned
> in the documentation.
>
> The integration of the module into 3.3. will be tracked in
> http://bugs.python.org/issue14814
>
> Peter will also need to be granted commit access in order to maintain
> the module.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zipimport to read from a file object instead of just a path?

2012-05-15 Thread Shy Shalom 
> 
> It's already possible - just write another importer. For the builtin
> zipimport, this is not an option, since it seeds itself from the sys.path
> entry, which will be a file name. See PEP 302.
> 
> Regards,
> Martin
> 
> 


Maybe it can be seeded by both a string path *or* a file object, the same way
zipfile.ZipFile does.
This way I'll be able to somehow override or re-initialize zipimport with my own
StringIO

- Shy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-15 Thread Barry Warsaw 
On May 15, 2012, at 10:26 AM, Eric Snow wrote:

>At this point I'm pretty comfortable with where PEP 421 is at.  Before
>asking for pronouncement, I'd like to know if anyone has any
>outstanding concerns that should be addressed first.

It looks great to me.  If I were the PEP czar , I'd approve it.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] dir() in inspect.py ?

2012-05-15 Thread Christian Tismer 

Hi,

by chance I looked into the impl of inspect.getmembers today and was
slightly shocked:

def getmembers(object, predicate=None):
"""Return all members of an object as (name, value) pairs sorted by 
name.

Optionally, only return members that satisfy a given predicate."""
results = []
for key in dir(object):

According to

http://docs.python.org/library/functions.html

"""
Note Because dir() is supplied primarily as a convenience for use at an 
interactive prompt, it tries to supply an interesting set of names more 
than it tries to supply a rigorously or consistently defined set of 
names, and its detailed behavior may change across releases. For 
example, metaclass attributes are not in the result list when the 
argument is a class.

"""

This is a bit inconsistent, and I think the standard lib should be the
best example for clean code that is consistent with the docs.

Is the usage of dir() correct in this context or is the doc right?
It would be nice to add a sentence of clarification if the use of
dir() is in fact the correct way to implement inspect.

cheers - chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com