[Barry Warsaw]
So, we need to come up with a new release schedule for Python 3.0. My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0 rc 2
19-Nov-2008 3.0 rc 3
03-Dec-2008 3.0 final
Given what still needs to be done, is this a reasonable schedule? Do
we need two more betas?
Yes to bot
Given that the *API* is fixed though, it is probably better to have the
module present in 3.0 and bring it back to the main line in 2.7.
If any absolute clangers from a performance/stability point of view get
past Raymond (and everyone else with an interest in this) then they can
be addressed in
[Guido van Rossum]
Well, from the number of release blockers it sounds like another 3.0
beta is the right thing. For 2.6 however I believe we're much closer
to the finish line -- there aren't all those bytes/str issues to clean
up, for example! And apparently the benefit of releasing on schedule
[Barry]
Since rc1 did not go out last night, bsddb could be restored. I still
don't think it should be, but at this point it's up to Guido to
override, and I will abide by his decision.
Put in my vote for restoration, deprecation, and thought-out
removal/replacement in 3.1.
The ensuing dis
[Brett Cannon]
On Wed, Sep 3, 2008 at 7:33 PM, <[EMAIL PROTECTED]> wrote:
All but dbm.dumb require some pre-existing library to exist to compile
against. So any platform that has the proper libraries installed will
be able to use ndbm or gnu, but as for which platforms that are I do
not know.
[Brett]
I gave a talk last night at the Vancouver Python users group on
2.6/3.0, and I tried the following code and it failed during a live
demo::
>>> try: pass
... except Exception, Exception: pass
File "", line 2
except Exception, Exception: pass
^
Sy
[Barry]
I'm not going to release rc1 tonight.
Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-30
Skip> Remind me why we want to get rid of bsddb?
Benjamin> The reasons are enumerated in PEP 3108.
Not much justification and no references to outside discussion for such a
heavily used package which has been part of Python for a long time in one
form or another.
Well said.
Raymond
_
From: "Guido van Rossum" <[EMAIL PROTECTED]>
That said, I would actually be okay with the status quo (which does
raise an OverflowError) as long as we commit to fixing this properly
in 2.7 / 3.1, by removing the range restriction (like we've done for
other int operations a long time ago).
And t
That makes sense to me and there a probably plenty of examples.
However, I worry more about other examples that will fail
and do so it a way that is nearly impossible to find through
code review (because the code IS correct as written).
n = len(log_entries)
if log_entries[n] in handled:
This
From: "Guido van Rossum" <[EMAIL PROTECTED]>
The way I see it is that there are tons of ways I can think of how
raising OverflowError can break unsuspecting programs (e.g. code that
has been tested before but never with a humungous input), whereas
returning a "little white lie" would allow such c
Yea! I'm very happy about this.
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Amaury Forgeot d'Arc" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, July 30, 2008 9:03 PM
Subject: Re: [Python-3000] Is this really a SyntaxError?
Cool.
I hope others can review, and
def grouper(n, iterable, fillvalue=None):
"grouper(3, 'abcdefg', 'x') --> abc def gxx"
args = [iter(iterable)] * n
kwds = dict(fillvalue=fillvalue)
return izip_longest(*args, **kwds)
[GvR]
If you reverse the two parts it will work:
izip_longest(fillvalue=fillvalue, *
With keyword-only parameters allowed now, I think it makes sense to be able
to supply the keywords arguments after the variable length argument as well.
Agreed. I doubt that this will be a simple enough change to allow it
in 3.0 though.
Sure would be nice if it could go in. IMO, the functional
The intended upgrade path is through 2.6.
If you go straight from 2.5, you don't get
to go through a step with the -3 warnings
and optional text/bytes annotations.
IMO, it would be a mistake to create a 2.5 to 3.0 converter.
Raymond
- Original Message -
From: "Robert Brewer" <[EMAIL PR
From: "Brett Cannon" <[EMAIL PROTECTED]>
I appreciate you want to maintain the code, Jesus, but that still
makes you the single point of failure for the code. If you decide you
don't want to deal with it, or are on vacation when the code breaks
just before a release, it is quite possible we are s
From: "nirinA raseliarison" <[EMAIL PROTECTED]>
>>> from test.test_random import gamma
. . .
there is a simple implementation in Python at:
http://en.wikipedia.org/wiki/Lanczos_approximation
with coefficients slightly different from those in
test_random.py, one gets:
. . .
with the gamma from
- Original Message -
From: "Mark Dickinson" <[EMAIL PROTECTED]>
To: "nirinA raseliarison" <[EMAIL PROTECTED]>; "python-3000"
Sent: Tuesday, July 15, 2008 1:27 AM
Subject: Re: [Python-3000] adding gamma and error functions to math module
On Tue, Jul 15, 2008 at 9:10 AM, nirinA rasel
From: "Nick Coghlan" <[EMAIL PROTECTED]>
Georg and I tried doing it that way and had major problems trying to get it to work - the hard part is that the body of the list
comp (which may include nested list comps, lambda functions and generator expressions) needs to be able to see the iteration
v
From: "Guido van Rossum" <[EMAIL PROTECTED]>
The new failure in 3.0 is a side effect of the translation (mostly) of
list comps into genexps. The underlying problem is that the genexp
creates a function scope, and function scopes don't have access to the
surrounding class body scope. (There's a re
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To be sure, IMO the generator expression is wrong in interpreting the
StopIteration exception! It should fail the same way the list
comprehension fails.
When exercising 2-to-3 on Zodb at the EuroPython sprints, we also found another oddity. This cod
From: "Barry Warsaw" <[EMAIL PROTECTED]>
There are two options. I could shift everything forward 2 weeks and
do the next betas on July 16th. Or we could wait until August 6th.
That would mean 6 weeks between betas. It's fine with me either way.
+1 for six weeks to allow the code to be mo
From: "Guido van Rossum" <[EMAIL PROTECTED]>
I haven't had the time to look into this, but it sounds unintuitive to
drop __reduce_ex__ which is supposed to be the "extended" IOW "newer"
version of the API compared to __reduce__ which was deemed to be
missing something.
Right. The version argum
"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
[MAL]
It's being able to write
str.transform('gzip').transform('uu')
which doesn't require knowledge about the modules doing the actual
work behind the scenes.
What is the reverse operation for the above example:
str.untransform('uu').untransform('gzip')?
Why can't we use codecs and st
It's why a want to know how to express the class decorator for making a
comparison
[Georg]
A class decorator works exactly like a function decorator, that is,
@foo
class X: ...
is equivalent to
class X: ...
X = foo(X)
This should be all you need to know in order to write a class decorator.
* UserList/UserString [done: 3.0]
Note that these were updated and moved to the collections module in Py3.0.
anydbm dbm.tools [1]_
whichdbdbm.tools [1]_
Were there any better naming suggestions than dbm.tools? The original names
seem much more informative.
[Barry]
> I'd also like for us to consider doing regular monthly releases.
+1
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archiv
[Skip]
> If s.reverse() is dumped shouldn't s.sort() be as well?
I don't think so. When you run reversed(s), the s argument
can be any Sequence (either mutable or immutable) and the
return value is an iterator that doesn't copy the whole
dataset.
In contrast, sorted() takes any iterable and make
[Steven]
> But .reverse() is in-place, while the other two create new sequences, no?
reversed(s) creates an iterator and s[::-1] creates a new list. They are not
the same as s.reverse() but the use cases overlap quite a bit.
Raymond
___
Python-3000
Would it be worthwhile to leave reversed(s) and s[::-1] as the two obvious ways
to do it (ways that work with any Sequence, not just lists)?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
I've been exercising the new keyword-only arguments syntax. It is absolutely
wonderful. I'm amazed at how many long standing problems it solves elegantly.
Thanks Talin!
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.o
[GvR]
> I think you can probably get something that is reasonable given the
> kind of assumptions that prevail in an ABC world by having a
> "Sortable" metaclass (itself a subclass of ABCMeta) with the implied
> semantics that objects x and y can be sorted if the nearest common
> ancestor of x.__cl
>> I don't think we'll ever get another chance to clean-up the mapping API and
>> to remove duplicate functionality (the code for
>> dict.__copy__ and dict.copy share the same implementation).
>
> I find the use of a copy operation that purports to copy any object
> suspect (regardless whether it
Was the concensus on this to move UserList into the collections module and to
remove UserString?
Any objections?
Raymond
---
>> [Brett]
>> > +1 on collections.
>>
>> [Steven Bethard]
>> > +1 for putting them in the collections module.
>>
>> How
Where did we end-up on dict.copy()?
Is the copy(obj) function sufficiently universal to replace the obj.copy()
method used in sets and in dict imitators? Or does the
need for import preclude it from consideration?
To me it seems that relationship between __copy__ and the copy() function is
ju
[GvR]
> Hold on. We went down that road quite a bit and then discovered it
> wasn't going to work.
I figured that it was missing for a reason.
> The problem is that if you have two instance x,
> y such that isinstance(x, TotalOrdering) and isinstance(y,
> TotalOrdering) you still don't know if x
During the discussion of PEP 3141, what use cases were envisioned for the
Integral type? Were there some examples of concrete implementations other than
or #t and (integer? 8/4) ==> #t but in our current
implementation Rational(8,4) is not Integral like it is for Scheme.
Also, Scheme seems a
>> Was some thought given to providing a mixin for boolean
>> inequalities in total orderings (define __le__ and get
>> the rest for free)
[GvR]
> IOW it's messy.
Would it make sense to do something in numbers.py modeled
after Exact/InExact? Those don't have any behavior; they
just make a sta
Was some thought given to providing a mixin for boolean inequalities in total
orderings (define __le__ and get the rest for free)?
One of the motivating examples in the ABC pep was that the presence of
__getitem__ was insufficient to distinguish between a sequence and a mapping.
By registering
[Martin]
> So indeed, your claim that .copy "is [not]
> really polymorphic" is quite puzzling - we now seem to agree that it
> *is* polymorphic.
Yes, of course. Every method used by dict imitators could be considered
polymophic. I was just observing copy.copy(obj) applies to
many, many more ob
In Py3.0, would it be worth it to simplify this protocol by combining these two
methods? Always pass in a proto argument and the
method can ignore it if it wants.
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mai
>> [Phillip Eby]
>>> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
[Raymond]
>> Can't say dict.copy() is really polymorphic if only one other class defines
>> the method.
[Martin]
> Why do you say it's only one? I found atleast UserDict.copy,
> os._Environ.copy, Wea
[Phillip Eby]
> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
Can't say dict.copy() is really polymorphic if only one other class defines the
method.
The __copy__ method is more common. The only wrinkle is that the copy()
function isn't a builtin.
Raymond
___
[Brett]
> +1 on collections.
[Steven Bethard]
> +1 for putting them in the collections module.
How about UserString?
Is there a reason for it to continue to exist?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mai
In the process of getting UserDict updated to subclass from MutableMapping, it
ended-up in the collections module during the
transistion. Probably, all three should end-up in the same place, either in
the collections module or in their own modules. What
do you guys think? Do you like them in
[Nick]
> does anyone else think a 'key' parameter on any() and all()
> would be useful?
Not really. The key= function is useful whenever you need to
keep the original value around for some reason (i.e. sorting
it or getting the min/max value). But with any() and all()
you don't keep anything.
I'm wondering if collections.Iterable should inherit from
collections.Container"?
In Python, anything that supports __iter__ automatically supports tests using
the "in" operator:
class A:
def __iter__(self):
for i in (1,2,3):
yield i
>>> 2 in A()
True
I recommend dropping the dict.copy() method from Py3.0.
* We can already write: newd = copy.copy(d).
* We can also write: newd = dict(d)
* Both of those approaches also work for most other containers.
* The collections.Mapping ABC does not support copy().
* copy() is not a universal feature o
> I think the Zope/Twisted interfaces have gone here before.
> I believe they have a separate validation call which is
> typically only invoked in unittests.
+1 That seems like a good idea.
Raymond
___
Python-3000 mailing list
Python-3000@python.org
It's interesting that tuples could be registered as Sequences without having
all the requisite methods. Should the register() method to some sort of
validation that all public methods in the ABC are in the class/type being
registered?
Raymond
___
Py
[Fred Drake]
> I'd be happy seeing these methods added to tuple; there's
> no reason that they would only be useful on mutable sequences.
That reminds me, I've always thought Sequence.__contains__().
should always be accompanied by Sequence.index(). Their
use cases are strongly related:
Good n
>> Do you want to drop those methods from the ABC or add them to tuple?
> I'm not sure, but I'm tempted to add them to the ABC.
> What's your hunch?
My hunch is that adding count() and index() to tuple is at
harmless at worst and sometimes helpful at best (I've
occasionally needed them and felt m
The tuple class is registered to the collections.Sequence ABC, but it does not
support count() and index() as required by the ABC.
Do you want to drop those methods from the ABC or add them to tuple?
Raymond
___
Python-3000 mailing list
Python-3000@py
[GvR]
> I expect that, given the general trend that different types are not
> comparable, making an exception for None is more likely a source of
> errors than a source of joy.
That is reasonable.
Raymond
___
Python-3000 mailing list
Python-3000@python
> You should have been there when this was decided about two years ago.
IIRC, the decision was a general one about cross-type
comparisons not being turned-on the default. I do not
recall a specific discussion about None.
Also, the list at the time was flooded with propositions
ranging from the
It was very convenient in Py2.x to have None comparable to other types and
always rank less than any other type.
I would like to restore that ability.
One example, it helps with heaps to be able to turn an entry into None and have
it sift to the top where the null entries can be popped-off.
R
>> However, my support for it has waned anyway. The notation is also
>> used for set comprehension and those should be mutable.
>
> Cool. That saves us a PEP. Vive le status quo.
It just wasn't me to be.
Raymond
___
Python-3000 mailing list
Python-30
[Adam]
> Given that "x in {1,2,3}" can be optimized just as well with mutable
> sets (can somebody think of an example that can't?), do you still
> support immutable using the literal notation?
>From an optimization point of view, it is still best to have {...} as a
>frozenset.
However, my suppo
[GvR]
> Raymond, I think you're overestimating how often the repr() of a set
> actually gets eval()'ed.
The repr is the model for how we enter things by hand.
If the repr is set([1,2,3]), the that's how we will learn
to type them into our programs. It's not the eval(repr(s))
round trip that's at
>>> should the repr for a set be set({a, b, c}) instead of set([a, b, c])?
[Raymond]
>> FWIW, running eval() on the repr is slower and less memory efficient with
>> curly braces than with the square brackets.
[Ron]
> It's all very close. I think the frozenset({1,2,3}) example will get faster
>
> should the repr for a set be set({a, b, c})
> instead of set([a, b, c])?
FWIW, running eval() on the repr is slower and less memory efficient with curly
braces than with the square brackets.
Also, it may be easily misread as meaning: set([frozenset([a, b, c])]). If the
latter is intended, t
[Jim Jewett]
> I thought you tried changing those tuples to frozensets
>(because it was semantically better), and found that it
> didn't actually win for tuples of length 2 or 3.
The sets were faster. The automatic transformation didn't
go in because it changed semantics -- the searched for item
[John Barham]
> But getting back to the original issue, what does using
> frozensets gain you over using a tuple:
>
> if urlext in ('html', 'xml', 'php'):
With sets, the search is O(1).
With tuples, it is O(n).
Sets win on inputs longer than 1.
Raymond
___
> Looking over the code base, frozensets are used rarely.
> So I don't think this is warranted.
There is no shortage for perfect use cases in the form:
if urlext in {'html', 'xml', 'php'}:
. . .
If the curly braces are taken to mean a frozenset,
then the peepholer can code the whol
I think it would be more useful for the {e1, e2, e3} literal to be a frozenset
instead of a set.
In expressions like "x in {'html', 'xml', 'php'}" the compiler could optimize
away the set construction and treat it as a constant.
In cases where we want to build-up mutable sets, we need to start
> Some folks thought it would be cute to be able to
> write incomplete code like this:
>
> class C:
> def meth(self): ...
> ...
>
> and have it be syntactically correct.
Hmm, that *is* cute :-)
Raymond
___
Python-3000 mailing list
Python-3000@pytho
[Raymond Hettinger]
>> I missed the conversation on this one.
>> Was there a use case or a reason to add this?
[Robert Kern]
> It was added for Numeric a long time ago.
The ellipsis syntax has been around for a while.
What is new is the Ellipsis literal in Py3.0.
See snippets
I missed the conversation on this one.
Was there a use case or a reason to add this?
I ask because the spelling has an unfortunate
overlap with the sys.ps2 prompt:
>>> def f(x):
... return x+1
I don't know if this is a problem. Just thought I would bring it up.
Raymond
[Skip]
> if not q.qsize():
>print q.qsize()
> might print something besides 0. And if it is a surprise,
> they should probably not be programming with threads.
> 0.5-even-rounded wink>
I concur. Let's leave qsize() alone. Even renaming it would cause unnecessary
breakage.
FWIW, th
> I'm not sure people who ignore the big "Because of
> multithreading semantics, this is not reliable" warnings
> should be catered to. Since others have contributed use-cases
> for qsize()'s advisory information, it should probably stay around.
I concur.
I do recommend we dump q.empty() and q.
I proposed to remove three methods from the queue module, qsize(), empty(), and
full(). These are not reliable. The RightWay (tm) is to trap the Empty and
Full exceptions or use the .join() approach.
Raymond
--- From the docs ---
Queue.qsize()ΒΆ
Return the approximate size of the queue.
1) The repr module is marked as hardly used, but it may have a fan base (not
me). It is covered in the tutorial's guided tour, so it has been held-up as
being active and useful. There are a few hits on google's codesearch:
http://www.google.com/codesearch?hl=en&q=+lang:python+%22import+repr%22&s
[Aahz]
> I have always thought that "quantize()" makes Decimal
> confusing in the context of the other mechanisms that Python makes
> available for other kinds of numbers.
No doubt, the spec made a number of choices that are obvious only if you work
at IBM. And, there is no doubt, the module has
[Jeffrey Yasskin]
> I always like to have a patch around because abstract discussions,
> even (especially?) on simple topics, have a tendency to run off into
> the weeds. A patch keeps things focused and moving forward.
Please recognize that our little system of patches and newsgroup
discussions i
[Jeffrey Yasskin]
> Given Guido's agreement, expect another version of this patch with
> only __trunc__.
Why is __trunc__ being backported? Is a trunc() builtin being backported?
What is the point for a synonym for int() and __int__ in
Py2.6.
Unless I'm missing something, this doesn't improve
[Jeffrey Yasskin]
>> > I'm not
>> > sure exactly what you're objecting to. Could you be more precise?
>>
>> You note said: "I'll implement Context.round() in a separate patch. Comment
>> away."
>
> Oh, sorry for not being clear then. I don't intend to write or discuss
> that separate patch until
[Raymond]
>> There should probably be a PEP sets clearer guidelines about what should be
>> backported from Py3.0.
>>
>> Perhaps something like this:
>> * If there is a new feature that can be implemented in both and will make
>> both more attractive, then it should be in both.
>> * If something
[Jeffrey Yasskin]
> The other 3 methods
> specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> be needed for 3.0. I'd rather not make the two versions of Decimal
> gratuitously different, so this patch puts them in the 2.6 version
> too.
If I understand you correctly, then the
more harm than good.
Raymond
- Original Message -
From: "Jeffrey Yasskin" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Mark Dickinson" <[EMAIL PROTECTED]>; "Python 3000"
; <[EMAIL PROTECTED]>
Sent
> I think pep 3141's round(x, ndigits) does (1). The only thing it
> doesn't support yet is specifying the rounding mode. Perhaps the pep
> should say that round() passes any extra named arguments on to the
> __round__() method so that users can specify a rounding mode for types
> that support it?
> On Aug 27, 2007, at 6:16 PM, [EMAIL PROTECTED] wrote:
>
>> I would like to see PEP 8 remove the "as necessary to improve
>> readability" in the function and method naming conventions. That
>> way methods like StringIO.getvalue() can be renamed to
>> StringIO.get_value().
Gratuitous breakage --
From: "Kurt B. Kaiser" <[EMAIL PROTECTED]>
> , IMHO eliminating the strict versions of map() and filter() in
> favor of the lazy versions from itertools kicks the degree of
> sophistication necessary to understand these functions up a notch (or
> three).
Not really. Once range() starts returning
>> Having done that, if I want to test whether some index j
>> is within the range of indices for this sequence, it
>> seems natural to write
>>
>>if j in r:
>> ...
>
> Fair enough. So maybe *you* can contribute a patch?
And maybe we can do the same for xrange() in Py2.6
Raymond
_
> PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
> it is in principle no longer necessary (due to the new defaultdict type).
I've forgotten. What was the whole point of Python 3.0?
Is it to make the language fat with lots of ways to do everything?
Guys, this is your ONE ch
From: "Andrew Koenig" <[EMAIL PROTECTED]>
> (I'm feeling slightly pedantic today, so I want to say that the proposal
> doesn't make it any easier to identify modules that engage in I/O -- it
> makes it easier to identify modules that assuredly do not engage in I/O.
u = urllib.urlopen('http://www.p
> Giovanni Bajo wrote:
>> Another workaround could be:
Before focusing mental talents on workarounds and implementations,
it would be worthwhile to consider whether the idea would help or
hurt the language. The and/or keywords already have some complexity
due to their returning non-boolean values
> I wasn't thinking of this from a security POV -- more from the
> perspective of trying to understand roughly what a module does.
> Looking at the imports is often a good place to start.
In the case of open(), this may be a false benefit. Too many other calls
(logging, shelve, etc) can open file
> I haven't used the python.org wiki before. If you point me to the
> right place put a link to a BList page, I'd be happy to create one.
> Somewhere under UsefulModules?
That would be a good place:
http://wiki.python.org/moin/UsefulModules
Raymond
__
> Thanks for taking time to review my code.
You welcome. And thanks for the continuing development effort.
> Did you look through the PEP as well?
Yes.
> In fact, I am half way done with implementing the change so
> that small BLists are memory efficient.
As the code continues to evolve, I'l
al
literal support dropped entirely, I would rather live with the 0123 form than
add more complexity with a non-standard format and a set of warnings for
decimals with leading zeros: date(2007, 05, 09).
> 3128 (BList) -- I'll leave this for Raymond Hettinger to review.
After looki
Those following the octal literal discussion might enjoy reading one of today's
SF bug reports:
www.python.org/sf/1715302
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
[Andrew Koenig]
> It has occurred to me that as Python stands today, an indent always begins
> with a colon. So in principle, we could define anything that looks like an
> indent but doesn't begin with a colon as a continuation. So the idea would
> be that you can continue a statement onto as man
> If it really has to be done this way, I think the whole PEP is doomed.
This thread is getting way ahead of me and starting to self-destruct before
I've had a chance to put together a concrete proposal and scan existing code
for use cases.
Can I please press the button for a few days until I
[Michael Bayer]
> why not encapsulate the "proper" weakref-based approach in an easy-to-
> use method such as "__close__()" ? that way nobody has to guess how
> to follow this pattern.
An encapsulating function should be added to the weakref module
so that Guido's example could be written as:
From: "Greg Ewing" <[EMAIL PROTECTED]>
> It has nothing to do with cyclic GC. The point is that
> if the refcount of a weak reference drops to zero before
> that of the object being weakly referenced, the weak
> reference object itself is deallocated and its callback
> is *not* called. So having th
>Raymond> I find that style hard to maintain. What is the advantage over
>Raymond> multi-line strings?
>
>Raymond> rows = self.executesql('''
>Raymond> select cities.city, state, country
>Raymond> from cities, venues, events, addresses
>Raymond> where cities.
[Skip]
> I use it all the time. For example, to build up (what I consider to be)
>readable SQL queries:
>
> rows = self.executesql("select cities.city, state, country"
>"from cities, venues, events, addresses"
>"where cities.city like %s"
>
PEP: Eliminating __del__
Motivation
Historically, __del__ has been one of the more error-laden dark corners
of the language. From an implementation point of view, it has
proven to be a thorny maintenance problem that grew almost beyond
the range of human comprehension once garbage collection wa
PEP: Remove Implicit String Concatenation
Motivation
One goal for Python 3000 should be to simplify the language by removing
unnecessary features. Implicit string concatenation should be dropped in
favor of existing techniques. This will simplify the grammar and simplify a
user's mental picture
1 - 100 of 164 matches
Mail list logo
