Re: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
> "Neil" == Neil Hodgson <[EMAIL PROTECTED]> writes: Neil> Most variable names were poorly chosen with s, p, q, fla Neil> (boolean=flag) and flafla being popular. When I asked some Neil> Japanese coders why they didn't use Japanese words expressed Neil> in ASCII (Romaji), their response was that it was a really Neil> weird idea. That may be due to the fact that two-ideograph words will often have a dozen homonyms, and sometimes several dozen. I sometimes use kanji in not-for-general-distribution Emacs LISP code when 2 kanji will give as expressive an identifier as 10 or 15 ASCII characters. Neil> This is anecdotal but it appears to me that transliterations Neil> are not commonly used apart from learning languages In everyday usage, they're used a lot for identifier-like purposes like corporate logos. The only large corpuses of Japanese-oriented Japanese-authored code I'm familiar with are the input methods Wnn, Canna, and SKK, and these invariably use transliterated Japanese grammatical terms for parser components[1], although there are perfectly good equivalents in English, at least (I think they may actually be standardized by the Ministry of Education). There's also an Emacs library, edict.el, that uses _mixed_ ASCII-hiragana-kanji identifiers. (ISTR that was done just to prove a point---the person who wrote it was an American, I believe---definitely not Japanese.) Footnotes: [1] Japanese does not require word delimiters, so input methods must have grammatical knowledge to choose among large numbers of homonyms. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
[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 consider conversion of the data complete. The CVS repository > will be kept available read-only for a while longer, so you can > easily forward any patches you may have. > > Most of you are probably interested in checking out one of these > folders: > > svn+ssh://[EMAIL PROTECTED]/python/trunk > svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint > svn+ssh://[EMAIL PROTECTED]/peps > Works out of the box for me, thanks, Martin (but we have debugged this before). 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? Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
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 subversion source, but it might be part of newer emacs distributions). Cheers, mwh -- INEFFICIENT CAPITALIST YOUR OPULENT TOILET WILL BE YOUR UNDOING -- from Twisted.Quotes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
Michael Hudson <[EMAIL PROTECTED]> writes: > 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 subversion > source, but it might be part of newer emacs distributions). I've heard that vc-svn.el does NOT work with Xemacs (note the X), but haven't tried it myself. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
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 variable names were poorly chosen with > s, p, q, fla (boolean=flag) and flafla being popular. When I asked > some Japanese coders why they didn't use Japanese words expressed in > ASCII (Romaji), their response was that it was a really weird idea. > >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. Israeli programmers generally use English identifiers but transliterations are common for local business terminology: types of financial instruments, tax and insurance terminology, employee benefit plans etc. Yes, it looks weird, but it would be rather pointless to try to translate them. Even native English speakers would find it difficult to recognize the translations because they are used to using them as loan words. Only transliteration (or possibly the use of non-ASCII identifiers) would make sense in this situation and I do not think it is unique to Israel. BTW, I heard about a Cobol shop that had an explicit policy of using only transliterated identifiers. This resulted in a much smaller chance of hitting one of Cobol's numerous reserved words. Thankfully, this is not an issue in Python... Oren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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__ being broken in BaseException*? ;) Aside from that, I actually do have one real problem and one observation. The problem: The value of ex.args The PEP as written significantly changes the semantics of ex.args - instead of being an empty tuple when no arguments are provided, it is instead a singleton tuple containing the empty string. A backwards compatible definition of BaseException.__init__ would be: def __init__(self, *args): self.args = args self.message = '' if not args else args[0] The observation: The value of ex.message Under PEP 352 the concept of allowing "return x" to be used in a generator to mean "raise StopIteration(x)" would actually align quite well. A bare "return", however, would need to be changed to translate to "raise StopIteration(None)" rather than its current "raise StopIteration" in order to get the correct value (None) into ex.message. Cheers, Nick. * (self.args[0] is self.message) due to the way __init__ is written, but __getitem__ assumes self.message isn't in self.args) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
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. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
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 problems in the past, but is generally pretty good these days. I've had issues with it bogging down XEmacs /after/ running stat on a very large tree. It seems (seemed?) as though it was still hogging cpu even after the actual back-end svn command was finished. My only other nit is that I wish I could svn stat a few directories at a time. Say I know that only directory A and B are out of date. At the command line I can say "svn stat A B" or "svn commit A B". Can't really do that in psvn.el, but I can understand why that's problematic. I also would love it to be hooked into vc-mode too, for modeline updates and commits of single files. I can understand why those things aren't there yet though. All in all psvn.el works very well, although it's not (for me) a complete replacement for the command line. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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. =) > > You mean aside from the implementation of __getitem__ being broken in > BaseException*? ;) Are you clairvoyant?! The cronjob wass broken due to the SVN transition and the file wasn't on the site yet. (Now fixed BTW.) Oh, and here's the URL just in case: http://www.python.org/peps/pep-0352.html > Aside from that, I actually do have one real problem and one observation. > > The problem: The value of ex.args > >The PEP as written significantly changes the semantics of ex.args - instead > of being an empty tuple when no arguments are provided, it is instead a > singleton tuple containing the empty string. > >A backwards compatible definition of BaseException.__init__ would be: > > def __init__(self, *args): > self.args = args > self.message = '' if not args else args[0] But does anyone care? As long as args exists and is a tuple, does it matter that it doesn't match the argument list when the latter was empty? IMO the protocol mostly says that ex.args exists and is a tuple -- the values in there can't be relied upon in pre-2.5-Python. Exceptions that have specific information should store it in a different place, not in ex.args. > The observation: The value of ex.message > >Under PEP 352 the concept of allowing "return x" to be used in a generator > to mean "raise StopIteration(x)" would actually align quite well. A bare > "return", however, would need to be changed to translate to "raise > StopIteration(None)" rather than its current "raise StopIteration" in order to > get the correct value (None) into ex.message. Since ex.message is new, how can you say that it should have the value None? IMO the whole idea is that ex.message should always be a string going forward (although I'm not going to add a typecheck to enforce this). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
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 fine, but I have no > > problem keeping the dev FAQ updated like I have for CVS in the past. > > And I'm sure we all appreciate your efforts! I certainly do. > > Regarding using the wiki... I have mixed feelings. Wikis are really, really > good for some things. Anything that's "how-to" based on technology (how to > use SVN, CVS, etc.) seems like a reasonable candidate, because we get the > advantages of peer review. > > For things that describe policy, I don't think that's so great. For policy > (how to use SVN for Python development, because we have certain rules), I > think we want to maintain strict editorial control. > I like that explanation more than mine. =) So I am just going to keep the FAQ up then. If there is anything at http://www.python.org/dev/svn.html people feel should be moved over to the FAQ that has not occurred yet, let me know. Please have personal experience, though, with what you want added so as to make sure the information is relevant (e.g., Tim suffering through getting an SSH 2 key for Windows and what is exactly needed, complete with screenshots =) . -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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 it is and that there is no qualms with it > > > whatsoever. =) > > > > You mean aside from the implementation of __getitem__ being broken in > > BaseException*? ;) > > Are you clairvoyant?! The cronjob wass broken due to the SVN > transition and the file wasn't on the site yet. (Now fixed BTW.) Oh, > and here's the URL just in case: > http://www.python.org/peps/pep-0352.html > 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). > > Aside from that, I actually do have one real problem and one observation. > > > > The problem: The value of ex.args > > > >The PEP as written significantly changes the semantics of ex.args - > > instead > > of being an empty tuple when no arguments are provided, it is instead a > > singleton tuple containing the empty string. > > > >A backwards compatible definition of BaseException.__init__ would be: > > > > def __init__(self, *args): > > self.args = args > > self.message = '' if not args else args[0] > > But does anyone care? As long as args exists and is a tuple, does it > matter that it doesn't match the argument list when the latter was > empty? IMO the protocol mostly says that ex.args exists and is a tuple > -- the values in there can't be relied upon in pre-2.5-Python. > Exceptions that have specific information should store it in a > different place, not in ex.args. > Looking at http://docs.python.org/lib/module-exceptions.html , it looks like Guido is right. All it ever says is that it is a tuple and that any passed-in arguments go into 'args'; nothing about its default value if no arguments are passed in. But I personally have no qualms changing it if people want it, so -0 from me on making it more backwards-compatible. > > The observation: The value of ex.message > > > >Under PEP 352 the concept of allowing "return x" to be used in a > > generator > > to mean "raise StopIteration(x)" would actually align quite well. A bare > > "return", however, would need to be changed to translate to "raise > > StopIteration(None)" rather than its current "raise StopIteration" in order > > to > > get the correct value (None) into ex.message. > > Since ex.message is new, how can you say that it should have the value > None? IMO the whole idea is that ex.message should always be a string > going forward (although I'm not going to add a typecheck to enforce > this). > My feeling exactly on 'message'. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 352 Transition Plan
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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 conforming code can catch exceptions raised by not-yet conforming code. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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. Presumably because they CAN still be raised; attempting to do so provokes a warning, not an error. It also facilitates upgrading from old versions of Python. You can work to eliminate cases where the exceptions are raised while still handling them if they do get raised. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
> > 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 pushing the deprecation of __getitem__ and
args back to Py2.8? Is the there a disadvantage for doing it earlier?
On the flip side, is there any reason it has to be done at all prior to
Py3.0? That change seems orthogonal to the rest of the proposal and has
its own pluses and minuses (simplification on the plus-side and
code-breakage on the minus-side).
FWIW, the args tuple does have a legitimate use case as one solution to
the problem of exception chaining (keeping the old info intact, but
adding new info as an extra field):
try:
raise TypeError('inner detail')
except TypeError, e:
args = e.args + ('outer context',)
raise TypeError(*args)
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help with inotify
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 question anymore). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
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 carried over from svn.ht is how to setup Putty on Windows. The issue is that subversion will look for a ssh binary in its path, and if there is none, it fails. Saying [tunnels] ssh="c:/program files/putty/plink.exe" -T in subversion's config file does the trick (see svn.html). If you use a different SSH client, you need to adjust the configuration accordingly. FYI, -T specifies to not allocate a terminal. plink has the nice feature of giving GUI feedback if there is no terminal for interactive feedback (such as whether the remote key is trusted). This makes it useful for TortoiseSVN. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
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, such as http://svn.python.org/projects/sandbox/trunk/decimal/ (say). We don't have a policy for making tags or branches for single directories only; I would suggest that either "tags/decimal-1.0" or "tags/decimal/1.0" would be acceptable (depending on how frequently anticipate to make takes, perhaps). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
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 clearly common for Latin-based languages (French, German, Spanish, say), but I doubt non-Latin scripts are that often transliterated (even if conventions exist). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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 pushing the deprecation of __getitem__ and
> args back to Py2.8? Is the there a disadvantage for doing it earlier?
> On the flip side, is there any reason it has to be done at all prior to
> Py3.0? That change seems orthogonal to the rest of the proposal and has
> its own pluses and minuses (simplification on the plus-side and
> code-breakage on the minus-side).
>
I thought that there was no exact rush on their removal. And I
suspect the later versions of the 2.x branch will be used to help ease
transition to Python 3, so I figured pushing it to 2.8 seemed like a
good idea. I could even push it all the way to 2.9 if people prefer.
> FWIW, the args tuple does have a legitimate use case as one solution to
> the problem of exception chaining (keeping the old info intact, but
> adding new info as an extra field):
>
>try:
> raise TypeError('inner detail')
>except TypeError, e:
> args = e.args + ('outer context',)
> raise TypeError(*args)
>
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
along. Perhaps something more along the lines of:
try:
raise TypeError("inner detail")
except TypeError, e:
raise TypeError("outer detail", cause=e)
where BaseException then has a 'cause' attribute that is set to None
by default or some specific object that is passed in as the second
argument to the constructor.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
[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 suggestions! I have a few to pass on: 1. CVS uses "update" for all sorts of things. SVN has different commands for several of the use cases CVS's update conflates: - Updating to the current server state. "svn update" does that, and SVN's update isn't useful for anything other than that. - Finding out what's changed in your sandbox. Use "svn status" for that. Bonus: in return for creating zillions of admin files, "svn status" is a local operation (no network access required). Do "svn status -u" to get, in addition, a listing of files that _would_ change if you were to do "svn update". - Merging. Use "svn merge" for that. This includes the case of reverting a checkin, in which case just reverse the revision numbers: svn merge URL -rNEW:OLD where NEW is the revision number of the checkin you want to revert, and OLD is typically NEW-1. Very nice: this reverts _all_ changes made in revision NEW, no matter how many files were involved. 2. Every checkin conceptually creates a new version of the entire repository, uniquely identified by its revision number. This is very powerful, but subtle, and CVS has nothing like it. A glimpse of its power was given just above, talking about the ease of reverting an entire checkin in one easy gulp, 3. You're working on a trunk sandbox and discover it's going to take longer than you hoped. Now you wish you had created a branch. This is actually dead easy: create a new branch of the trunk. "svn switch" your sandbox to that new branch; this leaves your local change alone, which is key. "svn commit" -- you're done! There's now a branch on the server matching your fiddled local state. 4. Making a branch or tag goes very fast under SVN. Because branches and tags are just conventionally-named directories, you can delete them (like any other directory) when you're done with them. These conspire to make simple applications of branches much more pleasant than under CVS. 5. CVS uses text mode for files by default. SVN uses binary mode. The latter is safer, but creates endless low-level snags for x-platform development. I encourage Python developers to include this gibberish in their SVN config file: """ [auto-props] # Setting eol-style to native on all files is a trick: if svn # believes a new file is binary, it won't honor the eol-style # auto-prop. However, svn considers the request to set eol-style # to be an error then, and if adding multiple files with one # svn "add" cmd, svn will stop adding files after the first # such error. A future release of svn will probably consider # this to be a warning instead (and continue adding files). * = svn:eol-style=native *.c = svn:keywords=Id *.h = svn:keywords=Id *.py = svn:keywords=Id """ Then SVN will set the necessary svn:eol-style property to "native" on new text files you commit. I've never yet seen it tag a file inappropriately using this trick, but it's guaranteed to screw up _all_ text files without something like this (unless you have the patience and discipline to manually set eol-style=native on all new text files you add). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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, when you first check a PEP in, the diff includes the entire text of the PEP - so I just read the python-checkins email :) >> But does anyone care? As long as args exists and is a tuple, does it >> matter that it doesn't match the argument list when the latter was >> empty? IMO the protocol mostly says that ex.args exists and is a tuple >> -- the values in there can't be relied upon in pre-2.5-Python. >> Exceptions that have specific information should store it in a >> different place, not in ex.args. > > Looking at http://docs.python.org/lib/module-exceptions.html , it > looks like Guido is right. All it ever says is that it is a tuple and > that any passed-in arguments go into 'args'; nothing about its default > value if no arguments are passed in. > > But I personally have no qualms changing it if people want it, so -0 > from me on making it more backwards-compatible. I agree changing the behaviour is highly unlikely to cause any serious problems (mainly because anyone *caring* about the contents of args is rare), the current behaviour is relatively undocumented, and the PEP now proposes deprecating ex.args immediately, so Guido's well within his rights if he wants to change the behaviour. I was merely commenting from the 'its an unnecessary change to existing behaviour' angle, since the backwards compatible version gives the same behaviour of the new ex.message API as the version in the PEP, while leaving the now-deprecated ex.args API behaviour identical to that in Python 2.4. In other words, I'm looking for a *benefit* that comes from the behavioural change, rather than a 'but the current behaviour is undocumented anyway' response. If there's no actual benefit in breaking it, then why break it? :) >>> The observation: The value of ex.message >>> >>>Under PEP 352 the concept of allowing "return x" to be used in a >>> generator >>> to mean "raise StopIteration(x)" would actually align quite well. A bare >>> "return", however, would need to be changed to translate to "raise >>> StopIteration(None)" rather than its current "raise StopIteration" in order >>> to >>> get the correct value (None) into ex.message. >> Since ex.message is new, how can you say that it should have the value >> None? IMO the whole idea is that ex.message should always be a string >> going forward (although I'm not going to add a typecheck to enforce >> this). >> > > My feeling exactly on 'message'. I'm talking about the specific context of the behaviour of 'return' in generators, not on the behaviour of ex.message in general. For normal exceptions, I agree '' is the correct default. For that specific case of allowing a return value from generators, and using it as the message on the raised StopIteration, *then* it makes sense for "return" to translate to "raise StopIteration(None)", so that generators have the same 'default return value' as normal functions. There's a reason I said it was just an observation - it has no effect on PEP 352 itself, only on a *different* syntax extension that hasn't even been officially suggested in a PEP (only mentioned in passing when discussing PEP 342). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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
> along. Perhaps something more along the lines of:
>
> try:
> raise TypeError("inner detail")
> except TypeError, e:
> raise TypeError("outer detail", cause=e)
>
> where BaseException then has a 'cause' attribute that is set to None
> by default or some specific object that is passed in as the second
> argument to the constructor.
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 instance of BaseException to raise.
Actually, that brings up another question - PEP 352 says it will require
objects that "inherit from BaseException". Does that mean that either subtypes
or instances of BaseException will be acceptable? Or does it just mean
instances? If the latter, how will that affect the multi-argument forms of
'raise'?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
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 idea. Some people enthusiastically prefer Japanese identifiers, but some feel it reduces readability and hard to type, some worry about tool breakages or encoding problem, etc. It looks that smart people don't like to express their preference to Japanese identifiers, maybe because they think such style is not cool, or they are afraid such confession may reveal lack of their English ability.;) I'm +0.1 for non-ASCII identifiers, although module names should remain ASCII. ASCII identifiers might be encouraged, but as Martin said, it is very useful for some groups of users. On Sat, 29 Oct 2005 00:21:03 +0200 "Martin v. Lvwis" <[EMAIL PROTECTED]> wrote: > 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 clearly common for > Latin-based languages (French, German, Spanish, say), but I doubt > non-Latin scripts are that often transliterated (even if conventions > exist). > Yes, transliterations are rarely used in daily life in Japan. For programming, I know a lot of projects use transliterated Japanses style, but I guess they are rather minority. -- Atsuo Ishimoto [EMAIL PROTECTED] Homepage:http://www.gembook.jp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
[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 instance of BaseException to raise. IMO, there is no reason to take e.args out of the Py2.x series. Take-aways should be left for Py3.0. The existence of a legitimate use case means that there may be working code in the field that would be broken unnecessarily. Nothing is gained by this breakage. If 344 gets accepted and implemented, that's great. Either way, there is no rationale for chopping this long standing feature before 3.0. IIRC, that was the whole point of 3.0 -- we could take out old stuff that had been replaced by new and better things; otherwise, we would simply deprecate old-style classes and be done with it in Py2.5 or Py2.6. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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 literally in under 5 minutes after checkin). > > Actually, when you first check a PEP in, the diff includes the entire text of > the PEP - so I just read the python-checkins email :) > > >> But does anyone care? As long as args exists and is a tuple, does it > >> matter that it doesn't match the argument list when the latter was > >> empty? IMO the protocol mostly says that ex.args exists and is a tuple > >> -- the values in there can't be relied upon in pre-2.5-Python. > >> Exceptions that have specific information should store it in a > >> different place, not in ex.args. > > > > Looking at http://docs.python.org/lib/module-exceptions.html , it > > looks like Guido is right. All it ever says is that it is a tuple and > > that any passed-in arguments go into 'args'; nothing about its default > > value if no arguments are passed in. > > > > But I personally have no qualms changing it if people want it, so -0 > > from me on making it more backwards-compatible. > > I agree changing the behaviour is highly unlikely to cause any serious > problems (mainly because anyone *caring* about the contents of args is rare), > the current behaviour is relatively undocumented, and the PEP now proposes > deprecating ex.args immediately, so Guido's well within his rights if he wants > to change the behaviour. > > I was merely commenting from the 'its an unnecessary change to existing > behaviour' angle, since the backwards compatible version gives the same > behaviour of the new ex.message API as the version in the PEP, while leaving > the now-deprecated ex.args API behaviour identical to that in Python 2.4. > > In other words, I'm looking for a *benefit* that comes from the behavioural > change, rather than a 'but the current behaviour is undocumented anyway' > response. If there's no actual benefit in breaking it, then why break it? :) > The benefit for me was that the code kept the 'message' argument and thus, in my mind, made it much more obvious that 'mesage' and 'args' are different. But I think I have a much more reasonable solution that lets me keep the 'message' argument explicit. It also let me use the conditional operator to simplify the code more. So I went ahead and made it the more backwards-compatible. > >>> The observation: The value of ex.message > >>> > >>>Under PEP 352 the concept of allowing "return x" to be used in a > >>> generator > >>> to mean "raise StopIteration(x)" would actually align quite well. A bare > >>> "return", however, would need to be changed to translate to "raise > >>> StopIteration(None)" rather than its current "raise StopIteration" in > >>> order to > >>> get the correct value (None) into ex.message. > >> Since ex.message is new, how can you say that it should have the value > >> None? IMO the whole idea is that ex.message should always be a string > >> going forward (although I'm not going to add a typecheck to enforce > >> this). > >> > > > > My feeling exactly on 'message'. > > I'm talking about the specific context of the behaviour of 'return' in > generators, not on the behaviour of ex.message in general. For normal > exceptions, I agree '' is the correct default. > > For that specific case of allowing a return value from generators, and using > it as the message on the raised StopIteration, *then* it makes sense for > "return" to translate to "raise StopIteration(None)", so that generators have > the same 'default return value' as normal functions. > > There's a reason I said it was just an observation - it has no effect on PEP > 352 itself, only on a *different* syntax extension that hasn't even been > officially suggested in a PEP (only mentioned in passing when discussing PEP > 342). > Ah, OK. So you just want to make sure that at the generator level that the bytecode (or the ceval loop, not sure where the change would need to be made) that the StopIteration be raised with an explicit 'message' argument of None. Which obviously does not directly affect PEP 352, but should be considered as a possible change. That makes sense to me and I have no trouble with that, but that is partially because I don't have to make that change. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
[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 args is rare), > the current behaviour is relatively undocumented, and the PEP now proposes > deprecating ex.args immediately, so Guido's well within his rights if he wants > to change the behaviour. I take it back. Since the feature will disappear in Python 3.0 and is maintained only for b/w compatibility, we should keep it as b/w compatible as possible. That means it should default to () and always have as its value exactly the positional arguments that were passed. OTOH, I want message to default to "", not to None (even though it will be set to None if you explicitly pass None as the first argument). So the constructor could be like this (until Python 3000): def __init__(self, *args): self.args = args if args: self.message = args[0] else: self.message = "" I think Nick proposed this before as well, so let's just do this. > I'm talking about the specific context of the behaviour of 'return' in > generators, not on the behaviour of ex.message in general. For normal > exceptions, I agree '' is the correct default. > > For that specific case of allowing a return value from generators, and using > it as the message on the raised StopIteration, *then* it makes sense for > "return" to translate to "raise StopIteration(None)", so that generators have > the same 'default return value' as normal functions. I don't like that (not-even-proposed) feature anyway. I see no use for it; it only gets proposed by people who are irked by the requirement that generators can contain 'return' but not 'return value'. I think that irkedness is unwarranted; 'return' is useful to cause an early exit, but generators don't have a return value so 'return value' is meaningless. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
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 > > problems (mainly because anyone *caring* about the contents of args is > > rare), > > the current behaviour is relatively undocumented, and the PEP now proposes > > deprecating ex.args immediately, so Guido's well within his rights if he > > wants > > to change the behaviour. > > I take it back. Since the feature will disappear in Python 3.0 and is > maintained only for b/w compatibility, we should keep it as b/w > compatible as possible. That means it should default to () and always > have as its value exactly the positional arguments that were passed. > > OTOH, I want message to default to "", not to None (even though it > will be set to None if you explicitly pass None as the first > argument). So the constructor could be like this (until Python 3000): > > def __init__(self, *args): > self.args = args > if args: > self.message = args[0] > else: > self.message = "" > > I think Nick proposed this before as well, so let's just do this. Yeah, but Nick used the conditional operator and I used that. All checked in. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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 some implied way of a causing exception to be passed
> > along. Perhaps something more along the lines of:
> >
> > try:
> > raise TypeError("inner detail")
> > except TypeError, e:
> > raise TypeError("outer detail", cause=e)
> >
> > where BaseException then has a 'cause' attribute that is set to None
> > by default or some specific object that is passed in as the second
> > argument to the constructor.
>
> 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 instance of BaseException to raise.
>
Yep. This is why having a guaranteed API is so handy for exceptions.
And actually PEP 3000 says that exceptions are supposed to gain a
traceback attribute. But that can be another PEP if PEP 344 doesn't
make it.
> Actually, that brings up another question - PEP 352 says it will require
> objects that "inherit from BaseException". Does that mean that either subtypes
> or instances of BaseException will be acceptable? Or does it just mean
> instances? If the latter, how will that affect the multi-argument forms of
> 'raise'?
>
I don't see how a multi-argument 'raise' changes the situation any.
``raise BaseException`` and ``raise BaseException()`` must both be
supported which means isinstance() or issubtype() will be used (unless
Python 3 bans raising a class or something).
-Brett
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
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 __traceback__ and garbage collection, since the traceback objects refer to all the frames. I expect there's a significant amount of code out there that expects Exception instances to be reasonably persistent. At least Twisted does, with its encapsulation of Exceptions for the purposes of asynchrony -- Failure objects. These Failure objects also refer to tracebacks, but we had to be very careful about deleting them fairly quickly because of GC issues. After deletion they simply contain an inert, basically stringified copy of the traceback. On an only semi-related note, at one point I tried making it possible to have longer-lived Traceback objects that could be reraised, but found it very hard to do, at least with my self-imposed requirement of keeping it in an extension module. http://mail.python.org/pipermail/python-dev/2005-September/056091.html -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 343 updated with outcome of recent discussions
Once the cron job works it magic, the updated PEP 343 should be available on the website. As far as I am aware, there aren't any more open issues, so it is once again ready for BDFL pronouncement. I also tinkered with the example naming a bit, and added a new example for the "nested" context manager (it turns out there *were* mistakes in the last version I posted here - I had the deque method name wrong, and I wasn't invoking __context__ correctly on the nested contexts). Cheers, Nick. P.S. My availability will be sketchy for the rest of this weekend, then nonexistent until next weekend, so don't be surprised if I don't respond to messages before then. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
