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
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
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
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 noticed
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 wrong
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 is
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
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
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
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.
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.
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
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
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 perhaps
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 changes
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
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
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
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
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?
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
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
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
23 matches
Mail list logo
