[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 Python-Dev@python.org 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).
Atsuo Ishimoto wrote: 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. Thanks for these data. This mostly reflects my experience with German and French users: some people would like to use non-ASCII identifiers if they could, other argue they never would as a matter of principle. Of course, transliteration is more straight-forward. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 Sat, 2005-10-29 at 10:56 +0200, Martin v. Löwis wrote: Atsuo Ishimoto wrote: 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. Thanks for these data. This mostly reflects my experience with German and French users: some people would like to use non-ASCII identifiers if they could, other argue they never would as a matter of principle. Of course, transliteration is more straight-forward. Not sure if anyone has made this point already, but unicode identifiers are also useful for math programs. The ability to directly type the math letters, like alpha, omega, etc., would actually make the code more readable, while still understandable by programmers of all nationalities. For instance, you could write: Δv = x1 - x0 if Δv ε: return Instead of: delta_v = x1 - x0 if delta_v epsilon: return But anyone that is supposed to understand the code will be able to read the delta and epsilon symbols. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ Python-Dev mailing list Python-Dev@python.org 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).
Thanks for these data. This mostly reflects my experience with German and French users: some people would like to use non-ASCII identifiers if they could, other argue they never would as a matter of principle. Of course, transliteration is more straight-forward. FWIW, being French, I don't remember hearing any programmer wish (s)he could use non-ASCII identifiers, in any programming language. But arguably translitteration is very straight-forward (although a bit lossless at times ;-)). I think typeability and reproduceability should be weighted carefully. It's nice to have the real letter delta instead of delta, but how do I type it again on my non-Greek keyboard if I want to keep consistent naming in the program? ASCII is ethnocentric, but it probably can be typed easily with every device in the world. Also, as a matter of fact, if I type an identifier with an accented letter inside, I would like Python to warn me, because it would be a typing error on my part. Maybe this should be an option at the beginning of any source file (like encoding currently). Or is this overkill? ___ Python-Dev mailing list Python-Dev@python.org 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).
FWIW, being French, I don't remember hearing any programmer wish (s)he could use non-ASCII identifiers, in any programming language. But arguably translitteration is very straight-forward (although a bit lossless at times ;-)). I think typeability and reproduceability should be weighted carefully. It's nice to have the real letter delta instead of delta, but how do I type it again on my non-Greek keyboard if I want to keep consistent naming in the program? ASCII is ethnocentric, but it probably can be typed easily with every device in the world. Also, as a matter of fact, if I type an identifier with an accented letter inside, I would like Python to warn me, because it would be a typing error on my part. Maybe this should be an option at the beginning of any source file (like encoding currently). Or is this overkill? I'm also French and I must say that I agree with you. In my case, the most important thing is to be able to manage the _data_ in the good encoding. I'm currently trying to implement a little search engine in python (to improve my skills mainly) and the biggest problem I have to face is how to manage encoding. Some web pages are in French, in German, in English, etc. and it take me a lot of time to handle this problem correctly. I think it's more useful to be able to manipulate simply the _data_ than to have accents in identifiers. -- Derrière chaque bogue, il y a un développeur, un homme qui s'est trompé. (Bon, OK, parfois ils s'y mettent à plusieurs). ___ Python-Dev mailing list Python-Dev@python.org 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).
Antoine Pitrou wrote: FWIW, being French, I don't remember hearing any programmer wish (s)he could use non-ASCII identifiers, in any programming language. But arguably translitteration is very straight-forward (although a bit lossless at times ;-)). 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 :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
Hello! On Fri, Oct 28, 2005 at 09:29:09PM -0400, Tim Peters wrote: - Finding out what's changed in your sandbox. Use svn status svn diff uses locally saved copies of files. This increases speed by trading for the disk space. It also decreases net traffic; that's important for those who have expensive connections. 4. Making a branch or tag goes very fast under SVN. Fast and cheap in terms of space; Subversion uses a kind of symlinks in its internal filesystem. make simple applications of branches much more pleasant than under CVS. Much more pleasant. I now use more branches than I did with CVS and have less conflicts. * = svn:eol-style=native I would very much like to recommend developers to set svn:executable property on executable scripts and unset it on non-executable files; thus all those README and NEWS will be tarred with -rw-r--r-- attributes. :) Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org 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 27 okt 2005, at 19.57, Martin v. Löwis wrote: Michael Hudson wrote: Do checkins to svn.python.org go to the python-checkins list already? They do indeed - you should have received one commit message by now (me testing whether committing works, on PEP 347). Could the subject lines of those messages please be changed to something more informative? Having which files were changed in the subject seems better than having only the new rev and the folders the files are in. //Simon ___ Python-Dev mailing list Python-Dev@python.org 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
Simon Percivall wrote: Could the subject lines of those messages please be changed to something more informative? Having which files were changed in the subject seems better than having only the new rev and the folders the files are in. I'm neither sure whether that should be done, or whether it could be done. What do others think? I personally found those long subject lines listing all the changed files very ugly and unreadable. The other question (whether it could be done) is probably answered as yes, but I have to research what magic precisely is necessary. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 Sat, 2005-10-29 at 12:44, Martin v. Löwis wrote: What do others think? I personally found those long subject lines listing all the changed files very ugly and unreadable. Me too. At work our subject lines contain something like: Subject: [SVN][reponame] checkin of r12345 - dir/containing/changes Note that we send a different commit message for every directory the change happens in, even though it's all one revision. We like it that way because some people don't care about certain directories and can filter based on that. Inside the body of the email you'll see something like: Author: person Date: when New Revision: r12345 Log: Log message comes next. Definitely best to show up before the diff. diff comes next... FWIW, this format has worked well for us. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org 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
On Friday 28 October 2005 21:29, Tim Peters wrote: - 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. It's worth noting that svn status -u does require network access, since it has to check with the repository to see what's been updated there. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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
On Saturday 29 October 2005 15:40, [EMAIL PROTECTED] wrote: Author: martin.v.loewis Date: Sat Oct 29 21:40:21 2005 New Revision: 41352 Modified: python/trunk/ (props changed) python/trunk/.cvsignore ... Add *.pyc to svn:ignore. Add libpython*.a to .cvsignore and svn:ignore. Shouldn't we simply remove the .cvsignore files? Subversion doesn't use them, so they'll just end up getting out of sync with the svn:ignore properties. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org 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, I have thought about freezing for some time, and I think that it is a fundamental need - the need to know, sometimes, that objects aren't going to change. This is mostly the need of containers. dicts need to know that the objects that are used as keys aren't going to change, because if they change, their hash value changes, and you end up with a data structure in an inconsistent state. This is the need of sets too, and of heaps, and binary trees, and so on. I want to give another example: I and my colleges designed something which can be described as an electronic spreadsheet in Python. We called it a table. The values in the table are Python objects, and the functions which relate them are written in Python. Then comes the problem: the user has, of course, access to the objects stored in the table. What would happen if he changes them? The answer is that the table would be in an inconsistent state, since something which should be the return value of a function is now something else, and there's no way for the table to know about that. The solution is to have a freeze protocol. It may be called frozen (like frozen(set([1,2,3]))), so that it will be clear that it does not change the object itself. The definition of a frozen object is that its value can't change - that is, if you compare it with another object, you should get the same result as long as the other object hasn't changed. As a rule, only frozen objects should be hashable. I want to give another, different, use case for freezing objects. I once thought about writing a graph package in Python - I mean a graph with vertices and edges. The most obvious way to store a directed graph is as a mapping (dict) from a node to the set of nodes that it points to. Since I want to be able to find also which nodes point to a specific node, I will store another mapping, from a node to the set of nodes that point to it. Now, I want a method of the graph which will return the set of nodes that a given node points to, for example to let me write if y in graph.adjacent_nodes(x) then. The question is, what will the adjacent_nodes method return? If it returns the set which is a part of the data structure, there is nothing (even no convention!) that will prevent the user from playing with it. This will corrupt the data structure, since the change won't be recorded in the inverse mapping. adjacent_nodes can return a copy of the set, it's a waste if you only want to check whether an object is a member of the set. I gave this example to say that the frozen protocol should (when possible) return an object which doesn't really contain a copy of the data, but rather gives an image of the original object. If the original object changes while there are frozen copies of it, the data will be copied, and all the frozen objects will then reference a version of the data that will never change again. This will solve the graph problem nicely - adjacent_nodes would simply return a frozen copy of the set, and a copy operation would happen only in the rare cases when the returned set is being modified. This would also help the container use cases: they may call the frozen() method on objects that should be inserted into the container, and usually the data won't be copied. Some objects can't be created in their final form, but can only be constructed step after step. This means that they must be non-frozen objects. Sometimes they are constructed in order to get into a container. Unless the frozen() method is copy-on-change the way I described, all the data would have to be copied again, just for the commitment that it won't change. I don't mean to frighten, but in principle, this may mean that immutable strings might be introduced, which will allow us to get rid of all the cStringIO workarounds. Immutable strings would be constructed whenever they are needed, at a low performance cost (remember that a frozen copy of a given object has to be constructed only once - once it has been created, the same object can be returned on additional frozen() calls.) Copy-on-change of containers of non-frozen objects requires additional complication: it requires frozen objects to have a way for setting a callback that will be called when the original object was changed. This is because the change makes the container of the original object change, so it must drop its own frozen copy. This needs to happen only once per frozen object, since after a change, all the containers drop their frozen copies. I think this callback is conceptually similar to the weakref callback. Just an example that copy-on-change (at least of containers of frozen objects) is needed: sets. It was decided that you can test whether a non-frozen set is a member of a set. I understand that it is done by temporarily freezing the set, and that it caused some threading issues. A copy-on-change mechanism might solve it more elegantly. What do you think? Noam ___ Python-Dev
Re: [Python-Dev] svn:ignore
Hi, FWIW, I opened a bug report on Subversion some time ago so that patterns like *.pyc and *.pyo are ignored by default in Subversion. Feel free to add comments or vote for the bug: http://subversion.tigris.org/issues/show_bug.cgi?id=2415 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
That might be reasonable. I just noticed that it is convenient to do svn propset svn:ignore -F .cvsignore . Without a file, I wouldn't know how to edit the property, so I would probably do svn propget svn:ignore . ignores vim ignores svn propset svn:ignore -F ignores . rm ignores Won't svn propedit svn:ignore . do the trick? Noam ___ Python-Dev mailing list Python-Dev@python.org 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, I have thought about freezing for some time, and I think that it is a fundamental need - the need to know, sometimes, that objects aren't going to change. I agree with this point. This is mostly the need of containers. dicts need to know that the objects that are used as keys aren't going to change, because if they change, their hash value changes, and you end up with a data structure in an inconsistent state. This is the need of sets too, and of heaps, and binary trees, and so on. You are exactly mirroring the sentiments of the PEP. I want to give another example: I and my colleges designed something which can be described as an electronic spreadsheet in Python. We called it a table. The values in the table are Python objects, and the functions which relate them are written in Python. Then comes the problem: the user has, of course, access to the objects stored in the table. What would happen if he changes them? The answer is that the table would be in an inconsistent state, since something which should be the return value of a function is now something else, and there's no way for the table to know about that. I respectfully disagree with this point and the rest of your email. Why? For two use-cases, you offer 'tables of values' and 'graphs', as well as a possible solution to the 'problem'; copy on write. 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. 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). 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. One of the reasons why I liked the freeze protocol is that it offered a simple mechanism by which Python could easily offer support, for both new and old objects alike. Want an example? Here's the implementation for array freezing: tuple(a). What about lists? tuple(map(freeze, lst)) Freezing may not ultimately be the right solution for everything, but it is a simple solution which handles the majority of cases. Copy on write in Python, on the other hand, is significantly harder to implement, support, and is probably not the right solution for many problems. - Josiah P.S. To reiterate to Barry: map freeze to the contents of containers, otherwise the object can still be modified, and hence is not frozen. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
