Re: [Python-Dev] [Python-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings
Noam Raphael wrote: > Won't "svn propedit svn:ignore ." do the trick? It certainly would. Thanks for pointing that out. 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] Freezing the CVS on Oct 26 for SVN switchover
Tim> Excellent suggestions! I have a few to pass on: ... Tim, Thanks for the tips. As a new svn user myself, I find these helpful. These are precisely the things the Wiki would be good for. They don't prescribe policy. They help people in a general way to migrate from cvs to svn more easily. Anyone with cvs and svn experience, but without the ability to check stuff into the pydotorg repository could contribute. Skip ___ 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-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings
Fred> Shouldn't we simply remove the .cvsignore files? Subversion Fred> doesn't use them, so they'll just end up getting out of sync with Fred> the svn:ignore properties. Is there some equivalent? If so, can we convert the .cvsignore files before deleting them? Skip ___ 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] svn checksum error
I tried "svn up" to bring my sandbox up-to-date and got this output: % svn up UInclude/unicodeobject.h subversion/libsvn_wc/update_editor.c:1609: (apr_err=155017) svn: Checksum mismatch for 'Objects/.svn/text-base/unicodeobject.c.svn-base'; expected: '8611dc5f592e7cbc6070524a1437db9b', actual: '2d28838f2fec366fc58386728a48568e' What's that telling me? Thx, Skip ___ 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
Tim> Excellent suggestions! I have a few to pass on: skip> These are precisely the things the Wiki would be good for. I went ahead and used Tim's note as the basis for a page on the wiki: http://wiki.python.org/moin/CvsToSvn It's linked from the PythonDevelopers page (a page of previously dubious necessity). Skip ___ 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] svn checksum error
[EMAIL PROTECTED] wrote: > I tried "svn up" to bring my sandbox up-to-date and got this output: > > % svn up > UInclude/unicodeobject.h > subversion/libsvn_wc/update_editor.c:1609: (apr_err=155017) > svn: Checksum mismatch for > 'Objects/.svn/text-base/unicodeobject.c.svn-base'; expected: > '8611dc5f592e7cbc6070524a1437db9b', actual: '2d28838f2fec366fc58386728a48568e' > > What's that telling me? "welcome to the wonderful world of subversion error messages" (from what I can tell, the message means that SVN thinks that there might have been some checksum error somewhere, or some other error at a point where subversion thinks it's likely that a checksum was involved; to figure out what's really causing this problem, you probably need a debug build of subversion). deleting the offending directory and doing "svn up" is the easiest way to fix this. ___ 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] svn:ignore (Was: [Python-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings)
[EMAIL PROTECTED] wrote: > Fred> Shouldn't we simply remove the .cvsignore files? Subversion > Fred> doesn't use them, so they'll just end up getting out of sync with > Fred> the svn:ignore properties. > > Is there some equivalent? If so, can we convert the .cvsignore files before > deleting them? cvs2svn has already converted them automatically - to svn:ignore properties; try svn propget svn:ignore Doc (assuming . is the current directory). I have now deleted all .cvsignore files in the trunk in revision 41357 (yay, giving a single number for a multi-file delete operation feels good :-) 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] Freezing the CVS on Oct 26 for SVN switchover
[EMAIL PROTECTED] wrote: > I went ahead and used Tim's note as the basis for a page on the wiki: > > http://wiki.python.org/moin/CvsToSvn > > It's linked from the PythonDevelopers page (a page of previously dubious > necessity). I have pretty much the same reservations against Wikis as Brett does; it seems more productive if people would just use python-dev to ask questions of the "how do I" kind (and probably of the "do I really need to" kind as well). I don't mind somebody collecting this information into whatever place more permanent and accessible than a mailing list archive; I think I would normally add them to the developer FAQ instead of to the Wiki, primarily because I can memorize the location of the FAQ better. 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] svn checksum error
[EMAIL PROTECTED] wrote: > I tried "svn up" to bring my sandbox up-to-date and got this output: > > % svn up > UInclude/unicodeobject.h > subversion/libsvn_wc/update_editor.c:1609: (apr_err=155017) > svn: Checksum mismatch for > 'Objects/.svn/text-base/unicodeobject.c.svn-base'; expected: > '8611dc5f592e7cbc6070524a1437db9b', actual: '2d28838f2fec366fc58386728a48568e' > > What's that telling me? At the shallow level, the message should be clear: there is an actual checksum for a file and an expected checksum, and they differ. They shouldn't differ. Somewhat deeper, this indicates a bug in Subversion. It's not clear to me whether this is a client or a server bug. In the version on svn.python.org, the error message is on line 2846, so I would suspect it is a client bug. The natural question then is: what operating system, what subversion version are you using? 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] Parser and Runtime: Divorced!
On Oct 26, 2005, at 20:02, Evan Jones wrote: > In the process of doing this, I came across a comment mentioning that > it would be desirable to separate the parser. Is there any interest in > doing this? I now have a vague idea about how to do this. Of course, > there is no point in making changes like this unless there is some > tangible benefit. I am going to assume that since no one was excited about my post, that the answer is: no, there is no interest in seperating the parser from the rest of the Python run time. At any rate, if anyone is looking for a standalone C Python parser library, you can get it at the following URL. It includes a "print the tree" example that displays the AST for a specified file. It only supports a subset of the parse tree (assignment, functions, print, return), but it should be obvious how it could be extended. http://evanjones.ca/software/pyparser.html Evan Jones -- Evan Jones http://evanjones.ca/ ___ 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 351, the freeze protocol
Hello, It seems that we both agree that freezing is cool (-; . We disagree on whether a copy-on-write behaviour is desired. Your arguments agains copy-on-write are: 1. It's not needed. 2. It's complicated to implement. But first of all, you didn't like my use cases. I want to argue with that. > In reading your description of a 'table of values', I can't help but be > reminded of the wxPython (and wxWidget) wx.Grid and its semantics. It > offers arbitrary tables of values (whose editors and viewers you can > change at will), which offers a mechanism by which you can "listen" to > changes that occur to the contents of a cell. I can't help but think > that if you offered a protocol by which a user can signal that a cell > has been changed, perhaps by writing the value to the table itself > (table.SetValue(row, col, value)), every read a deepcopy (or a PEP 351 > freeze), etc., that both you and the users of your table would be much > happier. Perhaps I didn't make it clear. The difference between wxPython's Grid and my table is that in the table, most values are *computed*. This means that there's no point in changing the values themselves. They are also used frequently as set members (I can describe why, but it's a bit complicated.) I want to say that even if sets weren't used, the objects in the table should have been frozen. The fact the sets (and dicts) only allow immutable objects as members/keys is just for protecting the user. They could have declared, "you shouldn't change anything you insert - as long as you don't, we'll function properly." The only reason why you can't compute hash values of mutable objects is that you don't want your user to make mistakes, and make the data structure inconsistent. > As for the graph issue, you've got a bigger problem than users just > being able to edit edge lists, users can clear the entire dictionary of > vertices (outgoing.clear()). It seems to me that a more reasonable > method to handle this particular case is to tell your users "don't > modify the dictionaries or the edge lists", and/or store your edge lists > as tuples instead of lists or dictionaries, and/or use an immutable > dictionary (as offered by Barry in the PEP). As I wrote before, telling my users "don't modify the edge lists" is just like making lists hashable, and telling all Python users, "dont modify lists that are dictionary keys." There's no way to tell the users that - there's no convention for objects which should not be changed. You can write it in the documentation, but who'll bother looking there? I don't think that your other suggestions will work: the data structure of the graph itself can't be made of immutable objects, because of the fact that the graph is a mutable object - you can change it. It can be made of immutable objects, but this means copying all the data every time the graph changes. Now, about copy-on-write: > There's also this little issue of "copy on write" semantics with Python. > Anyone who tells you that "copy on write" is easy, is probably hanging > out with the same kind of people who say that "threading is easy". Of > course both are easy if you limit your uses to some small subset of > interesting interactions, but "copy on write" gets far harder when you > start thinking of dictionaries, lists, StringIOs, arrays, and all the > possible user-defined classes, which may be mutated beyond obj[key] = > value and/or obj.attr = value (some have obj.method() which mutates the > object). As such, offering a callback mechanism similar to weak > references is probably pretty close to impossible with CPython. Let's limit ourselves to copy-on-write of objects which do not contain nonfrozen objects. Perhaps it's enough - the table, the graph, and strings, are perfect examples of these. Implementation doesn't seem to complicated to me - whenever the object is about to change, and there is a connected frozen copy, you make a shallow copy of the object, point the frozen copy to it, release the reference to the frozen copy, and continue as usual. That's all. I really think that this kind of copy-on-write is "correct". The temporary freezing of sets in order to check if they are members of other sets is a not-very-nice way of implementing it. This kind of copy-on-write would allow, in principle, for Python strings to become mutable, with almost no speed penalty. It would allow my table, and other containers, to automatically freeze the objects that get into it, without having to trust the user on not changing the objects - and remember that there's no way of *telling* him not to change the objects. Now, the computer scientist in me wants to explain (and think about) freezing containers of nonfrozen objects. What I actually want is that as long as an object doesn't change after it's freezed, the cost of freezing would be nothing - that is, O(1). Think about a mutable string object, which is used in the same way as the current, immutable strings. It is constructed o
[Python-Dev] StreamHandler eating exceptions
The StreamHandler available under the logging package is currently
catching all exceptions under the emit() method call. In the
Handler.handleError() documentation it's mentioned that it's
implemented like that because users do not care about errors
in the logging system.
I'd like to apply the following patch:
Index: Lib/logging/__init__.py
===
--- Lib/logging/__init__.py (revision 41357)
+++ Lib/logging/__init__.py (working copy)
@@ -738,6 +738,8 @@
except UnicodeError:
self.stream.write(fs % msg.encode("UTF-8"))
self.flush()
+except KeyboardInterrupt:
+raise
except:
self.handleError(record)
Anyone against the change?
--
Gustavo Niemeyer
http://niemeyer.net
___
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 351, the freeze protocol
> It allows everything in Python to be both mutable and hashable, I don't understand, since it's already the case. Any user-defined object is at the same time mutable and hashable. And if you want the hash value to follow the changes in attribute values, just define an appropriate __hash__ method. Regards Antoine. ___ 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] svn checksum error
Martin> The natural question then is: what operating system, what Martin> subversion version are you using? Sorry, wasn't thinking in terms of svn bugs. I was anticipating some sort of obvious pilot error. I am on Mac OSX 10.3.9, running svn 1.1.3 I built from source back in the May timeframe. Should I upgrade to 1.2.3 as a matter of course? Fredrik> "welcome to the wonderful world of subversion error messages" ... Fredrik> deleting the offending directory and doing "svn up" is the Fredrik> easiest way to fix this. Thanks. I zapped Objects. The next svn up complained about Misc. The next about Lib. After that, the next svn up ran to completion. Skip ___ 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] svn checksum error
Le dimanche 30 octobre 2005 à 19:08 -0600, [EMAIL PROTECTED] a écrit : > Sorry, wasn't thinking in terms of svn bugs. I was anticipating some sort > of obvious pilot error. I am on Mac OSX 10.3.9, running svn 1.1.3 I built > from source back in the May timeframe. Should I upgrade to 1.2.3 as a > matter of course? IIRC, the version provided by Fink works fine. No need to compile manually. ___ 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 implicit conversions).
[Martin von Löwis] > My canonical example is François Pinard, who keeps requesting it, > saying that local people where surprised they couldn't use accented > characters in Python. Perhaps that's because he actually is Quebecian > :-) I presume I should comment a bit on this. People here are not "surprised" they couldn't use accented characters, they are rather saddened, and some hoped that Python would offer that possibility, one of these days. Also given that here, every production program or system has been progressively rewritten in Python, slowly at first, and more aggressively while the confidence was building up, to the point not much of the non-Python things remain by now. So, all our hopes are concentrated into a single language. All development is done in house by French people. All documentation, external or internal, comments, identifier and function names, everything is in French. Some of the developers here have had a long programming life, while they only barely read English. It is surely a constant frustration, for some of us, having to mangle identifiers by ravelling out their necessary diacritics. It does not look good, it does not smell good, and in many cases, mangling identifiers significantly decreases program legibility. Now, I keep reading strange arguments from people opposing that we use national letters in identifiers, disturbed by the fact they would have a hard time reading our code or publishing it. Even worse, some want to protect us (and the world) against ourselves, using made up, irrational arguments, producing false logic out of their own emotions and feelings. They would like us to think, write, and publish in English. Is it some anachronical colonialism? Quite possible. It surely has some success, as you may find some French people that will only swear in English! :-) For one, in my programming life, I surely chose to write a lot of English code, and I still think English is a good vehicle to planetary communication. However, I like it to my choice. I always felt much opened and collaborative with similarly minded people, and for them, happily rewrote my things from French to English in view of sharing, whenever I saw some mutual advantage to it. I resent when people want to force me into English when I have no real reason to do so. Let me choose to use my own language, as nicely as I can, when working in-shop with people sharing this language with me, for programs that will likely never be published outside anyway. Internationalisation is already granted in our overall view of today's programming, as a way for letting people be comfortable with computers, each in his/her own language. This comfort should extend widely to naming main programming objects (functions, classes, variables, modules) as legibly as possible. Here, I mean legible in an ideal way for the team or the local community, and not necessarily legible to the whole planet. It does not always have to be planetary, you know. For keywords, the need is less stringent, as syntactical constructs are part of a language. When English is opaque to a programmer, he/she can easily learn that small set of words making the syntax, understanding their effect, even while not necessarily understanding the real English meaning of those keywords. This is not a real obstacle in practice. It is true that many Python tools are not prepared to handle internationalised identifiers, and it is very unlikely that these tools will get ready before Python opens itself to internationalised identifiers. Let's open Python first, tools will undoubtedly follow. There will be some adaptation period, but after some while, everything will fall in place, things will become smooth again and just natural to everybody, to the point many of us might remember the current times, and wonder what was all that fuss about. :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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 implicit conversions).
On 10/30/05, François Pinard <[EMAIL PROTECTED]> wrote: > All development is done in house by French people. All documentation, > external or internal, comments, identifier and function names, > everything is in French. Some of the developers here have had a long > programming life, while they only barely read English. It is surely > a constant frustration, for some of us, having to mangle identifiers by > ravelling out their necessary diacritics. It does not look good, it > does not smell good, and in many cases, mangling identifiers > significantly decreases program legibility. Hear, hear! Not all the world uses english, and restricting them to latin characters simply means it's not readable in any language. It doesn't make it any more readable for those of us who only understand english. +1 on internationalized identifiers. -- 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] StreamHandler eating exceptions
On Sunday 30 October 2005 18:37, Gustavo Niemeyer wrote: > I'd like to apply the following patch: +1 Might want to include SystemExit as well, though I think that's less likely to be seen in practice. -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] PEP 351, the freeze protocol
Noam Raphael <[EMAIL PROTECTED]> wrote: > > Hello, > > It seems that we both agree that freezing is cool (-; . We disagree on > whether a copy-on-write behaviour is desired. Your arguments agains > copy-on-write are: > 1. It's not needed. > 2. It's complicated to implement. > > But first of all, you didn't like my use cases. I want to argue with that. > > > In reading your description of a 'table of values', I can't help but be > > reminded of the wxPython (and wxWidget) wx.Grid and its semantics. It > > offers arbitrary tables of values (whose editors and viewers you can > > change at will), which offers a mechanism by which you can "listen" to > > changes that occur to the contents of a cell. I can't help but think > > that if you offered a protocol by which a user can signal that a cell > > has been changed, perhaps by writing the value to the table itself > > (table.SetValue(row, col, value)), every read a deepcopy (or a PEP 351 > > freeze), etc., that both you and the users of your table would be much > > happier. > > Perhaps I didn't make it clear. The difference between wxPython's Grid > and my table is that in the table, most values are *computed*. This > means that there's no point in changing the values themselves. They > are also used frequently as set members (I can describe why, but it's > a bit complicated.) Again, user semantics. Tell your users not to modify entries, and/or you can make copies of objects you return. If your users are too daft to read and/or follow directions, then they deserve to have their software not work. Also from the sounds of it, you are storing both source and destination values in the same table...hrm, that sounds quite a bit like a spreadsheet. How does every spreadsheet handle that again? Oh yeah, they only ever store immutables (generally strings which are interpreted). But I suppose since you are (of course) storing mutable objects, you need to work a bit harder...so store mutables, and return immutable copies (which you can cache if you want, and invalidate when your application updates the results...like a wx.Grid update on changed). > > As for the graph issue, you've got a bigger problem than users just > > being able to edit edge lists, users can clear the entire dictionary of > > vertices (outgoing.clear()). It seems to me that a more reasonable > > method to handle this particular case is to tell your users "don't > > modify the dictionaries or the edge lists", and/or store your edge lists > > as tuples instead of lists or dictionaries, and/or use an immutable > > dictionary (as offered by Barry in the PEP). > > As I wrote before, telling my users "don't modify the edge lists" is > just like making lists hashable, and telling all Python users, "dont > modify lists that are dictionary keys." There's no way to tell the > users that - there's no convention for objects which should not be > changed. You can write it in the documentation, but who'll bother > looking there? When someone complains that something doesn't work, I tell them to read the documentation. If your users haven't been told to RTFM often enough to actually make it happen, then you need a RTFM-bat. Want to know how you make one? You start wrapping the objects you return which segfaults the process if they change things. When they start asking, tell them it is documented quite clearly "do not to modify objects returned, or else". Then there's the other option, which I provide below. > I don't think that your other suggestions will work: the data > structure of the graph itself can't be made of immutable objects, > because of the fact that the graph is a mutable object - you can > change it. It can be made of immutable objects, but this means copying > all the data every time the graph changes. So let me get this straight: You've got a graph. You want to be able to change the graph, but you don't want your users to accidentally change the graph. Sounds to me like an API problem, not a freeze()/mutable problem. Want an API? class graph: ... def IterOutgoing(self, node): ... def IterIncoming(self, node): ... def IsAdjacent(self, node1, node2): ... def IterNodes(self): ... def AddEdge(self, f_node, t_node): ... def RemEdge(self, node1, node2): ... def AddNode(self): ... If you are reasonable in your implementation, all of the above operations can be fast, and you will never have to worry about your users accidentally mucking about with your internal data structures: because you aren't exposing them. If you are really paranoid, you can take the next step and implement it in Pyrex or C, so that only a malicous user can muck about with internal structures, at which point you stop supporting them. > Now, about copy-on-write: > > > There's also this little issue of "copy on write" semantics with Python. > > Anyone who tells you that "copy on write" is easy, is probably hanging > > o
Re: [Python-Dev] svn checksum error
[EMAIL PROTECTED] wrote: > Martin> The natural question then is: what operating system, what > Martin> subversion version are you using? > > Sorry, wasn't thinking in terms of svn bugs. I was anticipating some sort > of obvious pilot error. I am on Mac OSX 10.3.9, running svn 1.1.3 I built > from source back in the May timeframe. Should I upgrade to 1.2.3 as a > matter of course? Not sure. The only mentioning of this specific message was about Linux and multi-threading, in svnserve. Apparently, due to some race condition/pthread locking semantics problems, something could get corrupted. It could be a compiler bug as well, of course. I would try to get some "official" binaries; 1.2.x works just fine with svn.python.org as well. 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
