Re: [Python-Dev] Generalised String Coercion
Guido van Rossum wrote: > The main problem for a smooth Unicode transition remains I/O, in my > opinion; I'd like to see a PEP describing a way to attach an encoding > to text files, and a way to decide on a default encoding for stdin, > stdout, stderr. FWIW, I've already drafted a patch for the former. It lets you write to file.encoding and honors this when writing Unicode strings to it. http://www.python.org/sf/1214889 Reinhold -- Mail address is perfectly valid! ___ 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] Major revision of PEP 348 committed
VMError -- This is a new intermediate grouping so it won't break anything and it does bring together two exceptions relating them by source. However, I recommend against introducing this new group. Besides added yet another thing to remember, it violates Flat-Is-Better-Than-Nested (see FIBTN below). Also, the new group is short on use cases with MemoryErrors sometimes being recoverable and SystemErrors generally not. In the library, only cookielib catches these and it does so along with KeyboardInterrupt in order to re-raise. In general, you don't want to introduce a new grouping unless there is some recurring need to catch that group. EOFError -- I recommend leaving this one alone. IOError is generally for real errors while EOF occurs in the normal course of reading a file or filelike source. The former is hard to recover and the latter is normal. The PEP's justification of "Since an EOF comes from I/O it only makes sense that it be considered an I/O error" is somewhat shallow and doesn't reflect thought about how those exceptions are actually used. That information is readily attainable by scanning the standard library with 57 instances of EOFError and 150 instances of IOError. There are a few cases of overlap where an except clause catches both; however, the two are mostly used independent from one another. The review of the library gives a good indication of how much code would be broken by this change. Also, see the FIBTN comment below. AnyDeprecationWarning -- This grouping makes some sense intuitively but do we have much real code that has had occasion to catch both at the same time? If not, then we don't need this. FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra significance for the exception hierarchy. The core issue is that exceptions are NOT inherently tree-structured. Each may ultimately carry its own set of meaningful attributes and those tend to not neatly roll-up into a parent/subclass relationships without Liskov violations. Likewise, it is a mistake to introduce nesting as a means of categorization. The problem is that many conflicting, though meaningful groupings are possible. (i.e. grouped by source (vm, user, data, system), grouped by recoverability or transience, grouped by module/container type (dictionary errors, weakref errors, net errors, warnings module, xml module, email errors), etc.) The ONLY useful nestings are those for a cluster of exceptions that are typically all handled together. IOW, any new nesting needs to be justified by a long list of real code examples that currently catch all those exceptions at the same time. Ideally, searching for that list would also turn-up no competing instances where other, orthogonal groupings are being used. Vocabulary size -- At one time, python-dev exhibited a strong reluctance to introduce any new builtins. No matter how sensible the idea, there was typically an immediate effort to jam the proposed function into some other namespace. It should be remembered that each of PEP 348's proposed new exception groupings ARE new builtins. Therefore, the bar for admission should be relatively high (i.e. I would prefer Fredrik's join() proposal to any of the above new proposals). Every new word in the vocabulary makes the language a little more complex, a little less likely to fit in your brain, and a little harder to learn. Nestings make this more acute since learning the new word also entails remembering how it fits in the structure (yet another good reason for FIBTN). Once again, my advice is not introduce change unless it is solving a specific, real problem in existing code. The groupings listed above feel like random ideas searching for a justification rather than the product of an effort to solve known issues. 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. Try to avoid reversing the process, staring at the existing tree, and letting your mind arbitrarily impose patterns on it. 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] Major revision of PEP 348 committed
Raymond Hettinger wrote: > FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra > significance for the exception hierarchy. The core issue is that > exceptions are NOT inherently tree-structured. Each may ultimately > carry its own set of meaningful attributes and those tend to not neatly > roll-up into a parent/subclass relationships without Liskov violations. I think this is a key point, because a Python except clause makes it easy to create an on-the-fly exception grouping, but it is more awkward to get rid of inheritance that is incorrect (you have to catch and reraise the ones you don't want handled before the real handler). I think Raymond gives a good suggestion - new groupings should only be introduced for exceptions where we have reasonable evidence that they are already frequently caught together. TerminalException is a good example of this. "except (KeyboardInterrupt, SystemExit): raise" is something that should be written often - there is a definite use case for catching them together. Those two are also examples of inappropriate inheritance causing obvious usability problems. Cheers, Nick. P.S. Are there any other hardware control people around to understand what I mean when I say that python-dev discussions sometimes remind me of a poorly tuned PID loop? Particularly the with statement discussion and this one. . . -- 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] Major revision of PEP 348 committed
Brett Cannon wrote:
> * SystemExit are the KeyboardInterrupt are the only exceptions *not*
> inheriting from Exception
> + CriticalException has been renamed TerminalException so it is
> more inline with the idea that the exceptions are meant to terminate
> the interpreter, not that they are more critical than other exceptions
I like TerminalException, although TerminatingException may be less ambiguous.
("There's nothing wrong with my terminal, you moronic machine!")
> This version addresses everyone's worries about
> backwards-compatibility or changes that were not substantive enough to
> break code.
Well, I think you said from the start that the forces of
backwards-compatibility would get you eventually ;)
> The things I did on my own without thorough discussion is remove
> ControlFlowException and introduce VMError.
+1 on the former.
-1 on the latter.
Same reasons as Raymond, basically. These exceptions are builtins, so let's
not add new ones without a strong use case.
Anyway, this is starting to look pretty good (but then, I thought that a few
days ago, too).
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] Generalised String Coercion
Guido van Rossum wrote: > The main problem for a smooth Unicode transition remains I/O, in my > opinion; I'd like to see a PEP describing a way to attach an encoding > to text files, and a way to decide on a default encoding for stdin, > stdout, stderr. If stdin, stdout and stderr go to a terminal, there already is a default encoding (actually, there always is a default encoding on these, as it falls back to the system encoding if its not a terminal, or if the terminal's encoding is not supported or cannot be determined). 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] Generalised String Coercion
Reinhold Birkenfeld wrote: > FWIW, I've already drafted a patch for the former. It lets you write to > file.encoding and honors this when writing Unicode strings to it. I don't like that approach. You shouldn't be allowed to change the encoding mid-stream (except perhaps under very specific circumstances). As I see it, the buffer of an encoded file becomes split, atleast for input: there are bytes which have been read and not yet decoded, and there are characters which have been decoded but not yet consumed. If you change the encoding mid-stream, you would have to undo decoding that was already done, resetting the stream to the real "current" position. For output, the situation is similar: before changing to a new encoding, or before changing from unicode output to byte output, you have to flush then codec first: it may be that the codec has buffered some state which needs to be completely processed first before a new codec can be applied to the stream. Another issue is seeking: given the many different kinds of buffers, seeking becomes fairly complex. Ideally, seeking should apply to application-level positions, ie. if when you tell the current position, it should be in terms of data already consumed by the application. Perhaps seeking in an encoded stream should not be supported at all. Finally, you also have to consider Universal Newlines: you can apply them either on the byte stream, or on the character stream. I think conceptually right would be to do universal newlines on the character stream. 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] Generalised String Coercion
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 allowed to return a Unicode string?
The problem here is that strings and Unicode are used in different
ways, whereas integers and longs are very similar. Strings are used
for both arbitrary data and text data, Unicode can only be used
for text data.
The new text() built-in would help make a clear distinction
between "convert this object to a string of bytes" and
"please convert this to a text representation". We need to
start making the separation somewhere and I think this is
a good non-invasive start.
Furthermore, the text() built-in could be used to only
allow 8-bit strings with ASCII content to pass through
and require that all non-ASCII content be returned as
Unicode.
We wouldn't be able to enforce this in str().
I'm +1 on adding text().
I would also like to suggest a new formatting marker '%t'
to have the same semantics as text() - instead of changing
the semantics of %s as the Neil suggests in the PEP. Again,
the reason is to make the difference between text and
arbitrary data explicit and visible in the code.
> The main problem for a smooth Unicode transition remains I/O, in my
> opinion; I'd like to see a PEP describing a way to attach an encoding
> to text files, and a way to decide on a default encoding for stdin,
> stdout, stderr.
Hmm, not sure why you need PEPs for this:
Open an encoded file:
-
Use codecs.open() instead of open() or file().
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
(encode, decode, streamreader, streamwriter) = codecs.lookup(encoding)
# Wrap using stream writers and readers
sys.stdin = streamreader(sys.stdin)
sys.stdout = streamwriter(sys.stdout)
sys.stderr = streamwriter(sys.stderr)
# Add .encoding attribute for introspection
sys.stdin.encoding = encoding
sys.stdout.encoding = encoding
sys.stderr.encoding = encoding
set_sys_std_encoding('rot-13')
Example session:
>>> print 'hello'
uryyb
>>> raw_input()
hello
h'hello'
>>> 1/0
Genpronpx (zbfg erprag pnyy ynfg):
Svyr "", yvar 1, va ?
MrebQvivfvbaReebe: vagrtre qvivfvba be zbqhyb ol mreb
Note that the interactive session bypasses the sys.stdin
redirection, which is why you can still enter Python
commands in ASCII - not sure whether there's a reason
for this, or whether it's just a missing feature.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 07 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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: Migrating the Python CVS to Subversion
M.-A. Lemburg wrote: > BTW, in one of your replies I read that you had a problem with > how cvs2svn handles trunk, branches and tags. In reality, this > is no problem at all, since Subversion is very good at handling > moves within the repository: you can easily change the repository > layout after the import to whatevery layout you see fit - without > losing any of the version history. Yes, however, I recall that some clients have problems with displaying history across renames (in particular, I believe viewcvs has this problem); also, it becomes difficult to refer to an old version by path name, since the old versions had all different path names. Jim Fulton has suggested a different approach: cvs2svn can create a dump file, and svnadmin load accepts a parent directory. Then, no renames are necessary. 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: Migrating the Python CVS to Subversion
Phillip J. Eby wrote: > Yeah, in my use of SVN I find that this is more theoretical than actual > for certain use cases. You can see the history of a file including the > history of any file it was copied from. However, if you want to try to > look at the whole layout, you can't easily get to the old locations. > This can be a royal pain, whereas at least in CVS you can use viewcvs to > show you the "attic". Subversion doesn't have an attic, which makes > looking at structural history very difficult. I guess this is a client issue also; in websvn, you can browse an older revision to see what the structure looked at that point. If you made tags, you can also browse the tags through the standard HTTP interface. I don't know a client, off-hand, which would answer the question "which files have been moved since tag xyz?". 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: Migrating the Python CVS to Subversion
Jeff Rush wrote: > BTW, re SSH access on python.org, using Apache's SSL support re https would > provide as good of security without the risk of giving out shell accounts. > SSL would encrypt the link and require a password or permit cert auth > instead, same as SSH. Cert admin needn't be hard if only a single server > cert is used, with client passwords, instead of client certs. That is the currently-proposed setup. However, with the current subversion clients, you will have to save your password to disk, or type it in every time. This is the real security disk: if somebody attacks the client machine, they get access to the python source repository. 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: Migrating the Python CVS to Subversion
Fernando Perez wrote: > I know Joe was in contact with the SVN devs to work on this, so perhaps he's > using a patched version of cvs2svn, I simply don't know. But I mention it in > case it proves useful to the python.org conversion. Thanks for the pointer. It turns out that I could resolve all my conversion problems myself (following Jim Fulton's suggestion of creating dump files). I found that somebody created a patch to support different structures in cvs2svn directly, but these patches have not been integrated yet. 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
[Python-Dev] PEP 347: Migration to Subversion
I have placed a new version of the PEP on http://www.python.org/peps/pep-0347.html Changes to the previous version include: - add more rationale for using svn (atomic changesets, fast tags and branches) - changed conversion procedure to a single repository, with some reorganization. See http://www.dcl.hpi.uni-potsdam.de/pysvn/ My proposal is that the repository is called http://svn.python.org/projects - add discussion section (Nick Bastin's proposal of hosting a Perforce repository, single vs. multiple repositories, user authentication, admin overhead and alternative hosters) - require python-cvsroot to be preserved forever. Please let me know what else I should change in the PEP. 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: Migrating the Python CVS to Subversion
Donovan Baarda wrote: > Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge > properly. All the other cool stuff like renames etc is kinda undone by > that. For a definition of properly, see; > > http://prcs.sourceforge.net/merge.html Can you please elaborate? I read the page, and it seems to me that subversion's merge command works exactly the way described on the page. 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: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>BTW, in one of your replies I read that you had a problem with >>how cvs2svn handles trunk, branches and tags. In reality, this >>is no problem at all, since Subversion is very good at handling >>moves within the repository: you can easily change the repository >>layout after the import to whatevery layout you see fit - without >>losing any of the version history. > > > Yes, however, I recall that some clients have problems with displaying > history across renames (in particular, I believe viewcvs has this > problem); also, it becomes difficult to refer to an old version by > path name, since the old versions had all different path names. Since I only use trac to view the source code (which doesn't have this problem), I can't comment on this. > Jim Fulton has suggested a different approach: cvs2svn can create > a dump file, and svnadmin load accepts a parent directory. Then, > no renames are necessary. Good idea. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 07 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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 8: exception style
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> PEP 8 doesn't express any preference between the
>> two forms of raise statements:
>> raise ValueError, 'blah'
>> raise ValueError("blah")
>>
>> I like the second form better, because if the exception arguments are
>> long or include string formatting, you don't need to use line
>> continuation characters because of the containing parens. Grepping
>> through the library code, the first form is in the majority, used
>> roughly 60% of the time.
>>
>> Should PEP 8 take a position on this? If yes, which one?
>
> Definitely ValueError('blah'). The other form will go away in Python
> 3000. Please update the PEP.
How do you then supply a traceback to the raise statement?
Cheers,
mwh
--
please realize that the Common Lisp community is more than 40
years old. collectively, the community has already been where
every clueless newbie will be going for the next three years.
so relax, please. -- Erik Naggum, comp.lang.lisp
___
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 8: exception style
> How do you then supply a traceback to the raise statement?
raise ValueError, ValueError("blah"), tb
Maybe in Py3K this could become
raise ValueError("bloop"), tb
--
--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] [ python-Patches-790710 ] breakpoint command listsinpdb
Michiel De Hoon wrote: > Speaking of the five-patch-review-rule, about two months ago I reviewed five > patches and posted a summary here in order to push patch #1049855. This patch > is still waiting for a verdict (this is also my own fault, since I needed > several iterations to get this patch straightened out; my apologies for > that). Is there anything else I can do for this patch? Sorry, I missed that message. I now reviewed the patch, but at the moment, I see little chance that the suggested feature is implementable, except by using code that is specific to each stdio implementation. 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 8: exception style
> > How do you then supply a traceback to the raise statement?
>
> raise ValueError, ValueError("blah"), tb
>
> Maybe in Py3K this could become
>
> raise ValueError("bloop"), tb
The instantiation and bindings need to be done in one step without
mixing two syntaxes. Treat this case the same as everything else:
raise ValueError("blip", traceback=tb)
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
[Python-Dev] pdb: should next command be extended?
Problem: When the code contains list comprehensions (or for that matter any other looping construct), the only way to get quickly through this code in pdb is to set a temporary breakpoint on the line after the loop, which is inconvenient.. There is a SF bug report #1248119 about this behavior. 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, i.e "next 5" would mean stop when line>=line_where_next_N_happened+5 is reached. This would allow to easily get over/out of loops in the debugger What do you think? Ilya ___ 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] [C++-sig] GCC version compatibility
Anthony Baxter wrote: > I should probably add that I'm not flagging that I think there's a problem > here. I'm mostly urging caution - I hate having to cut brown-paper-bag > releases . If possible, can the folks on c++-sig try this patch > out and put their results in the patch discussion? If you're keen, you > could try jumping onto HP's testdrive systems (http://www.testdrive.hp.com/). >>From what I recall, they have a bunch of systems with non-gcc C++ compilers, > including the DEC^WDigital^Compaq^WHP one on the alphas, and the HP C++ > compiler on the HP/UX boxes[1]. I've looked at the patch, and it looks fairly safe, so I committed it. 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] pdb: should next command be extended?
Ilya Sandler wrote: > 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, [...] > What do you think? That would differ from gdb's "next ", which does "next" n times. It would be confusing if pdb accepted the same command, but it meant something different. Plus, there is always a chance that +n is never reached, which would also be confusing. So I'm -1 here. 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: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > Donovan Baarda wrote: > >>Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge >>properly. All the other cool stuff like renames etc is kinda undone by >>that. For a definition of properly, see; >> >>http://prcs.sourceforge.net/merge.html > > > Can you please elaborate? I read the page, and it seems to me that > subversion's merge command works exactly the way described on the > page. maybe it's changed since I last looked at it, but last time I looked SVN didn't track merge histories. From the svnbook; "Unfortunately, Subversion is not such a system. Like CVS, Subversion 1.0 does not yet record any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files." What this means is SVN has no way of automatically identifying the common version. An svn merge requires you to manually identify and specify the "last common point" where the branch was created or last merged. PRCS automatically finds the common version from the branch/merge history, and even remembers the merge/replace/nothing/delete decision you make for each file as the default to use for future merges. You can see this in the command line differences. For subversion; # create and checkout branch my-calc-branch $ svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Creating a private branch of /calc/trunk." $ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch # merge and commit changes from trunk $ svn merge -r 341:HEAD http://svn.example.com/repos/calc/trunk $ svn commit -m "Merged trunc changes to my-calc-branch." # merge and commit more changes from trunk $ svn merge -r 345:HEAD http://svn.example.com/repos/calc/trunk $ svn commit -m "Merged trunc changes to my-calc-branch." Note that 341 and 345 are "magic" version numbers which correspond to the trunc version at the time of branch and first merge respectively. It is up to the user to figure out these versions using either meticulous use of tags or svn logs. In PRCS; # create and checkout branch my-calc-branch $ prcs checkout calc -r 0 $ prcs checkin -r my-calc-branch -m "Creating my-calc-branch" # merge and commit changes from trunk $ prcs merge -r 0 $ prcs checkin -m " merged changes from trunk" # merge and commit more changes from trunk $ prcs merge -r 0 $ prcs checkin -m " merged changes from trunk" Note that "-R 0" means "HEAD of trunk branch", and "-r my-calc-branch" means "HEAD of my-calc-branch". There is no need to figure out what versions of those branches to use as the "changes from" point, because PRCS figures it out for you. Not only that, but if you chose to ignore changes in certain files during the first merge, the second merge will remember that as the default action for the second merge. -- Donovan Baarda ___ 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] pdb: should next command be extended?
On Sun, 7 Aug 2005, [ISO-8859-1] "Martin v. L?wis" wrote: > Ilya Sandler wrote: > > 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, > [...] > > What do you think? > > That would differ from gdb's "next ", which does "next" n times. > It would be confusing if pdb accepted the same command, but it > meant something different. But as far as I can tell, pdb's next is already different from gdb's next! gdb's next seem to always go to the different source line, while pdb's next may stay on the current line. The problem with "next " meaning "repeat next n times" is that it seems to be less useful that the original suggestion. Any alternative suggestions to allow to step over list comprehensions and such? (SF 1248119) > Plus, there is always a chance that > +n is never reached, which would also be confusing. That should not be a problem, returning from the current frame should be treated as a stopping condition (similarly to the current "next" behaviour)... Ilya > So I'm -1 here. > > 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: Migrating the Python CVS to Subversion
Donovan Baarda wrote: > What this means is SVN has no way of automatically identifying the > common version. Ah, ok. That's true. It doesn't mean you can't do proper merging with subversion - it only means that it is harder, as you need to figure out the revision range that you want to merge. If this is too painful, you can probably use subversion to store the relevant information. For example, you could define a custom property on the directory, last_merge_from_trunk, which you would always update after you have done a merge operation. Then you don't have to look through history to find out when you last merged. 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 8: exception style
> > Maybe in Py3K this could become
> >
> > raise ValueError("bloop"), tb
>
> The instantiation and bindings need to be done in one step without
> mixing two syntaxes. Treat this case the same as everything else:
>
> raise ValueError("blip", traceback=tb)
That requires PEP 344. I have some vague feeling that the way we build
up the traceback by linking backwards, this may not necessarily work
right. I guess somebody has to try to implement PEP 344 in order to
find out.
(In fact, I think trying to implement PEP 344 would be an *excellent*
way to validate it.)
--
--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] Generalised String Coercion
[me] > > a way to decide on a default encoding for stdin, > > stdout, stderr. [Martin] > If stdin, stdout and stderr go to a terminal, there already is a > default encoding (actually, there always is a default encoding on > these, as it falls back to the system encoding if its not a terminal, > or if the terminal's encoding is not supported or cannot be determined). So there is. Wow! I never kew this. How does it work? Can we use this for writing to files to? -- --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] Generalised String Coercion
[Reinhold Birkenfeld] > > FWIW, I've already drafted a patch for the former. It lets you write to > > file.encoding and honors this when writing Unicode strings to it. [Martin v L] > I don't like that approach. You shouldn't be allowed to change the > encoding mid-stream (except perhaps under very specific circumstances). Right. IMO the encoding is something you specify when opening the file, just like buffer size and text mode. > Another issue is seeking: given the many different kinds of buffers, > seeking becomes fairly complex. Ideally, seeking should apply to > application-level positions, ie. if when you tell the current position, > it should be in terms of data already consumed by the application. > Perhaps seeking in an encoded stream should not be supported at all. I'm not sure if it works for all encodings, but if possible I'd like to extend the seeking semantics on text files: seek positions are byte counts, and the application should consider them as "magic cookies". > Finally, you also have to consider Universal Newlines: you can apply > them either on the byte stream, or on the character stream. I think > conceptually right would be to do universal newlines on the character > stream. Is there any reason not to do Universal Newline processing on *all* text files? I can't think of a use case where you'd like text file processing but you want to see the bare \r characters. -- --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] Generalised String Coercion
[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?
[MAL]
> The problem here is that strings and Unicode are used in different
> ways, whereas integers and longs are very similar. Strings are used
> for both arbitrary data and text data, Unicode can only be used
> for text data.
Yes, that is the case in Python 2.x. In Python 3.x, I'd like to use a
separate "bytes" array type for non-text and for encoded text data,
just like Java; strings should always be considered text data.
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.
Perhaps a better API would be a new file-open mode ("B"?) to indicate
that a file's read* operations should return bytes instead of strings.
The bytes type could just be a very thin wrapper around array('b').
> The new text() built-in would help make a clear distinction
> between "convert this object to a string of bytes" and
> "please convert this to a text representation". We need to
> start making the separation somewhere and I think this is
> a good non-invasive start.
I agree with the latter, but I would prefer that any new APIs we use
use a 'bytes' data type to represent non-text data, rather than having
two different sets of APIs to differentiate between the use of 8-bit
strings as text vs. data -- while we *currently* use 8-bit strings for
both text and data, in Python 3.0 we won't, so then the interim APIs
would have to change again. I'd rather intrduce a new data type and
new APIs that work with it.
> Furthermore, the text() built-in could be used to only
> allow 8-bit strings with ASCII content to pass through
> and require that all non-ASCII content be returned as
> Unicode.
>
> We wouldn't be able to enforce this in str().
>
> I'm +1 on adding text().
I'm still -1.
> I would also like to suggest a new formatting marker '%t'
> to have the same semantics as text() - instead of changing
> the semantics of %s as the Neil suggests in the PEP. Again,
> the reason is to make the difference between text and
> arbitrary data explicit and visible in the code.
Hm. What would be the use case for using %s with binary, non-text data?
> > The main problem for a smooth Unicode transition remains I/O, in my
> > opinion; I'd like to see a PEP describing a way to attach an encoding
> > to text files, and a way to decide on a default encoding for stdin,
> > stdout, stderr.
>
> Hmm, not sure why you need PEPs for this:
I'd forgotten how far we've come. I'm still unsure how the default
encoding on stdin/stdout works.
But it still needs to be simpler; IMO the built-in open() function
should have an encoding keyword. (But it could return something whose
type is not 'file' -- once again making a distinction between open and
file.) Do these files support universal newlines? IMO they should.
--
--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: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > Donovan Baarda wrote: >>What this means is SVN has no way of automatically identifying the >>common version. > If this is too painful, you can probably use subversion to store > the relevant information. For example, you could define a custom > property on the directory A script named "svnmerge" that does just that is included in the contrib directory of the Subversion tar. We (ZC) have just started using it to track two-way merge operations, but I don't have much experience with it personally yet. -- Benji York ___ 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: Migrating the Python CVS to Subversion
On 8/4/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Nicholas Bastin wrote: > > Perforce is a commercial product, but it can be had for free for > > verified Open Source projects, which Python shouldn't have any problem > > with. There are other problems, like you have to renew the agreement > > every year, but it might be worth considering, given the fact that > > it's an excellent system. > > So we should consider it because it is an excellent system... I don't > know what that means, in precise, day-to-day usage terms (i.e. what > precisely would it do for us that, say, Subversion can't do). It's a mature product. I would hope that that would count for something. I've had enough corrupted subversion repositories that I'm not crazy about the thought of using it in a production system. I know I'm not the only person with this experience. Sure, you can keep backups, and not really lose any work, but we're moving over because we have uptime and availability problems, so lets not just create them again. > >>I think anything but Subversion is ruled out because: > >>- there is no offer to host that anywhere (for subversion, there is > >> already svn.python.org) > > > > > > We could host a Perforce repository just as easily, I would think. > > Interesting offer. I'll add this to the PEP - who is "we" in this > context? Uh, the Python community. Which is currently hosting a subversion repository, so it doesn't seem like a stretch to imagine that p4.python.org could exist just as easily. > >>- there is no support for converting a CVS repository (for subversion, > >> there is cvs2svn) > > > > > > I'd put $20 on the fact that cvs2svn will *not* work out of the box > > for converting the python repository. Just call it a hunch. > > You could have read the PEP before losing that money :-) It did work > out of the box. Pardon me if I don't feel that I'd like to see a system in production for a few weeks before we declare victory. The problems with this kind of conversion can be very subtle, and very painful. I'm not saying we shouldn't do this, I'm just saying that we should take an appropriate measure of how much greener the grass really is on the other side, and how much work we're willing to put in to make it that way. -- Nick ___ 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] Major revision of PEP 348 committed
On 8/7/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > VMError -- This is a new intermediate grouping so it won't break > anything and it does bring together two exceptions relating them by > source. However, I recommend against introducing this new group. > Besides added yet another thing to remember, it violates > Flat-Is-Better-Than-Nested (see FIBTN below). Also, the new group is > short on use cases with MemoryErrors sometimes being recoverable and > SystemErrors generally not. In the library, only cookielib catches > these and it does so along with KeyboardInterrupt in order to re-raise. > In general, you don't want to introduce a new grouping unless there is > some recurring need to catch that group. > And Nick didn't like it either. Unless someone speaks up Monday, you can consider it removed. > EOFError -- I recommend leaving this one alone. IOError is generally > for real errors while EOF occurs in the normal course of reading a file > or filelike source. The former is hard to recover and the latter is > normal. The PEP's justification of "Since an EOF comes from I/O it only > makes sense that it be considered an I/O error" is somewhat shallow and > doesn't reflect thought about how those exceptions are actually used. > That information is readily attainable by scanning the standard library > with 57 instances of EOFError and 150 instances of IOError. There are a > few cases of overlap where an except clause catches both; however, the > two are mostly used independent from one another. The review of the > library gives a good indication of how much code would be broken by this > change. Also, see the FIBTN comment below. > Basically you are arguing that EOFError is practically not an error and more of an exception signaling an event, like StopIteration for file reading. That makes sense, although it does suggest the name breaks the naming scheme Guido suggested. But I am not crazy enough to try to suggest a name change at this point. =) > AnyDeprecationWarning -- This grouping makes some sense intuitively but > do we have much real code that has had occasion to catch both at the > same time? If not, then we don't need this. > Well, PendingDeprecationWarning is barely used in Lib/ it seems. That would suggest the grouping isn't worth it just because the need to catch it will be miniscule. That also kills the argument that it would simplify warnings filters by cutting down on needing another registration since the chance of that happening seems to be microscopic. > FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra > significance for the exception hierarchy. The core issue is that > exceptions are NOT inherently tree-structured. Each may ultimately > carry its own set of meaningful attributes and those tend to not neatly > roll-up into a parent/subclass relationships without Liskov violations. > [SNIP] > > Vocabulary size -- At one time, python-dev exhibited a strong reluctance > to introduce any new builtins. No matter how sensible the idea, there > was typically an immediate effort to jam the proposed function into some > other namespace. It should be remembered that each of PEP 348's > proposed new exception groupings ARE new builtins. Therefore, the bar > for admission should be relatively high (i.e. I would prefer Fredrik's > join() proposal to any of the above new proposals). Every new word in > the vocabulary makes the language a little more complex, a little less > likely to fit in your brain, and a little harder to learn. Nestings > make this more acute since learning the new word also entails > remembering how it fits in the structure (yet another good reason for > FIBTN). > Now those are two arguments I can go with. OK, so your points make sense. I will wait until Monday evening after work to make any changes to give people a chance to argue against them, but VMError and AnyDeprecationWarning can be considered removed and EOFError will be moved to inherit from EnvironmentError again. Luckily you didn't say you hated TerminalException. =) -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] Major revision of PEP 348 committed
On 8/7/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > * SystemExit are the KeyboardInterrupt are the only exceptions *not*
> > inheriting from Exception
> > + CriticalException has been renamed TerminalException so it is
> > more inline with the idea that the exceptions are meant to terminate
> > the interpreter, not that they are more critical than other exceptions
>
> I like TerminalException, although TerminatingException may be less ambiguous.
> ("There's nothing wrong with my terminal, you moronic machine!")
>
Maybe. But the interpreter is not terminating quite yet; state is
still fine since the exceptions have not reached the top of the stack
if you caught it. But then "terminal" sounds destined to die, which
is not true either since that only occurs if you catch the exceptions;
"terminating" portrays that the plan is the termination but that it is
not definite.
OK, TerminatingException it is.
> > This version addresses everyone's worries about
> > backwards-compatibility or changes that were not substantive enough to
> > break code.
>
> Well, I think you said from the start that the forces of
> backwards-compatibility would get you eventually ;)
>
=) I should become a pundit for being able to tell what is going to happen.
> > The things I did on my own without thorough discussion is remove
> > ControlFlowException and introduce VMError.
>
> +1 on the former.
> -1 on the latter.
>
> Same reasons as Raymond, basically. These exceptions are builtins, so let's
> not add new ones without a strong use case.
>
> Anyway, this is starting to look pretty good (but then, I thought that a few
> days ago, too).
>
Yeah, and so did everyone else basically. While Guido has his "let's
get all excited about a crazy idea, but then scale it back" mentality,
I guess I have the "let's change everything for the better, but then
realize other people actually use this language too". =)
-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] PyTuple_Pack added references undocumented
According to the source code, PyTuple_Pack returns a new reference (it calls PyTuple_New). It also Py_INCREF's all the objects in the new tuple. Is this unusual behavior? None of these added references are documented in the API Reference Manual. ___ 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 347: Migration to Subversion
On 8/7/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I have placed a new version of the PEP on > > http://www.python.org/peps/pep-0347.html > > Changes to the previous version include: > > - add more rationale for using svn (atomic changesets, > fast tags and branches) > > - changed conversion procedure to a single repository, with > some reorganization. See > > http://www.dcl.hpi.uni-potsdam.de/pysvn/ > What is going in under python/ ? If it is what is currently /dist/src/, then great and the renaming of the repository works. But if that is what src/ is going to be used for, then what is python/ for and it would be nice to have a repository name that more directly reflects that it is the Python source tree. And I assume you are going to list the directory structure in the PEP at some point. -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] PyTuple_Pack added references undocumented
On 8/7/05, Edward C. Jones <[EMAIL PROTECTED]> wrote: > According to the source code, PyTuple_Pack returns a new reference (it > calls PyTuple_New). It also Py_INCREF's all the objects in the new > tuple. Is this unusual behavior? None of these added references are > documented in the API Reference Manual. This seems the only sensible behavior given what it does. I think the INCREFs don't need to be documented because you don't have to worry about them -- they follow the normal pattern of reference counts: if you owned an object before passing it to PyTuple_Pack(), you still own it afterwards. The docs say that it returns a new object, so that's in order too. It's not listed in refcounts.dat; that seems an omission (or perhaps the function's varargs signature doesn't fit in the pattern?). -- --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] PyTuple_Pack added references undocumented
> According to the source code, PyTuple_Pack returns a new reference (it > calls PyTuple_New). It also Py_INCREF's all the objects in the new > tuple. Is this unusual behavior? No. That is how containers work. Look at PyBuild_Value() for comparison. > None of these added references are documented in the API Reference Manual. The docs seem clear to me. If the docs don't meet your needs, submit a patch. ___ 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] Generalised String Coercion
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 what the C API would be? It seems to me that PyObject_Str cannot start returning a unicode object without a lot of code breakage. I suppose we could introduce a function called something like PyObject_String. Neil ___ 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] Generalised String Coercion
At 05:24 PM 8/7/2005 -0700, Guido van Rossum 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 there's a
subtlety I've missed here.
___
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: Migrating the Python CVS to Subversion
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote: > I've had enough corrupted subversion repositories that I'm > not crazy about the thought of using it in a production system. I > know I'm not the only person with this experience. Sure, you can keep > backups, and not really lose any work, but we're moving over because > we have uptime and availability problems, so lets not just create them > again. Has anyone experienced svn corruptions with the fsfs backend? I haven't, across quite a few repositories. > Uh, the Python community. Which is currently hosting a subversion > repository, so it doesn't seem like a stretch to imagine that > p4.python.org could exist just as easily. Unfortunately, I don't think "we" (meaning specifically the collective python.org admins) have much if any operational experience with Perforce. We do with Subversion though and that's a big plus. If "we" were to host a Perforce repository, we'd need significant commitments from several somebodies to get things set up, keep it running, and help socialize long-term institutional knowledge amongst the other admins. 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. -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] PyTuple_Pack added references undocumented
On Sunday 07 August 2005 22:14, Guido van Rossum wrote: > I think the INCREFs don't need to be documented because you don't have > to worry about them -- they follow the normal pattern of reference > counts: if you owned an object before passing it to PyTuple_Pack(), > you still own it afterwards. That's right; the function doesn't affect the references you hold in any way, so there's no need to deal with them. > It's not listed in refcounts.dat; that seems an omission (or perhaps > the function's varargs signature doesn't fit in the pattern?). It should and can be listed. refcounts.dat won't deal with the varargs portion of the signature, but it can deal with the return value and normal arguments without worrying about varargs portions of the signature for any function. -Fred -- Fred L. Drake, Jr. ___ 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] Generalised String Coercion
Guido van Rossum wrote: >>If stdin, stdout and stderr go to a terminal, there already is a >>default encoding (actually, there always is a default encoding on >>these, as it falls back to the system encoding if its not a terminal, >>or if the terminal's encoding is not supported or cannot be determined). > > > So there is. Wow! I never kew this. How does it work? Can we use this > for writing to files to? On Unix, it uses nl_langinfo(CHARSET), which in turn looks at the environment variables. On Windows, it uses GetConsoleCP()/GetConsoleOutputCP(). On Mac, I'm still searching for a way to determine the encoding of Terminal.app. In IDLE, it uses locale.getpreferredencoding(). So no, this cannot easily be used for file output. Most likely, people would use locale.getpreferredencoding() for file output. For socket output, there should not be a standard way to encode Unicode. 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] Generalised String Coercion
On Aug 7, 2005, at 7:37 PM, Martin v. Löwis wrote: > Guido van Rossum wrote: > >>> If stdin, stdout and stderr go to a terminal, there already is a >>> default encoding (actually, there always is a default encoding on >>> these, as it falls back to the system encoding if its not a >>> terminal, >>> or if the terminal's encoding is not supported or cannot be >>> determined). >>> >> >> >> So there is. Wow! I never kew this. How does it work? Can we use this >> for writing to files to? >> > > On Unix, it uses nl_langinfo(CHARSET), which in turn looks at the > environment variables. > > On Windows, it uses GetConsoleCP()/GetConsoleOutputCP(). > > On Mac, I'm still searching for a way to determine the encoding of > Terminal.app. It's UTF-8 by default, I highly doubt many people bother to change it. -bob ___ 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] Generalised String Coercion
Guido van Rossum wrote: > I'm not sure if it works for all encodings, but if possible I'd like > to extend the seeking semantics on text files: seek positions are byte > counts, and the application should consider them as "magic cookies". If the seek position is merely a number, it won't work for all encodings. For the ISO 2022 ones (iso-2022-jp etc), you need to know the shift state: you can switch to a different encoding in the stream using standard escape codes, and then the same bytes are interpreted differently. For example, iso-2022-jp supports these escape codes: ESC ( B ASCII ESC $ @ JIS X 0208-1978 ESC $ B JIS X 0208-1983 ESC ( J JIS X 0201-Roman ESC $ A GB2312-1980 ESC $ ( C KSC5601-1987 ESC $ ( D JIS X 0212-1990 ESC . A ISO8859-1 ESC . F ISO8859-7 So at a certain position in the stream, the same bytes could mean different characters, depending on which "shift state" you are in. That's why ISO C introduced fgetpos/fsetpos in addition to ftell/fseek: an fpos_t is a truly opaque structure that can also incorporate codec state. If you follow this approach, you can get back most of seek; you will lose the "whence" parameter, i.e. you cannot seek forth and back, and you cannot position at the end of the file (actually, iso-2022-jp still supports appending to a file, since it requires that all data "shift out" back to ASCII at the end of each line, and at the end of the file. So "correct" ISO 2022 files can still be concatenated) > Is there any reason not to do Universal Newline processing on *all* > text files? Correct. However, this still might result in a full rewrite of the universal newlines code: the code currently operates on byte streams, when it "should" operate on character streams. In some encodings, CRLF simply isn't represented by \x0d\x0a (e.g. UTF-16-LE: \x0d\0\0x0a\0) 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: Migrating the Python CVS to Subversion
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 subversion 0.23. It has matured since then. Even then, invoking db_recover would restore the operation, without losing data (i.e. I did not need to go to backup). >>Interesting offer. I'll add this to the PEP - who is "we" in this >>context? > > > Uh, the Python community. Which is currently hosting a subversion > repository, so it doesn't seem like a stretch to imagine that > p4.python.org could exist just as easily. Ah. But these people have no expertise with Perforce, and there is no Debian Perforce package, so it *is* a stretch assuming that they could also host a perforce directory. So I should then remove your offer to host a perforce installation, as you never made such an offer, right? > Pardon me if I don't feel that I'd like to see a system in production > for a few weeks before we declare victory. The problems with this > kind of conversion can be very subtle, and very painful. I'm not > saying we shouldn't do this, I'm just saying that we should take an > appropriate measure of how much greener the grass really is on the > other side, and how much work we're willing to put in to make it that > way. Yes. That's what this PEP is for. So I guess you are -1 on the PEP. 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 347: Migration to Subversion
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 move nondist/src/Compiler, and drop nondist/src. > And I assume you are going to list the directory structure in the PEP > at some point. Please take a look at the PEP. 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
