Re: [Python-Dev] teaching the new urllib
On Tue, Feb 03, 2009 at 06:50:44PM -0500, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > The encoding information *is* available in the response headers, e.g.: > > - -- %< - > $ wget -S --spider http://knuth.luther.edu/test.html > - --18:46:24-- http://knuth.luther.edu/test.html >=> `test.html' > Resolving knuth.luther.edu... 192.203.196.71 > Connecting to knuth.luther.edu|192.203.196.71|:80... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > Date: Tue, 03 Feb 2009 23:46:28 GMT > Server: Apache/2.0.50 (Linux/SUSE) > Last-Modified: Mon, 17 Sep 2007 23:35:49 GMT > ETag: "2fcd8-1d8-43b2bf40" > Accept-Ranges: bytes > Content-Length: 472 > Keep-Alive: timeout=15, max=100 > Connection: Keep-Alive > Content-Type: text/html; charset=ISO-8859-1 > Length: 472 [text/html] > 200 OK > - -- %< - > > So, the OP's use case *could* be satisfied, assuming that the Py3K > version of urllib sprouted a means of leveraging that header. In this > sense, fetching the resource over HTTP is *better* than loading it from > a file: information about the character set is explicit, and highly > likely to be correct, at least for any resource people expect to render > cleanly in a browser. First of all, as it was noted, Content-Type may have no charset parameter, or be omitted at all. But the most important and the worst is that charset in Content-Type may have no relation to charset in document. And even worse - charset specified in document may have no relation to charset used to encode the document. :( Remember, that headers are supplied by HTTP server and it have to read document from just a file, so there is no difference, since there is no magic in being a HTTP server. Ofcourse it will be correct to provide web-server with some hints about charset of byte-encoded text documents, but web-server will not stop working without charset specified or with incorrect charset. This use case is really important for those international segments of Internet, which have two or more conflicting character sets for their (single) alphabet. As an example - every Russian Internet user can tell you that a browser, that have no menu option to select explicitly what encoding to use for current document, is completely unusable. -- Alexey Shpagin ___ 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] C API for appending to arrays
Mike Klaas wrote:
Do you need to append, or are you just looking to create/manipulate an
array with a bunch of c-float values?
Mostly real-life examples I've seen of this were creating an array from
C values obtained from an external source, such as an on-disk file, or
another process. The code example was a (simplified and de-C++-ized)
snippet of actual code.
I find As{Write/Read}Buffer sufficient for most of these tasks.
They improve things, as shown in the second example, but they're still
cumbersome to use for appending/initialization of the array.
(Note that you can
get the size of the resulting c array more easily than you are by
using PyObject_Length).
Note that AsWriteBuffer always gives you the buffer size anyway -- you
can't pass bufsize==NULL. Since I have to call AsWriteBuffer in each
iteration (because I don't know when the buffer will resize), calling
PyObject_Length in addition to that doesn't buy much, if anything.
> I've included some example pyrex code that populates a new
> array.array at c speed.
[...]
cdef int NA
NA = len(W1)
W0 = array('d', [colTotal]) * NA
The thing is, when reading values from a file or a general iterator, you
typically don't know the number of values in advance. If I did, I would
probably use an approach similar to yours.
Thanks for the code -- even if it doesn't help in this case, I
appreciate it as an instructing example of the advanced usage of Pyrex.
___
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] Missing operator.call
Is there a reason why the operator module doesn't have an operator.call function? It would seem logical to be able to write: map(operator.call, lst) which calls each object in lst, just like map(operator.neg, lst) negates every object. Of course, operator.call is equivalent to lambda x: x(), but such an equivalence exists for all functions in the operator module. __call__ should also be provided for symmetry with other operators that correspond to special-name methods. If there is interest in this and no reason why it shouldn't be done, I can write up an issue in the tracker and provide a patch. ___ 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] Missing operator.call
Hrvoje Niksic wrote: > Is there a reason why the operator module doesn't have an operator.call > function? My guess is that it was left out because it would have been redundant given the existence of apply() in 2.x. That argument no longer holds in 3.x of course, so operator.call may be a reasonable addition to 3.1 (and then to 2.7 for forward compatibility reasons). I'm somewhere between -0 and +0 though (-0 due to the lack of concrete use cases, +0 because the improved consistency is appealing) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Missing operator.call
Andrew Bennetts wrote: A patch to add operator.caller(*args, **kwargs) may be a good idea. Your example would then be: map(operator.caller(), lst) Regarding the name, note that I proposed operator.call (and operator.__call__) because it corresponds to the __call__ special method, which is analogous to how operator.neg corresponds to __neg__, operator.add to __add__, etc. The term "caller" implies creation of a new object that carries additional state, such as method name in operator.methodcaller, item in operator.itemgetter, or attr in operator.attrgetter. ___ 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] Missing operator.call
Nick Coghlan wrote: I'm somewhere between -0 and +0 though (-0 due to the lack of concrete use cases, +0 because the improved consistency is appealing) The operator module is one of the rare cases in python where consistency is valued more than concrete use cases. But, for what it's worth, I really wished to use operator.call in my code, expected to find operator.call, and was quite surprised to find it missing. ___ 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] Missing operator.call
Hrvoje Niksic wrote:
> Is there a reason why the operator module doesn't have an operator.call
> function?
Python 2.6 adds operator.methodcaller. So you could use
operator.methodcaller('__call__'), but that's not really any better than
lambda x: x().
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then be:
map(operator.caller(), lst)
That reads ok to me. I think this reads better though:
[callable() for callable in lst]
-Andrew.
___
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] [patch] Duplicate sections detection in ConfigParser
On Tuesday 03 February 2009, Raghuram Devarakonda wrote: > http://bugs.python.org/issue2204 refers to the same issue. Perhaps, > you can upload your patch there in addition to adding any comments. I attached the patch to the ticket. Do you have recommendations on how to solve the uniformity issue with the builder interface? -- Yannick Gingras http://ygingras.net signature.asc Description: This is a digitally signed message part. ___ 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] Missing operator.call
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic wrote: > Andrew Bennetts wrote: >> >> A patch to add operator.caller(*args, **kwargs) may be a good idea. Your >> example would then be: >> >>map(operator.caller(), lst) > > Regarding the name, note that I proposed operator.call (and > operator.__call__) because it corresponds to the __call__ special method, > which is analogous to how operator.neg corresponds to __neg__, operator.add > to __add__, etc. The term "caller" implies creation of a new object that > carries additional state, such as method name in operator.methodcaller, item > in operator.itemgetter, or attr in operator.attrgetter. Part of the problem is the term 'call' is an overloaded term. Do you really mean only objects that define __call__? What about objects that define __init__ and thus can be called as well? If you mean the former than you have to make sure the docs are very clear about this; there is a reason we got rid of callable(). If you mean the latter then there is little benefit to the function since ``[x() for x in lst]`` gets you the same result as your map call. -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] Missing operator.call
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote: > On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic wrote: >> Andrew Bennetts wrote: >>> >>> A patch to add operator.caller(*args, **kwargs) may be a good idea. Your >>> example would then be: >>> >>>map(operator.caller(), lst) >> >> Regarding the name, note that I proposed operator.call (and >> operator.__call__) because it corresponds to the __call__ special method, >> which is analogous to how operator.neg corresponds to __neg__, operator.add >> to __add__, etc. The term "caller" implies creation of a new object that >> carries additional state, such as method name in operator.methodcaller, item >> in operator.itemgetter, or attr in operator.attrgetter. > > Part of the problem is the term 'call' is an overloaded term. Do you > really mean only objects that define __call__? What about objects that > define __init__ and thus can be called as well? If you mean the former > than you have to make sure the docs are very clear about this; there > is a reason we got rid of callable(). If you mean the latter then > there is little benefit to the function since ``[x() for x in lst]`` > gets you the same result as your map call. Not sure I follow you here. It's not the __init__ that allows you to do ``x()``, it's the fact that the class declares a __call__, right? >>> class C(object): ... pass ... >>> C.__call__() <__main__.C object at 0x01A3C370> >>> C() <__main__.C object at 0x02622EB0> >>> str.__call__() '' >>> str() '' That said, I'm also unconvinced of the utility of operator.call over the equivalent list comprehension. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Missing operator.call
On Wed, Feb 4, 2009 at 10:43, Steven Bethard wrote: > On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote: >> On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic wrote: >>> Andrew Bennetts wrote: A patch to add operator.caller(*args, **kwargs) may be a good idea. Your example would then be: map(operator.caller(), lst) >>> >>> Regarding the name, note that I proposed operator.call (and >>> operator.__call__) because it corresponds to the __call__ special method, >>> which is analogous to how operator.neg corresponds to __neg__, operator.add >>> to __add__, etc. The term "caller" implies creation of a new object that >>> carries additional state, such as method name in operator.methodcaller, item >>> in operator.itemgetter, or attr in operator.attrgetter. >> >> Part of the problem is the term 'call' is an overloaded term. Do you >> really mean only objects that define __call__? What about objects that >> define __init__ and thus can be called as well? If you mean the former >> than you have to make sure the docs are very clear about this; there >> is a reason we got rid of callable(). If you mean the latter then >> there is little benefit to the function since ``[x() for x in lst]`` >> gets you the same result as your map call. > > Not sure I follow you here. It's not the __init__ that allows you to > do ``x()``, it's the fact that the class declares a __call__, right? > class C(object): > ... pass > ... C.__call__() > <__main__.C object at 0x01A3C370> C() > <__main__.C object at 0x02622EB0> str.__call__() > '' str() > '' > I don't think so:: >>> Foo.__call__ >>> Foo.__call__ = lambda: None >>> Foo.__call__ > >>> Foo() <__main__.Foo object at 0xf7f90e8c> -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] Missing operator.call
I believe the omission of call from the operator module is an oversight, perhaps caused by the existence (when the operator module was created) of apply. Since apply has been removed from 3.0, we should add operator.call (with the same signature) back. It should be a straightforward wrapper around one of the PyObject_Call* functions. Also note that using __call__ can lead to all sorts of problems when looking at classes -- all class objects have a __call__ attribute, because their metaclass (type) has one, but should not be confused with a __call__ method defined in the class. A quick illustration: >>> class C(object): ... def __call__(self): print "instance call" ... >>> C() <__main__.C object at 0xf7f9052c> >>> C()() instance call >>> C.__call__() Traceback (most recent call last): File "", line 1, in TypeError: unbound method __call__() must be called with C instance as first argument (got nothing instead) >>> C.__call__(C()) instance call >>> C.__class__.__call__(C) <__main__.C object at 0xf7f9048c> >>> -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Missing operator.call
> If there is interest in this and no reason why it shouldn't be done, I > can write up an issue in the tracker and provide a patch. I think there is a tricky design choice to make wrt. argument passing. IIUC, you don't care much about arguments, so you could probably live with def call(o): return o() Somebody proposed that you pass arguments once, and get an "arguments bound" object, i.e. def call(*args, **kwds): def func(o): return o(*args, **kwds) return func Finally, it seems that Guido is advocating an API where arguments get passed along with the callable, i.e. def call(o, *args, **kwds): return o(*args, **kwds) which would make call a synonym for apply (and would also provide for the first definition as a special case). However, with that API, it isn't so easy anymore to pass the same arguments to all callables (unless it is no arguments that you want to pass). 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] Missing operator.call
On Wed, 4 Feb 2009 10:50:47 -0800, Brett Cannon wrote:
On Wed, Feb 4, 2009 at 10:43, Steven Bethard wrote:
[snip]
Not sure I follow you here. It's not the __init__ that allows you to
do ``x()``, it's the fact that the class declares a __call__, right?
class C(object):
... pass
...
C.__call__()
<__main__.C object at 0x01A3C370>
C()
<__main__.C object at 0x02622EB0>
str.__call__()
''
str()
''
I don't think so::
Foo.__call__
Foo.__call__ = lambda: None
Foo.__call__
>
Foo()
<__main__.Foo object at 0xf7f90e8c>
That's because the __call__ special on an instance is ignored, as many
specials on new-style instances are ignored. If you change the method
where it counts - on type(Foo) in this case - then you see something
different.
>>> class X(type):
... def __call__(self, *a, **kw):
... print 'X.__call__', a, kw
... return super(X, self).__call__(*a, **kw)
...
>>> class Y(object):
... __metaclass__ = X
...
>>> Y.__call__
>
>>> Y()
X.__call__ () {}
<__main__.Y object at 0xb7d0706c>
>>> Y.__call__ = lambda: None
>>> Y.__call__
>
>>> Y()
X.__call__ () {}
<__main__.Y object at 0xb7d0706c>
>>> X.__call__ = lambda: None
>>> Y()
Traceback (most recent call last):
File "", line 1, in
TypeError: () takes no arguments (1 given)
>>>
As far as I know, Steven Bethard's point is correct.
Jean-Paul
___
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] Missing operator.call
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon wrote: > On Wed, Feb 4, 2009 at 10:43, Steven Bethard wrote: >> Not sure I follow you here. It's not the __init__ that allows you to >> do ``x()``, it's the fact that the class declares a __call__, right? >> > class C(object): >> ... pass >> ... > C.__call__() >> <__main__.C object at 0x01A3C370> > C() >> <__main__.C object at 0x02622EB0> > str.__call__() >> '' > str() >> '' >> > > I don't think so:: > Foo.__call__ > Foo.__call__ = lambda: None Foo.__call__ > > Foo() > <__main__.Foo object at 0xf7f90e8c> Take a look at PyObject_Call in abstract.c. Basically, __call__ is always looked up on the type, something like: >>> class C(object): ... def __call__(self): ... return 'instance' ... >>> def func(): ... return 'func' ... >>> type(C).__call__(C) <__main__.C object at 0x0263E250> >>> type(C()).__call__(C()) 'instance' >>> type(func).__call__(func) 'func' Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Missing operator.call
On Wed, Feb 4, 2009 at 11:48 AM, "Martin v. Löwis" wrote: >> If there is interest in this and no reason why it shouldn't be done, I >> can write up an issue in the tracker and provide a patch. > > I think there is a tricky design choice to make wrt. argument passing. > IIUC, you don't care much about arguments, so you could probably live > with > > def call(o): >return o() > > Somebody proposed that you pass arguments once, and get an > "arguments bound" object, i.e. > > def call(*args, **kwds): >def func(o): >return o(*args, **kwds) >return func > > Finally, it seems that Guido is advocating an API where arguments get > passed along with the callable, i.e. > > def call(o, *args, **kwds): >return o(*args, **kwds) > > which would make call a synonym for apply (and would also provide for > the first definition as a special case). However, with that API, it > isn't so easy anymore to pass the same arguments to all callables > (unless it is no arguments that you want to pass). My version is in line with the other operators in the operator module. The version that binds the arguments and returns a callable is already available as functools.partial. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
