[EMAIL PROTECTED] writes:
The Python source code repository is now converted to subversion;
please feel free to start checking out new sandboxes. For a few
days, this installation probably still needs to be considered in
testing. If there are no serious problems found by next Monday,
I would
Thomas Heller [EMAIL PROTECTED] writes:
Can anyone recommend an XEmacs svn plugin to use - I've tried psvn.el
from http://www.xsteve.at/prg/emacs/psvn.el which seems to work?
I've heard http://www.xsteve.at/prg/emacs/psvn.el works :)
I also have vc-svn.el installed (I think it's from the
On 10/28/05, Neil Hodgson [EMAIL PROTECTED] wrote:
I used to work on software written by Japanese and English speakers
at Fujitsu with most developers being Japanese. The rules were that
comments could be in Japanese but identifiers were only allowed to
contain ASCII characters. Most
Brett Cannon wrote:
Anyway, as soon as the cron job posts the PEP to the web site (already
checked into the new svn repository) have a read and start expounding
about how wonderful it is and that there is no qualms with it
whatsoever. =)
You mean aside from the implementation of __getitem__
Fred L. Drake, Jr. wrote:
On Thursday 27 October 2005 14:16, Martin v. Löwis wrote:
I think I would request a separate address; I don't think I want to get
all webmaster email.
I like the idea of a separate address as well.
Perhaps the radically named [EMAIL PROTECTED]
Cheers,
Nick.
On Fri, 2005-10-28 at 03:53, Thomas Heller wrote:
Can anyone recommend an XEmacs svn plugin to use - I've tried psvn.el
from http://www.xsteve.at/prg/emacs/psvn.el which seems to work?
Yep, that's the one I use, albeit a few revs back from what's up there
now. It's had some performance
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Anyway, as soon as the cron job posts the PEP to the web site (already
checked into the new svn repository) have a read and start expounding
about how wonderful it is and that there is no qualms with it
whatsoever. =)
On 10/27/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Thursday 27 October 2005 23:03, Brett Cannon wrote:
I guess, but I just don't like wikis personally so I have no
inclination to make the conversion. If someone wants to make the
conversion over to the wiki and keep it up that's
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Anyway, as soon as the cron job posts the PEP to the web site (already
checked into the new svn repository) have a read and start expounding
about how wonderful
I don't follow why the PEP deprecates catching a category of exceptions
in a different release than it deprecates raising them. Why would a
release allow catching something that cannot be raised? I must be
missing something here.
Raymond
___
On 10/28/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I don't follow why the PEP deprecates catching a category of exceptions
in a different release than it deprecates raising them. Why would a
release allow catching something that cannot be raised? I must be
missing something here.
So
On 10/28/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I don't follow why the PEP deprecates catching a category of exceptions
in a different release than it deprecates raising them. Why would a
release allow catching something that cannot be raised? I must be
missing something here.
Neal Becker wrote:
OK, does python have a C API that would allow me to create a python file
object from my C (C++) code? Then instead of using python's fdopen I could
just do it myself.
I don't know - you will have to read the python source to find out
(this is actually not a pythondev
Brett Cannon wrote:
I have started a svn section in the dev FAQ
(http://www.python.org/dev/devfaq.html) pertaining to checking out a
project from the repository and other stuff discussed so far. If
something is not clear or people feel a step is missing, let me know.
One think that should be
Martin v. Löwis wrote:
I am also curious as to what you would have me check out for the
sandbox; whole directory or just the trunk?
You would usually only check out the trunk (unless you want to work
on a branch, of course).
Actually, you would probably check out a sandbox subdirectory,
Neil Hodgson wrote:
This is anecdotal but it appears to me that transliterations are
not commonly used apart from learning languages and some minimal help
for foreigners such as including transliterated names on railway
station name boards.
That would be my guess also. Transliteration is
On 10/28/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Why would a
release allow catching something that cannot be raised? I must be
missing something here.
So conforming code can catch exceptions raised by not-yet conforming
code.
That makes sense.
What was the rationale for
[EMAIL PROTECTED]
Though there's no svn/cvs cheatsheet there, you may also find isolated
tidbits in the Subversion FAQ:
http://subversion.tigris.org/faq.html
Just grep around for cvs.
[Martin v. Löwis]
In addition, you might want to read
http://www.python.org/dev/svn.html
Excellent
Brett Cannon wrote:
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick got the python-checkins email and then read the PEP from the
repository (or at least that is what I assume since that is how Neal
managed to catch the PEP literally in under 5 minutes after checkin).
Actually,
Brett Cannon wrote:
Interesting point, but I think that chaining should have more concrete
support ala PEP 344 or some other mechanism. I think most people
agree that exception chaining is important enough to have better
support than some implied way of a causing exception to be passed
Hello from Japan,
I googled discussions about non-ASCII identifiers in Japanese, but I
found no consensus. Major languages such as Java or VB support non-ASCII
identifiers, so projects uses non-ASCII identifiers for their programs
are existing. Not all Japanese programmers think this is a good
[Nick Coghlan]
Another point in PEP 352's favour, is that it makes it far more
feasible
to
implement something like PEP 344 by providing __traceback__ and
__prev_exc__ attributes on BaseException.
The 'raise' statement could then take care of setting them
appropriately
if it
was given an
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick got the python-checkins email and then read the PEP from the
repository (or at least that is what I assume since that is how Neal
managed to catch the PEP
[Trying to cut this short... We have too many threads for this topic. :-( ]
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
[on making args b/w compatible]
I agree changing the behaviour is highly unlikely to cause any serious
problems (mainly because anyone *caring* about the contents of
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Trying to cut this short... We have too many threads for this topic. :-( ]
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
[on making args b/w compatible]
I agree changing the behaviour is highly unlikely to cause any serious
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Interesting point, but I think that chaining should have more concrete
support ala PEP 344 or some other mechanism. I think most people
agree that exception chaining is important enough to have better
support than
On 10/29/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Another point in PEP 352's favour, is that it makes it far more feasible to
implement something like PEP 344 by providing __traceback__ and
__prev_exc__ attributes on BaseException.
Not sure if I'm fully in-context here, but watch out for
27 matches
Mail list logo
