Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system.
I had the last corrupted repository with
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.
But if that is what src/ is going to be used for
This is nondist/src. Perhaps I should just
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
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
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.
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 perhaps
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 Terminal, it's no
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
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 support
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 subversion
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,
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 Unicode string?
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(encoding):
# Load
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
Way
to
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 thoughts on
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 pdb is
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()
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 is
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 than
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.
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 far enough
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:
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
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 against
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
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
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
[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're
[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
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 in
[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.
This
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
[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
'frame
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 in
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 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 n, which does next n times.
It would be confusing if pdb accepted the
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
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 henceforth
[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. Eby]
How
[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 is
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
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
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 histories.
It's not
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 could be
[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
45 matches
Mail list logo
