Hello all,
Recently I've found that rlcompleter does not work correctly with SWIG
generated classes.
In some cases dir(object) containes not only strings, but also type of
the object, smth like class 'mywrapper.IClassPtr'.
And condition word[:n] == attr throws an exception.
Is it possible to
Hi,
An interesting problem was pointed out to me, which I have distilled
to this testcase:
def gen():
raise TypeError, I am a TypeError
yield 1
def one(): return ''.join( x for x in gen() )
def two(): return ''.join([x for x in gen()])
for x in one, two:
try:
x()
Martin v. Löwis wrote:
[EMAIL PROTECTED] wrote:
Granted. What is the cost of waiting a bit longer to see if it (or
something else) gets more usable and would hit the mark better than svn?
It depends on what a bit is. Waiting a month would be fine; waiting
two years might be pointless.
This
Stephen Thorne wrote:
I can't see an obvious solution, but perhaps generators should get
special treatment regardless. Reading over this code it looks like the
generator is exhausted all at once, instead of incrementally..
Indeed - str.join uses a multipass approach to build the final string,
[Brett]
This obviously goes against what Guido last said he
wanted, but I hope I can convince him to get rid of bare 'except's.
-1 on eliminating bare excepts. This unnecessarily breaks tons of code
without offering ANY compensating benefits. There are valid use cases
for this construct. It
On Mon, Aug 15, 2005 at 09:16:47AM -0400, Raymond Hettinger wrote:
It is completely Pythonic to have bare keywords
apply a useful default as an aid to readability and ease of coding.
Bare while: was rejected because of while WHAT?!. Bare except:
does not cause except WHAT?! reaction. Isn't
It is completely Pythonic to have bare keywords
apply a useful default as an aid to readability and ease of coding.
[Oleg]
Bare while: was rejected because of while WHAT?!. Bare
except:
does not cause except WHAT?! reaction. Isn't it funny?! (-:
It's both funny and interesting. It
On Monday 15 August 2005 14:16, Raymond Hettinger wrote:
-1 on replacing except (KeyboardInterrupt, SystemExit) with except
TerminatingException.
The rationale for including TerminatingException in the PEP would also be
satisfied by having a TerminatingExceptions tuple (in the exceptions
On 8/8/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I will then assume that you and I have different ideas of what 'mature' means.
So I should then remove your
On 14-aug-2005, at 23:43, Martin v. Löwis wrote:
Ronald Oussoren wrote:
I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a
checkout that is less than two hours old. I'm building a standard
unix tree (no framework install):
I just committed what I think is a bugfix for the
I'm with Raymond here.
On 8/15/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Brett]
This obviously goes against what Guido last said he
wanted, but I hope I can convince him to get rid of bare 'except's.
-1 on eliminating bare excepts. This unnecessarily breaks tons of code
without
(1) Please use the SF patch manager.
(2) Please don't propose adding more bare except: clauses to the
standard library.
(3) I think a better patch is to use str(word)[:n] instead of word[:n].
On 8/14/05, Michael Krasnyk [EMAIL PROTECTED] wrote:
Hello all,
Recently I've found that
OK, I will take this as BDFL pronouncement that ditching bare
'except's is just not going to happen. Had to try. =)
And I will strip out the TerminatingException proposal.
-Brett
On 8/15/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm with Raymond here.
On 8/15/05, Raymond Hettinger
On 8/15/05, Toby Dickenson [EMAIL PROTECTED] wrote:
On Monday 15 August 2005 14:16, Raymond Hettinger wrote:
-1 on replacing except (KeyboardInterrupt, SystemExit) with except
TerminatingException.
The rationale for including TerminatingException in the PEP would also be
satisfied by
On Mon, 2005-08-15 at 12:27 -0400, Nicholas Bastin wrote:
On 8/8/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I will then assume that you and I have
Toby Dickenson wrote:
On Monday 15 August 2005 14:16, Raymond Hettinger wrote:
The rationale for including TerminatingException in the PEP would also be
satisfied by having a TerminatingExceptions tuple (in the exceptions
module?). It makes sense to express the classification of exceptions
On 8/15/05, Scott David Daniels [EMAIL PROTECTED] wrote:
An argument _for_ TerminatingException as a class is that I can
define my own subclasses of TerminatingException without forcing
it to being a subclass of KeyboardInterrupt or SystemExit.
And how would that help you? Would your own
Nicholas Bastin wrote:
Not completely. More like -0 at the moment. We need a better system,
but I think we shouldn't just pick a system because it's the one the
PEP writer preferred - there should be some sort of effort to test a
few systems (including bug trackers).
But that's how the PEP
On Aug 15, 2005, at 5:04 PM, Bryan O'Sullivan wrote:
The centralised SCM tools all create a wall between core developers
(i.e. people with commit access to the central repository) and people
who are on the fringes. Outsiders may be able to get anonymous
read-only access, but they are left up
Bryan O'Sullivan wrote:
However, it's worth pointing out that with a distributed SCM - it
doesn't really matter which one you use - it is simple to put together a
workflow that operates in the same way as a centralised SCM. You lose
nothing in the translation. What you gain is several-fold:
On Mon, 2005-08-15 at 23:29 +0200, Martin v. Löwis wrote:
That may be off-topic for python-dev, but can you please explain how
this works?
It's simple enough. In place of a central server that hosts a set of
repositories and a number of branches, and to which only a few people
have access,
[Bryan O'Sullivan]
The centralised SCM tools all create a wall between core developers
(i.e. people with commit access to the central repository) and
people
who are on the fringes. Outsiders may be able to get anonymous
read-only access, but they are left up to their own devices if they
[Martin v. Löwis]
I have placed a new version of the PEP on
http://www.python.org/peps/pep-0347.html
...
+1 from me. But, I don't think my vote should count much, and (sorry)
Guido's even less: what do the people who frequently check in want?
That means people like you (Martin), Michael,
You don't need something like a buggy SWIG to put non-strings in dir().
class C: pass
...
C.__dict__[3] = bad wolf
dir(C)
[3, '__doc__', '__module__']
This is likely to happen legitimately, for instance in a class that allows
x.y and x['y'] to mean the same thing. (if the user assigns to
On Sun, 14 Aug 2005 21:39:41 -0500, skip wrote:
Lalo You can, however, convert from CVS to baz (arch), and from there
Lalo to bzr.
Would this be with cscvs? According to the cscvs wiki page at
http://wiki.gnuarch.org/cscvs
cscvs is current unmaintained and can't handle
On Mon, 2005-08-15 at 04:30, Benji York wrote:
Martin v. Löwis wrote:
[EMAIL PROTECTED] wrote:
Granted. What is the cost of waiting a bit longer to see if it (or
something else) gets more usable and would hit the mark better than svn?
It depends on what a bit is. Waiting a month would
26 matches
Mail list logo
