The issues related to PEP 3108 now total 14. With the beta
(supposedly) in a week, I am hoping the last minor details can be
pulled together or decisions made on what can be postponed and what
should definitely be considered a release blocker.
Issue 2847 - the aifc module still imports the cl modu
On 28-May-08, at 5:44 PM, Greg Ewing wrote:
Mike Klaas wrote:
In my perfect world, strings would be indicable and sliceable, but
not iterable.
An object that was indexable but not iterable would
be a very strange thing. If it has __len__ and __getitem__,
there's nothing to stop you iterat
Mike Klaas wrote:
In my perfect world, strings would be indicable and sliceable, but not
iterable.
An object that was indexable but not iterable would
be a very strange thing. If it has __len__ and __getitem__,
there's nothing to stop you iterating over it by hand
anyway, so disallowing __ite
Bill Janssen wrote:
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from the Sequence, as
a marker, so that those of us who want to ask "isinstance(o, String)"
can do so.
Doesn't isinstance(x, basestring) already cover that?
Paul Moore wrote:
I'd rather see a solution which addressed the
wider visitor use case (I think I just sprained my back bending over
backwards to avoid mentioning generic functions :-))
Speaking of generic functions, while thinking about the
recent discussion on proxy objects, it occurred to me
On 28-May-08, at 2:33 PM, Bill Janssen wrote:
From what's been discussed so far, I don't see any advantage
of isinstance(o, String) over hasattr(o, 'encode') or somesuch.
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from
> >>> 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 for substring containment
> >>
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 for substring containment
- splitting on a substring into a list o
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
>
> How can it be that we allow major C API chang
On Wed, May 28, 2008 at 10:08 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I'm beginning to wonder whether I'm the only one who cares about
>> the Python 2.x branch not getting cluttered up with artifacts caused
>> by a broken forward merge strategy.
>
> I share your concern. Seems to me that pe
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to back-port from 3.x, and the concern ab
Georg kindly published the PEP I submitted last night to the PEP site:
http://www.python.org/dev/peps/pep-0371/
This PEP includes some of the previous discussion on the processing
module's inclusion, and I hope clears up/clarifies some of the
goals/non goals and issues. I also included benchmark
On Wed, May 28, 2008 at 6:57 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> It was most likely an oversight on my part. I've now removed the classes
> from the 3000 module.
Nice! =) If you're up to fixing the docs, could you, please, also review the
fresh issue about this module.
http://bugs.pyt
techtonik schrieb:
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. Class
M.-A. Lemburg wrote:
You are probably talking about the great renaming between 1.4 and 1.5.
That was different, since it changes almost all C APIs in Python.
And it used the standard practice... from rename2.h in Python 1.5:
/* This file contains a bunch of #defines that make it possible to use
On 2008-05-28 14:02, Christian Heimes wrote:
M.-A. Lemburg schrieb:
I have a feeling that we should be looking for better merge
tools, rather than implement code changes that cause more trouble
than do good, just because our existing tools aren't smart
enough.
We don't have better tools at our
On 2008-05-28 14:29, Paul Moore wrote:
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I care, but I struggle to und
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I care, but I struggle to understand the implications and/or what
On 27/05/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Conceptually, this is a fine idea, but three things bug me.
>
> First, there is a mismatch between the significance of the problem
> being addressed versus the weight of the solution.
Agreed, absolutely.
> Second, this seems like the w
M.-A. Lemburg schrieb:
> I have a feeling that we should be looking for better merge
> tools, rather than implement code changes that cause more trouble
> than do good, just because our existing tools aren't smart
> enough.
We don't have better tools at our hands. I don't think we'll get any
tools
Stefan Behnel schrieb:
> Straight forward patch is attached (against 3.0a5). Works for me in Cython. I
> thought about a name like "Taint(t)" or "ClearTypeCache(t)", but then went
> with the coward solution of calling the function PyType_Modified() as it was
> (almost) named internally.
>
> BTW, I
Stefan Behnel wrote:
> Straight forward patch is attached (against 3.0a5).
[...]
> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
> times.
Filed on the bug tracker as issues 2989 and 2990.
http://bugs.python.org/issue2989
http://bugs.python.org/issue2990
Stefan
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.
To flesh out the span of your "something like", recently I had a WSGI-based app
that to some request mistakenly r
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
How can it be that we allow major C API changes such as the renaming
of the PyString APIs to go into the trunk without discussi
Greg Ewing wrote:
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.
Yep - and I really think it would need to do this. T
25 matches
Mail list logo
