Ilya Sandler wrote:
> So, would implementing gdb's "until" command instead of "next N" be a
> better idea? In its simplest form (without arguments) "until" advances to
> the next (textually) source line... This would solve the original problem of
> getting over list comprehensions...
I like that
Trent Mick wrote:
> One feature I like in Perforce (which Subversion doesn't have) is the
> ability to have pending changesets.
That sounds useful.
> Currently with svn you have to manually
> specify those 9 to be sure to not include the remaining one. With p4 you
> just say to check-in the whole
Raymond Hettinger wrote:
> If the PEP can't resist the urge to create new intermediate groupings,
> then start by grepping through tons of Python code to find-out which
> exceptions are typically caught on the same line. That would be a
> worthwhile empirical study and may lead to useful insights.
[Brett Cannon]
> At this point the only
> changes to the hierarchy are the addition of BaseException and
> TerminatingException, and the change of inheritnace for
> KeyboardInterrupt, SystemExit, and NotImplementedError.
TerminatingException
The rationale for adding Termi
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> While this would work, it would still feel wrong: the
Martin> binary data are *not* latin1 (most likely), so declaring
Martin> them to be latin1 would be confusing. Perhaps a synonym
Martin> '8bit' for latin1 coul
> "Donovan" == Donovan Baarda <[EMAIL PROTECTED]> writes:
Donovan> It all comes down to how painless branch/merge is. Many
Donovan> esoteric "features" of version control systems feel like
Donovan> they are there to workaround the absence of proper
Donovan> branch/merge histori
version 1.7 scales the proposal back once more
(http://www.python.org/peps/pep-0348.html). At this point the only
changes to the hierarchy are the addition of BaseException and
TerminatingException, and the change of inheritnace for
KeyboardInterrupt, SystemExit, and NotImplementedError. At this
> At OSCON, Anthony Baxter made the point that pdb is currently one of the
> more unPythonic modules.
What is unpythonic about pdb? Is this part of Anthony's presentation
online? (Google found a summary and slides from presentation but they
don't say anything about pdb's deficiencies)
Ilya
On M
[Brett Cannon]
> Wasn't there talk of getting rid of __del__ a little while ago and
> instead use weakrefs to functions to handle cleaning up?
There was from me, yes, with an eye toward P3K.
> Is that still feasible?
It never was, really. The combination of finalizers, cycles and
resurrection i
[Tim Peters]
>> If P3K retains them [__del__]-- or maybe even before --we should
>> consider taking "the Java dodge" on this one. That is, decree that
>> henceforth a __del__ method will get invoked by magic at most
>> once on any given object O, no matter how often O is resurrected.
[Phillip J.
On 8/8/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> I can't think of a Python feature with a higher aggregate
> braincell_burned / benefit ratio than __del__ methods. If P3K retains
> them-- or maybe even before --we should consider taking "the Java
> dodge" on this one. That is, decree that henc
At 09:12 PM 8/8/2005 -0400, Tim Peters wrote:
>I can't think of a Python feature with a higher aggregate
>braincell_burned / benefit ratio than __del__ methods. If P3K retains
>them-- or maybe even before --we should consider taking "the Java
>dodge" on this one. That is, decree that henceforth a
> > Should pdb's next command accept an optional numeric argument? It would
> > specify how many actual lines of code (not "line events")
> > should be skipped in the current frame before stopping,
> That would differ from gdb's "next ", which does "next" n times.
> It would be confusing if pdb
On 8/8/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> I can't think of a Python feature with a higher aggregate
> braincell_burned / benefit ratio than __del__ methods. If P3K retains
> them-- or maybe even before --we should consider taking "the Java
> dodge" on this one. That is, decree that hence
On Mon, 2005-08-08 at 17:51, Trent Mick wrote:
[...]
> [Donovan Baarda wrote]
> > On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
[...]
> You want to do checkins of code in a consisten state. Some large changes
> take a couple of days to write. During which one may have to do a couple
> minor things
[Armin Rigo]
> There are various proposals to add an attribute on exception instances
> to store the traceback (see PEP 344). A detail not discussed, which I
> thought of historical interest only, is that today's exceptions try very
> hard to avoid reference cycles, in particular the cycle
>
> '
On Aug 8, 2005, at 12:14 PM, Guido van Rossum wrote:
> Ouch. Too much discussion to respond to it all. Please remember that
> in Jythin and IronPython, str and unicode are already synonyms. That's
> how Python 3.0 will do it, except unicode will disappear as being
> redundant. I like the bytes/froz
Who made me the Perforce-bitch? Here I am screaming "Subversion!
Subversion!" and y'all think I just using that as cover for a p4 lover
affair. :)
[Donovan Baarda wrote]
> On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
> > One feature I like in Perforce (which Subversion doesn't have) is the
> >
[Tim Peters wrote]
> [Trent Mick]
> > ...
> > There are other little things, like not being able to trim the check-in
> > filelist when editing the check-in message. For example, say you have
> > 10 files checked out scattered around the Python source tree and you
> > want to check 9 of those in.
On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
> One feature I like in Perforce (which Subversion doesn't have) is the
> ability to have pending changesets. A changeset is, as with subversion,
> something you check-in atomically. Pending changesets in Perforce allow
> you to (1) group related files
[Phillip J. Eby]
> At 09:14 AM 8/8/2005 -0700, Guido van Rossum wrote:
> > I'm not going to change my mind on text() unless someone explains
> > what's so attractive about it.
> 2. It's more obvious to programmers that it's a *text* string rather
> than a string of bytes
I've no opinion on the
[Trent Mick]
> ...
> There are other little things, like not being able to trim the check-in
> filelist when editing the check-in message. For example, say you have
> 10 files checked out scattered around the Python source tree and you
> want to check 9 of those in.
This seems dubious, since you'
On Sat, Aug 06, 2005 at 06:56:39PM -0700, Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string -- after all, int() is allowed to return a long, so
> why couldn't str() be a
One feature I like in Perforce (which Subversion doesn't have) is the
ability to have pending changesets. A changeset is, as with subversion,
something you check-in atomically. Pending changesets in Perforce allow
you to (1) group related files in a source tree where you might be
working on multipl
Phillip J. Eby wrote:
> Actually, thinking about it some more, it seems to me it's actually more
> like this:
>
>sock.send( ("%d:%s," %
> (len(data),data.decode('latin1'))).encode('latin1') )
While this would work, it would still feel wrong: the binary data
are *not* latin1 (most likely), so
Trent Mick wrote:
>>No. The PEP is only about Subversion. Why should we be looking at Per
>>Force? Only because Python is Open Source?
>
>
> Perforce offers free licensing to open source projects.
Ok, so I now got "it's mature", and "it would be without charges".
Given that it is now running aga
On Mon, Aug 08, 2005, Trent Mick wrote:
>Martin:
>>
>> No. The PEP is only about Subversion. Why should we be looking at Per
>> Force? Only because Python is Open Source?
>
> Perforce offers free licensing to open source projects.
So did BitKeeper. Linux got bitten by that. We'd need a strong
I know I came after the battle. And I have just another sight on context
managment.
Simple Context Managment may look in Python 2.4.1 like this:
Synhronized example:
def Synhronised(lock,func):
lock.acquire()
try:
func()
finally:
lock.rele
[Aahz wrote]
> On Sun, Aug 07, 2005, Barry Warsaw wrote:
> >
> > We'd also have to teach the current crop of developers how to use the
> > client tools effectively. I think it's fairly simple to teach a CVS
> > user how to use Subversion, but have no idea if translating CVS
> > experience to Perfo
> > Since Python is Open Source are you looking at Per Force which you can
> > use for free and seems to be a happy medium between something like CVS
> > and something horrific like Clear Case?
>
> No. The PEP is only about Subversion. Why should we be looking at Per
> Force? Only because Python i
On 8/7/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > What is going in under python/ ? If it is what is currently
> > /dist/src/, then great and the renaming of the repository works.
>
> Just have a look yourself :-) Yes, this is dist/src.
>
Ah, OK. I didn't drill f
On Sun, Aug 07, 2005, Barry Warsaw wrote:
>
> We'd also have to teach the current crop of developers how to use the
> client tools effectively. I think it's fairly simple to teach a CVS
> user how to use Subversion, but have no idea if translating CVS
> experience to Perforce is as straightforward
Guido van Rossum wrote:
> Ouch. Too much discussion to respond to it all. Please remember that
> in Jythin and IronPython, str and unicode are already synonyms.
I know, but don't understand that argument: aren't we talking
about Python in general, not some particular implementation ?
Why should
At 09:14 AM 8/8/2005 -0700, Guido van Rossum wrote:
>I'm not going to change my mind on text() unless
>someone explains what's so attractive about it.
1. It's obvious to non-programmers what it's for (str and unicode aren't)
2. It's more obvious to programmers that it's a *text* string rather tha
On 8/8/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Attaching a __traceback__ will only make this "bug" show up more often,
> as the 'except Exception, e' line in a __del__() method would be enough
> to trigger it.
Hmm... We can blame this on __del__ as much as on __traceback__, of
course... But it
Ouch. Too much discussion to respond to it all. Please remember that
in Jythin and IronPython, str and unicode are already synonyms. That's
how Python 3.0 will do it, except unicode will disappear as being
redundant. I like the bytes/frozenbytes pair idea. Streams could grow
a getpos()/setpos() API
On Sun, Aug 07, 2005, Ilya Sandler wrote:
>
> Solution:
>
> Should pdb's next command accept an optional numeric argument? It would
> specify how many actual lines of code (not "line events")
> should be skipped in the current frame before stopping,
At OSCON, Anthony Baxter made the point that p
On Sun, Aug 07, 2005, Neil Schemenauer wrote:
> On Sat, Aug 06, 2005 at 06:56:39PM -0700, Guido van Rossum wrote:
>>
>> My first response to the PEP, however, is that instead of a new
>> built-in function, I'd rather relax the requirement that str() return
>> an 8-bit string
>
> Do you have any th
At 10:07 AM 8/8/2005 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> >>Hm. What would be the use case for using %s with binary, non-text data?
> >
> >
> > Well, I could see using it to write things like netstrings,
> > i.e. sock.send("%d:%s," % (len(data),data)) seems like the One Obvious
Michael Hudson wrote:
> "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
>
>
>>Set the external encoding for stdin, stdout, stderr:
>>
>>(also an example for adding encoding support to an
>>existing file object):
>>
>>def set_sys_std_encoding(encodin
Guido van Rossum wrote:
> [Guido]
>
>>>My first response to the PEP, however, is that instead of a new
>>>built-in function, I'd rather relax the requirement that str() return
>>>an 8-bit string -- after all, int() is allowed to return a long, so
>>>why couldn't str() be allowed to return a Unicod
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>>The bytes type could just be a very thin wrapper around array('b').
>
> That answers an important question: so you want the bytes type to be
> mutable (and, consequently, unsuitable as a dictionary key).
I would suggest a bytes/frozenbytes pair,
Barry Warsaw <[EMAIL PROTECTED]> writes:
> Unfortunately, I don't think "we" (meaning specifically the collective
> python.org admins) have much if any operational experience with
> Perforce.
Also (from someone who is on the fringes of the pydotorg admin set): I
don't know that much about subvers
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> Set the external encoding for stdin, stdout, stderr:
>
> (also an example for adding encoding support to an
> existing file object):
>
> def set_sys_std_encoding(encoding):
> # Load encoding supp
On Sun, Aug 07, 2005 at 11:51:49PM -0400, Barry Warsaw wrote:
> Has anyone experienced svn corruptions with the fsfs backend? I
> haven't, across quite a few repositories.
I haven't. But I must admit that the repositories I'm working with
aren't big. The bigest is at svn.colorstudy.com (I am w
Hi,
On Mon, Aug 08, 2005 at 10:31:06AM +0200, Armin Rigo wrote:
> see the attached program...
Oups. Here it is...
Armin
import sys, time
def log(typ, val, tb):
pass
class X:
def __del__(self):
try:
typo
except Exception, e:
e_type, e_value, e_t
Hi all,
There are various proposals to add an attribute on exception instances
to store the traceback (see PEP 344). A detail not discussed, which I
thought of historical interest only, is that today's exceptions try very
hard to avoid reference cycles, in particular the cycle
'frame -> local
Stephen J. Turnbull wrote:
> If you mean the UTF-8 support in Terminal, it's no better or worse
> than the EUC-JP support. The problem is that most Japanese Unix
> systems continue to default to EUC-JP, and many Windows hosts
> (including Samba file systems) default to Shift JIS. So people using
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> I think your doubts are unfounded. Many Japanese people
Martin> change it to EUC-JP (I believe), as UTF-8 support doesn't
Martin> work well for them (or atleast didn't use to).
If you mean the UTF-8 support in Termin
Phillip J. Eby wrote:
>>Hm. What would be the use case for using %s with binary, non-text data?
>
>
> Well, I could see using it to write things like netstrings,
> i.e. sock.send("%d:%s," % (len(data),data)) seems like the One Obvious Way
> to write a netstring in today's Python at least. But
Guido van Rossum wrote:
> We might be able to get there halfway in Python 2.x: we could
> introduce the bytes type now, and provide separate APIs to read and
> write them. (In fact, the array module and the f.readinto() method
> make this possible today, but it's too klunky so nobody uses it.
> Pe
Bob Ippolito wrote:
> It's UTF-8 by default, I highly doubt many people bother to change it.
I think your doubts are unfounded. Many Japanese people change it to
EUC-JP (I believe), as UTF-8 support doesn't work well for them (or
atleast didn't use to).
Regards,
Martin
___
On Sun, Aug 07, 2005 at 11:11:56PM +0200, "Martin v. Löwis" wrote:
> I've looked at the patch, and it looks fairly safe, so I committed it.
Thanks. I did not forget my promise to look into a more comprehensive
approach to the C++ build issues. But I first need to better understand the
potential im
53 matches
Mail list logo
