Re: [Python-Dev] csv changed from python 2.4 to 2.5
Christian K <[EMAIL PROTECTED]> wrote:
> I could not find documentation of the following change in python2.5. What is
> the
> reason for that?
>
> Python 2.4.4 (#2, Apr 12 2007, 21:03:11)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import csv
> >>> d=csv.get_dialect('excel')
> >>> d.delimiter = ','
> >>>
>
> [EMAIL PROTECTED]:/media/hda6/home/ck/prog/peak-o-mat/trunk$ python2.5
> Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import csv
> >>> d=csv.get_dialect('excel')
> >>> d.delimiter = ','
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: readonly attribute
> >>>
Looks like this is the reason - the get_dialect call (which is
implemented in C) is now returning a read only Dialect object rather
than an instance of the original class :-
2.5
>>> import csv
>>> d = csv.get_dialect('excel')
>>> d.__class__
>>>
2.4
>>> import csv
>>> d = csv.get_dialect('excel')
>>> d.__class__
>>>
> Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import csv
> >>> d = csv.excel
> >>> d.delimiter = ','
> >>>
Don't you want to do this anyway?
import csv
class my_dialect(csv.excel):
delimeter = ","
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Return error codes from getaddrinfo.
Dear all,
I'm seeking enlightenment on the error codes returned by the
socket.getaddrinfo() function.
Consider the following on python 2.5 on Windows
>>> import urllib
>>> urllib.urlopen("http://nonexistent";)
[snip traceback]
IOError: [Errno socket error] (11001, 'getaddrinfo failed')
So the error number is 11001.
But when I try to find a symbolic constant in the errno module
corresponding to this error number, I can't find one.
>>> import errno
>>> errno.errorcode[11]
'EAGAIN'
>>> errno.errorcode[11001]
Traceback (most recent call last):
File "", line 1, in
KeyError: 11001
Looking through the C source for the socket module doesn't provide any
clarity (although my C is a little rusty). That module has a special
function, set_gaierror(), for handling error returns from getaddrinfo.
But I can't see if or how the resulting error codes relate to the errno
module.
Is there supposed to be symbolic constants in the errno module
corresponding to getaddrinfo errors?
I want jython to use the same errno symbolic constants as cpython, to
ease portability of code.
Regards,
Alan.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What's going on with the check-in emails?
Hi, It seems there is a problem with check-in emails -- i.e., none have been sent since r56057 (and the svn tree is at r56098 right now). Does someone has a hint what's going on? Thanks, -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's going on with the check-in emails?
Alexandre> It seems there is a problem with check-in emails -- i.e., Alexandre> none have been sent since r56057 (and the svn tree is at Alexandre> r56098 right now). Does someone has a hint what's going on? I'm not aware of a problem, though I noticed the slowdown in checkin emails recently. I forwarded your note to the python.org mailman/postfix gurus. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] csv changed from python 2.4 to 2.5
Christian> I could not find documentation of the following change in
Christian> python2.5. What is the reason for that?
Without looking through the change history for the module it's unclear to me
why that would have changed. The thing that changed is that the get_dialect
call now returns a _csv.Dialect object instead of an instance of the
csv.excel class:
% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>
Please submit a bug report on SourceForge.
Thx,
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return error codes from getaddrinfo.
> Is there supposed to be symbolic constants in the errno module > corresponding to getaddrinfo errors? No. On Windows, there is a separate set of error codes, winerror.h If you google for "winerror 11001", you find quickly that it is "host not found". > I want jython to use the same errno symbolic constants as cpython, to > ease portability of code. That will be very difficult to achieve, as Python is (deliberately) not even consistent across systems. Instead, it reports what the platform reports, so you should do the same in Java. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's going on with the check-in emails?
On 6/27/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > Hi, > > It seems there is a problem with check-in emails -- i.e., none have > been sent since r56057 (and the svn tree is at r56098 right now). > Does someone has a hint what's going on? > I am having issues as well. I just did a slew of PEP checkins and I have not gotten a single email on them. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's going on with the check-in emails?
The mail-checkins script broke because of the upgrade of the machine that hosts the subversion repository -- Python 2.3 went away, but two scripts were still using '#!/usr/bin/env python2.3'. They should be fixed now. On 6/27/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: Hi, It seems there is a problem with check-in emails -- i.e., none have been sent since r56057 (and the svn tree is at r56098 right now). Does someone has a hint what's going on? Thanks, -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] object capability; func_closure; __subclasses__
rehi all,
I have been looking at the object capability + Python discussions for
a while now, and was wondering what the use cases for
``object.__subclasses__`` and ``FunctionType.func_closure`` were?
I don't see __subclasses__ used anywhere in the standard library. And
whilst I can see exposing func_closure as being useful in terms of
"cloning/modifying" an existing function, isn't it possible to do that
without making it introspectable?
Years ago, Ka-Ping Yee pointed out:
http://mail.python.org/pipermail/python-dev/2003-March/034284.html
Derived from this we get:
# capability.py functions
def Namespace(*args, **kwargs):
for arg in args:
kwargs[arg.__name__] = arg
def get(key):
return kwargs.get(key)
return get
class Getter(object):
def __init__(self, getter):
self.getter = getter
def __repr__(self):
return self.getter('__repr__') or object.__repr__(self)
def __getattr__(self, attr):
return self.getter(attr)
# io.py module
def FileReader(name):
file = open(name, 'r')
def __repr__():
return '' % name
def read(bufsize=-1):
return file.read(bufsize)
def close():
return file.close()
return Getter(Namespace(__repr__, read, close))
Now, a process A -- which has full access to all objects -- can do:
>>> motd = FileReader('/etc/motd')
And pass it to "process B" operating in a limited scope, which can then call:
>>> motd.read()
>>> motd.close()
But not:
>>> motd = type(motd)(motd.name, 'w')
which would have been possible *had* motd been created as a ``file``
type by calling: ``open('/etc/motd', 'r')``.
Now, there are probably a million holes in this approach, but as long
as process B's __import__ is sanitised and it operates in a "limited"
scope with regards to references to other functionality, this seems to
be relatively secure.
However, this is where __subclasses__ and func_closure get in the way.
With object.__subclasses__ (as Brett points out), all defined
classes/types are available -- including the ``file`` type we were
trying to deny process B access to! Is it necessary to expose this
attribute publically?
And, likewise with func_closure, one can do
motd.read.func_closure[0].cell_contents and get hold of the original
``file`` object. Is it absolutely necessary to expose func_closure in
this way?
Now, whilst probably wrong, I can see myself being able to create a
minimal object capability system in pure python if those 2 "features"
disappeared. Am I missing something obvious that prevents me from
doing that?
Can we get rid of them for Python 2.6? Or even 2.5.2? Is anyone
besides PJE actually using them? ;p
Thanks in advance for your thoughts.
--
love, tav
founder and ceo, esp metanational llp
plex:espians/tav | [EMAIL PROTECTED] | +44 (0) 7809 569 369
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] csv changed from python 2.4 to 2.5
[EMAIL PROTECTED] wrote:
> Christian> I could not find documentation of the following change in
> Christian> python2.5. What is the reason for that?
>
> Without looking through the change history for the module it's unclear to me
> why that would have changed. The thing that changed is that the get_dialect
> call now returns a _csv.Dialect object instead of an instance of the
> csv.excel class:
>
> % python2.4
> Python 2.4.1 (#3, Jul 28 2005, 22:08:40)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import csv
> >>> d = csv.get_dialect("excel")
> >>> d
>
>
> % python
> Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48)
> [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import csv
> >>> d = csv.get_dialect("excel")
> >>> d
> <_csv.Dialect object at 0x137fac0>
>
> Please submit a bug report on SourceForge.
>
Ok. Done.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] object capability; func_closure; __subclasses__
At 02:04 AM 6/28/2007 +0100, tav wrote: >rehi all, > >I have been looking at the object capability + Python discussions for >a while now, and was wondering what the use cases for >``object.__subclasses__`` and ``FunctionType.func_closure`` were? > >I don't see __subclasses__ used anywhere in the standard library. And >whilst I can see exposing func_closure as being useful in terms of >"cloning/modifying" an existing function, isn't it possible to do that >without making it introspectable? You know, I find it particularly interesting that, as far as I can tell, nobody who proposes making changes to the Python language to add security, ever seems to offer any comparison or contrast of their approaches to Zope's -- which doesn't require any changes to the language. :) >Now, whilst probably wrong, I can see myself being able to create a >minimal object capability system in pure python if those 2 "features" >disappeared. Am I missing something obvious that prevents me from >doing that? Well, you're missing a simpler approach to protecting functions, anyway. The '__call__' attribute of functions is still callable, but doesn't provide any access to func_closure, func_code, etc. I believe this trick also works for bound method objects. I suspect that you could also use ctypes to remove or alter the type.__subclasses__ member, though I suppose you might not consider that to be "pure" Python any more. However, if you use a definition of pure that allows for stdlib modules, then perhaps it works. :) >Can we get rid of them for Python 2.6? Or even 2.5.2? Is anyone >besides PJE actually using them? ;p I wouldn't object (no pun intended) to moving the type.__subclasses__ method to say, the 'new' or 'gc' modules, since you wouldn't want to make those available to restricted code, but then they'd still be available for folks who need/want them. 'gc' has similar capabilities (again no pun intended) anyway. However, ISTM that this should be a 3.0 change rather than a 2.x one, even so. With regard to the func_closure thing, I'd actually like to make it *writable* as well as readable, and I don't mean just to change the contents of the cells. But, since you can use .__call__ to make a capability without access to func_closure, it doesn't seem like you really need to remove func_closure. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
