On Mon, May 26, 2008 at 11:59 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> * The 2.6-backported Mapping ABC has the 3.0 dict API,
>> that is, it uses keys() that returns a view etc.
>
> Curious to hear what Guido thinks about this one.
> A nice use of the Mapping ABC is to be able to
> get
On Mon, May 26, 2008 at 4:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> Deque's do not support count(), insert() or __iadd__().
>>> They should not be registered.
>
>> If it doesn't implement the MutableSequence protocol it still is a Sized
>> container. However currently it's not regist
I'm fine with giving it a public interface. Please submit a patch with
docs included.
On Tue, May 27, 2008 at 9:47 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> [reposting this to python-dev, as it affects both 2.6 and 3.0]
>
> Hi,
>
> when we build extension classes in Cython, we have to first b
* The 2.6-backported Mapping ABC has the 3.0 dict API,
that is, it uses keys() that returns a view etc.
Curious to hear what Guido thinks about this one.
A nice use of the Mapping ABC is to be able to
get 3.0 behaviors. I thought that was the whole
point of all these backports. If the ABC get
Antoine Pitrou schrieb:
> In order to avoid memory consumption issues there could be a centralized cache
> as for regular expressions. It makes it easier to handle eviction based on
> various parameters, and it saves a few bytes for string objects which are
> never
> used as a formatting template.
Christian Heimes wrote:
Antoine Pitrou schrieb:
In order to avoid memory consumption issues there could be a centralized cache
as for regular expressions. It makes it easier to handle eviction based on
various parameters, and it saves a few bytes for string objects which are never
used as a form
On Tue, May 27, 2008 at 10:44 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
* The 2.6-backported Mapping ABC has the 3.0 dict API,
that is, it uses keys() that returns a view etc.
>>>
>>> Curious to hear what Guido thinks about this one.
>>> A nice use of the Mapping ABC is to be able
If you want to use the 3.0 mixins in 2.6, perhaps an alternate set of
APIs could be imported from the future? E.g. from future_collections
import Mapping. IIRC a similar mechanism was proposed for some
built-in functions, even though I see no traces of an implementation
yet.
Any know what happen
Hi,
Guido van Rossum python.org> writes:
> There's no need to register as Sized -- the Sized ABC recognizes
> classes that define __len__ automatically. The Container class does
> the same looking for __contains__. Since the deque class doesn't
> implement __contains__, it is not considered a Co
Hi,
Strings are currently iterable and it was stated multiple times that this is a
good idea and shouldn't change. While I still don't think that that's a good
idea I would like to propose a solution for the problem many people are
experiencing by introducing an abstract base class for strings.
On Tue, May 27, 2008 at 12:16 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Guido van Rossum python.org> writes:
>
>> There's no need to register as Sized -- the Sized ABC recognizes
>> classes that define __len__ automatically. The Container class does
>> the same looking for __contains
[+python-3000]
On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Strings are currently iterable and it was stated multiple times that this is a
> good idea and shouldn't change. While I still don't think that that's a good
> idea I would like to propose a solution for
On Tue, May 27, 2008 at 3:42 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [+python-3000]
>
> On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
> <[EMAIL PROTECTED]> wrote:
>> Basically *the* problematic situation with iterable strings is something like
>> a `flatten` function that flattens out
(just my 2 eurocents)
Guido van Rossum python.org> writes:
>
> I'm not against this, but so far I've not been able to come up with a
> good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a string are:
- testing
Antoine Pitrou schrieb:
(just my 2 eurocents)
Guido van Rossum python.org> writes:
I'm not against this, but so far I've not been able to come up with a
good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
I meant semantically primitive. I thi
Hi,
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
It surely is, but it would proba
Antoine Pitrou schrieb:
Georg Brandl gmx.net> writes:
I'd argue that "find" is more primitive than "split" -- split is intuitively
implemented using find and slicing, but implementing find using split and
len is unintuitive. (Of course, "index" can be used instead of "find".)
I meant semanti
Georg Brandl gmx.net> writes:
>
> It does, but I don't see how it contradicts my proposition. find() takes a
> substring as well.
Well, I'm not sure what your proposal was :-)
Did you mean to keep split() out of the String interface, or to provide a
default implementation of it based on find() a
Antoine Pitrou schrieb:
Georg Brandl gmx.net> writes:
It does, but I don't see how it contradicts my proposition. find() takes a
substring as well.
Well, I'm not sure what your proposal was :-)
Did you mean to keep split() out of the String interface, or to provide a
default implementation o
Georg Brandl gmx.net> writes:
> You wrote:
>
> > If we stay minimalistic we could consider that the three basic
operations that
> > define a string are:
> > - testing for substring containment
> > - splitting on a substring into a list of substrings
> > - slicing in order to extract a substr
[Armin Ronacher]
Basically *the* problematic situation with iterable strings is something like
a `flatten` function that flattens out every iterable object except of strings.
Stated more generally: The problematic situation is that flatten()
implementations typically need some way to decide wh
On 5/27/08, Benji York wrote:
> Guido van Rossum wrote:
> > Armin Ronacher wrote:
> >> Basically *the* problematic situation with iterable strings is something
> >> like
> >> a `flatten` function that flattens out every iterable object except of
> strings.
> > I'm not against this, but so far
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An object cannot know in general
w
"Armin Ronacher" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Basically *the* problematic situation with iterable strings is something
like
| a `flatten` function that flattens out every iterable object except of
strings.
In most real cases I can imagine, this is way too broad
(If you receive this twice, please excuse the duplicate email.
User-error on my part, sorry.)
On Wed, 28 May 2008 08:23:38 am Raymond Hettinger wrote:
> A flatten() implementation doesn't really care about whether
> an input is a string which supports all the string-like methods
> such as capita
Steven D'Aprano" <[EMAIL PROTECTED]>
If built-in objects grew an __atomic__ attribute, you could
simplify the atomic() function greatly:
I may not have been clear enough in my previous post.
Atomicity is not an intrinsic property of an object or class.
How could you know in advance what various
Armin Ronacher wrote:
I'm currently not
providing any __r*__ methods as I was too lazy to test on each call if the
method that is proxied is providing an __rsomething__ or not, and if not come up
with an ad-hoc implementation by calling __something__ and reversing the
arguments passed.
I don't
Nick Coghlan wrote:
else:
# Returned a different object, make a new proxy
result = type(self)(result)
You might want to check that the result has the
same type as the proxied object before doing that.
--
Greg
___
Python-Dev maili
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Just throwing a suggestion out there...
def atomic(obj, _atomic=(basestring,)):
try:
return bool(obj.__atomic__)
except AttributeError:
if isinstance(obj, _atomic):
return True
Hi,
Guido van Rossum wrote:
> On Tue, May 27, 2008 at 9:47 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Could this function get a public interface? I do not think Cython is the only
>> case where C code wants to modify a type after its creation, and copying the
>> code over seems like a hack to
I've noticed that some classes in Cookies module (namely SerialCookie and
SmartCookie) deprecated since 2.3 still present in Python3000 documentation.
http://docs.python.org/dev/3.0/library/http.cookies.html
Is it because ... ?:
1. Docs are not synchronized with API
2. Classes are not removed yet
32 matches
Mail list logo
