Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
2014-04-09 17:37 GMT+02:00 Nathaniel Smith n...@pobox.com: On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist bjou...@gmail.com wrote: 2014-04-08 14:52 GMT+02:00 Nathaniel Smith n...@pobox.com: On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote: 2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com: So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/ Couldn't you please have made your motivation example actually runnable? import numpy as np from numpy.linalg import inv, solve # Using dot function: S = np.dot((np.dot(H, beta) - r).T, np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r)) # Using dot method: S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) Don't keep your reader hanging! Tell us what the magical variables H, beta, r and V are. And why import solve when you aren't using it? Curious readers that aren't very good at matrix math, like me, should still be able to follow your logic. Even if it is just random data, it's better than nothing! There's a footnote that explains the math in more detail and links to the real code this was adapted from. And solve is used further down in the section. But running it is really what you want, just insert: beta = np.random.randn(10) H = np.random.randn(2, 10) r = np.random.randn(2) V = np.random.randn(10, 10) Does that help? ;-) Thanks! Yes it does help. Then I can see that this expression: np.dot(H, beta) - r Evaluates to a vector. And a vector transposed is the vector itself. So the .T part in this expression np.dot(H, beta) - r).T is unnecessary, isn't it? In univariate regressions r and beta are vectors, and the .T is a no-op. The formula also works for multivariate regression, in which case r and beta become matrices; in this case the .T becomes necessary. Then what is the shape of those variables supposed to be? The earlier definitions you gave isn't enough for this general case. -- mvh/best regards Björn Lindqvist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
2014-04-08 14:52 GMT+02:00 Nathaniel Smith n...@pobox.com: On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote: 2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com: So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/ Couldn't you please have made your motivation example actually runnable? import numpy as np from numpy.linalg import inv, solve # Using dot function: S = np.dot((np.dot(H, beta) - r).T, np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r)) # Using dot method: S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) Don't keep your reader hanging! Tell us what the magical variables H, beta, r and V are. And why import solve when you aren't using it? Curious readers that aren't very good at matrix math, like me, should still be able to follow your logic. Even if it is just random data, it's better than nothing! There's a footnote that explains the math in more detail and links to the real code this was adapted from. And solve is used further down in the section. But running it is really what you want, just insert: beta = np.random.randn(10) H = np.random.randn(2, 10) r = np.random.randn(2) V = np.random.randn(10, 10) Does that help? ;-) Thanks! Yes it does help. Then I can see that this expression: np.dot(H, beta) - r Evaluates to a vector. And a vector transposed is the vector itself. So the .T part in this expression np.dot(H, beta) - r).T is unnecessary, isn't it? -- mvh/best regards Björn Lindqvist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com: So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/ Couldn't you please have made your motivation example actually runnable? import numpy as np from numpy.linalg import inv, solve # Using dot function: S = np.dot((np.dot(H, beta) - r).T, np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r)) # Using dot method: S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) Don't keep your reader hanging! Tell us what the magical variables H, beta, r and V are. And why import solve when you aren't using it? Curious readers that aren't very good at matrix math, like me, should still be able to follow your logic. Even if it is just random data, it's better than nothing! -- mvh/best regards Björn Lindqvist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
2014-04-08 12:23 GMT+02:00 Sturla Molden sturla.mol...@gmail.com: Björn Lindqvist bjou...@gmail.com wrote: import numpy as np from numpy.linalg import inv, solve # Using dot function: S = np.dot((np.dot(H, beta) - r).T, np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r)) # Using dot method: S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) Don't keep your reader hanging! Tell us what the magical variables H, beta, r and V are. And why import solve when you aren't using it? Curious readers that aren't very good at matrix math, like me, should still be able to follow your logic. Even if it is just random data, it's better than nothing! Perhaps. But you don't need to know matrix multiplication to see that those expressions are not readable. And by extension, you can still imagine that bugs can easily hide in unreadable code. Matrix multiplications are used extensively in anything from engineering to statistics to computer graphics (2D and 3D). This operator will be a good thing for a lot of us. All I ask for is to be able to see that with my own eyes. Maybe there is some drastic improvement I can invent to make the algorithm much more readable? Then the PEP:s motivation falls down. I don't want to have to believe that the code the pep author came up with is the most optimal. I want to prove that for myself. -- mvh/best regards Björn Lindqvist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Retrieve an arbitrary element from asetwithoutremoving it
2009/11/6 Raymond Hettinger pyt...@rcn.com:
[me]
Why not write a short, fast get_first() function for your utils directory
and be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for something so trivial and so
rarely needed.
Forgot to post the code. It is short, fast, and easy. It is explicit about
handing the case with an empty input. And it is specific about which value
it returns (always the first iterated value; not an arbitrary one). There's
no guessing about what it does. It gets the job done.
def first(iterable):
'Return the first value from a container or iterable. If empty, raises
LookupError'
for value in iterable:
return value
raise LookupError('no first value; iterable is empty')
If desired, it is not hard to change to the last time to return a default
value or some other exception.
That function is very nice and genericly lisp-like. Couldn't that one
be in the builtins? It would both solve the problem and avoid
fattening the set API.
--
mvh Björn
___
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] please consider changing --enable-unicode default to ucs4
2009/9/28 James Y Knight f...@fuhm.net: People building their own Python version will usually also build their own extensions, so I don't really believe that the above scenario is very common. I'd just like to note that I've run into this trap multiple times. I built a custom python, and expected it to work with all the existing, installed, extensions (same major version as the system install, just patched). And then had to build it again with UCS4, for it to actually work. Of course building twice isn't the end of the world, and I'm certainly used to having to twiddle build options on software to get it working, but, this *does* happen, and *is* a tiny bit irritating. I've also encountered this trap multiple times. Obviously, the problem is not rebuilding Python which is quick, but to figure out the correct configure option to use (--enable-unicode=ucs4). Others have also spent some time scratching their heads over the strange PyUnicodeUCS4_FromUnicode error the misconfiguration results in, as Zooko's links show. If Python can't infer the unicode setting from the width of the platforms wchar_t, then perhaps it should be mandatory to specify to configure whether you want UCS2 or UCS4? For someone clueless like me, it would be easier to deal with the problem upfront than (much) further down the line. Explicit being better than implicit and all that. -- mvh Björn ___ 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] Issue5434: datetime.monthdelta
It's not only about what people find intuitive. Why care about them? Most persons aren't programmers. It is about what application developers find useful too. I have often needed to calculate month deltas according to the proposal. I suspect many other programmers have too. Writing a month add function isn't entirely trivial and would be a good candidate for stdlib imho. 2009/4/17, Antoine Pitrou solip...@pitrou.net: James Y Knight foom at fuhm.net writes: It's a human-interface operation, and as such, everyone (ahem) knows what it means to say 2 months from now, but the details don't usually have to be thought about too much. I don't think it's true. When you say 2 months from now, some people will think 9 weeks from now (or 10 weeks from now), others 60 days from now, and yet other will think of the meaning this proposal gives it. That's why, when scheduling a meeting, you don't say 2 months from now. You give a precise date instead, because you know otherwise people wouldn't show up on the same day. 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/bjourne%40gmail.com -- mvh Björn ___ 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] Proposal: add odict to collections
On Sat, Jun 14, 2008 at 11:39 PM, Armin Ronacher [EMAIL PROTECTED] wrote: Some reasons why ordered dicts are a useful feature: And for metaclasses or for LRU caches or for removing duplicates in a list while maintaining order. I think that the name ordereddict would be more readable though, and match the existing defaultdict class in the collections module. -- mvh Björn ___ 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] urllib exception compatibility
On 9/27/07, Guido van Rossum [EMAIL PROTECTED] wrote: How about making IOError, OSError and EnvironmentError all aliases for the same thing? The distinction is really worthless historical baggage. Wouldn't it also be nice to have some subclasses of IOError like FileNotFoundError, IOPermissionError and EOFError? Often that would be easier than having to use the errno attribute to find out the exact cause. -- mvh Björn ___ 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-3000] Documentation switch imminent
It is fantastic! Totally super work. I just have one small request; pretty please do not set the font. I'm very happy with my browsers default (Verdana), and Bitstream Vera Sans renders badly for me. -- mvh Björn ___ 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
[Python-Dev] Patch reviews
Here is a review of some patches: * [ 1673759 ] '%G' string formatting doesn't catch same errors as '%g' This patch is done, has been reviewed and works as advertised. Just needs someone to commit it I think. * [ 1100942 ] datetime.strptime constructor added Doesn't apply cleanly, emits compiler warnings, but works as expected. Lacks tests. * [ 968063 ] Add fileinput.islastline() Good and useful patch (see the pup.py program) but lacks unit tests and documentation. * [ 1501979 ] syntax errors on continuation lines Doesn't apply cleanly, but that is easy to fix. Needs someone to fix a few minor flaws in it, but the patch works really well. * [ 1375011 ] Improper handling of duplicate cookies Fixes a fairly exotic bug in which Pythons cookie handling deviates in an obscure way from Netscapes cookie specification. See the bug about it at 1372650. As far as I can understand, the patch fixes the problem. If someone still does the 5 for 1 deal, my patch is [ 1676135 ]. -- mvh Björn ___ 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] Minor ConfigParser Change
On 6/1/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: Changes in general are a source of risk; they have to be considered carefully. We've seen too many cases in which a change was thought to be safe, but broke something for someone. Avoiding style-only changes helps avoid introducing problems without being able to predict them; there are tests for ConfigParser, but it's hard to be sure every corner case has been covered. I understand what you mean, all changes carry a certain risk. Especially in code that is so widely relied upon as the Standard Library. But the alternative, which is to let the code rot, while one-line fixes are applied upon it, is a much worse alternative. It is true that unit tests does not cover all corner cases and that you can't be 100% sure that a change won't break something for someone. But on the other hand, the whole point with unit tests is to facilitate exactly these kind of changes. If something breaks then that is a great opportunity to introduce more tests. This is a general policy in the Python project, not simply my preference. I'd love to be able to say yes, the code is painful to read, let's make it nicer, but it's hard to say that without being able to say I'm sure it won't break anything for anybody. Python's too flexible for that to be easy. While what you have stated is the policy, I can't help but think that it is totally misguided (no offense intended). Maybe the policy can be reevaluated? -- mvh Björn ___ 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
[Python-Dev] What exception should Thread.start() raise?
The threading module contains buggy code: class Thread(_Verbose): ... def start(self): assert self.__initialized, Thread.__init__() not called assert not self.__started, thread already started ... If you run such code with python -O, weird stuff may happen when you call mythread.start() multiple times. -O removes assert statements so the code won't fail with an AssertionError which would be expected. So what real exception should Thread.start() raise? I have suggested adding an IllegalStateError modelled after java's IllegalStateException, but that idea was rejected. So what exception should be raised here, is it a RuntimeError? -- mvh Björn ___ 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] The docs, reloaded
On 5/24/07, Greg Ewing [EMAIL PROTECTED] wrote: Talin wrote: As in the above example, the use of backticks can be signal to the document processor that the enclosed text should be examined for identifiers and other Python syntax. Does this mean it's time for pyST -- Python-structured text?-) Not before someone writes it. Georg Brandl's awesome ReST based system has the nice property that it actually exists and works. For a great number of reasons it is superior to the existing LaTeX based system, and I hope and think that they are strong enough to replace LaTeX with it. -- mvh Björn ___ 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] The docs, reloaded
IMO that pair of examples shows clearly that, in this application, reST is not an improvement over LaTeX in terms of readability/ writability of source. It's probably not worse, although I can't help muttering EIBTI. In particular I find the ``'...'`` construct horribly unreadable because it makes it hard to find the Python syntax in all the reST. Well. That was a bad example. But if you look at the converted sources and open the source file you can see that rst is a lot cleaner that latex for this type of documentation. In your examples, I think the ReST version can be cleaned up quite a bit. First by using the .. default-role:: literal directive so that you can type `foo()` instead of using double back quotes and then you can remove the redundant semantic markup. Like this: `\*?`, `+?`, `??` The `*`, `+` and `?` qualifiers are all *greedy*; they match as much text as possible. Sometimes this behaviour isn't desired; if the RE `.*` is matched against `'H1title/H1'`, it will match the entire string, and not just `'H1'`. Adding `?` after the qualifier makes it perform the match in *non-greedy* or *minimal* fashion; as *few* characters as possible will be matched. Using `.*?` in the previous expression will match only `'H1'`. The above is the most readable version. For example, semantic markup like :regexp:`.\*` doesn't serve any useful purpose. The end result is that the text is typesetted with a fixed-width font, no matter if you prepend :regexp: to it or not. -- mvh Björn ___ 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] The docs, reloaded
In your examples, I think the ReST version can be cleaned up quite a bit. First by using the .. default-role:: literal directive so that you can type `foo()` instead of using double back quotes and then you can remove the redundant semantic markup. Like this: I've already assigned the default role to `var` since it's used most frequently. Having two ways of spelling literal code is wasting markup, for me. Reassign it then. :) `var` makes italic text but you can use *var* for that instead. Minor point I know, but it would make reading ReST source just a tiny bit easier. -- mvh Björn ___ 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] functools additions
def cat(x): return x def multimap(func, s, n=2): assert n 0, n must be positive return (map(func, seq) if n == 1 else map(lambda x: multimap(func, x, n-1), seq)) def multifilter(func, s, n=2): return multimap(lambda x: filter(func, x), s, n-1) def multireduce(func, s, n=2): return multimap(lambda x: reduce(func, x), s, n-1) class nullfunc(object): def __call__(self, *a, **k): return self def __getattr(self, name): return getattr(None, name) Could you describe what these functions do? Preferably with examples that demonstrates that they are useful. -- mvh Björn ___ 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] concerns regarding callable() method
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote: I have no problems with Python being untyped. But I want that error stack traces provide some useful information as possible with reasonable effort and that errors happen as early as possible. In particular, stack trace should mention that error occured when you passed something wrong to set_callback() call and not in some obscure place 200 lines later, because otherwise it will only obfuscate error reason. Using the duck typing philosophy; if it quacks like a duck and walks like a duck, then it probably is a duck. But how can you be so sure it is NOT a duck if you have never seen it walk or heard it quack? What if you are passing in an object that is not callable but later on becomes callable? Is it really an error? I think the plan is that in py3k, you will be able to do type-checking using function annotations (bleach). Like this: def set_callback(self, callback : CallableType): self.callback = callback You probably also need to add some more gunk to make it work. I believe it should be able to replace most uses of callable(). -- mvh Björn ___ 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] Proposal to revert r54204 (splitext change)
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: Phillip J. Eby schrieb: This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. That much is obvious. But I haven't seen any explanation as to why explicitly-documented and explicitly-tested behavior should be treated as a bug in policy terms, just because people don't like the documented and tested behavior. So far, the only policy justification I've seen you give was along the lines of, I volunteered to do it, so I get to decide. I guess it maybe also had something to do with that the bug had been left open on the bug tracker for almost two years and the persons favoring the change had a 2:1 advantage (3:1 if you count the patch contributor). There was plenty of time to voice your dissent. I also think that which ever behavior splitext has, it does not matter much in the grand scheme of things. There are bigger fishes to fry. -- mvh Björn ___ 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] datetime module enhancements
On 3/11/07, Steven Bethard [EMAIL PROTECTED] wrote: On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote: I've another idea. Date and datetime objects are compared by date. The date object for a given date is always smaller than the datetime for the same day - even for midnight. I really don't understand what the problem is with having a date() behave like a proper temporal interval. The only person complaining about that interpretation acknowledged that for his purposes, it would be better than the status quo. And I have yet to see a use case where being consistent with temporal interval logic is a problem. I do not really understand proper temporal intervals. But I am interested what temporal interval logic has to say about this problem: def get_most_recent_articles(articles, cutoff_date): recent_articles = [] for article in articles: if article.datetime_posted cutoff_date: recent_articles.append(article) return recent_articles Would temporal interval logic make it so an article with datetime(2007, 1, 1, 0, 0, 0) be included, if cutoff_date was date(2007, 1, 1)? What about articles with datetimes (2007, 1, 1, 0, 0, 1) and (2007, 1, 2, 0, 0, 0) respectively? I believe that temporal interval logic has to include at least the last two examples in recent_articles, otherwise it would be highly annoying. -- mvh Björn ___ 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] datetime module enhancements
On 3/9/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The range of datetime objects far exceeds that of the current Unix timestamp. Given that the range of current (32-bit) Unix timestamps is approximately 1970 to 2038, What would the output of this be? dt = datetime.datetime(3000, 1, 1, 0, 0, 0) print dt.totimestamp() dt = datetime.datetime(1900, 1, 1, 0, 0, 0) print dt.totimestamp() If you extend the range to 64 bits there's no problem: the first should print 3250368, the second -2208988800. I think it should be a ValueError, given that the programmer is very likely to further use the returned timestamp to for example insert stuff in a database. Unix timestamps are not unambiguously defined for any years other than 1970 to 2038 imho. -- mvh Björn ___ 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] datetime module enhancements
On 3/9/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/9/07, BJörn Lindqvist [EMAIL PROTECTED] wrote: On 3/9/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The range of datetime objects far exceeds that of the current Unix timestamp. Given that the range of current (32-bit) Unix timestamps is approximately 1970 to 2038, What would the output of this be? dt = datetime.datetime(3000, 1, 1, 0, 0, 0) print dt.totimestamp() dt = datetime.datetime(1900, 1, 1, 0, 0, 0) print dt.totimestamp() If you extend the range to 64 bits there's no problem: the first should print 3250368, the second -2208988800. I think it should be a ValueError, given that the programmer is very likely to further use the returned timestamp to for example insert stuff in a database. Unix timestamps are not unambiguously defined for any years other than 1970 to 2038 imho. But they will be. And they already are on some platforms. The database should raise an OverflowError if a timestamp is out of range, but it would be unpythonic to limit those outcomes to 32 bits. Then I guess datetime.fromtimestamp() also should be fixed?: datetime.fromtimestamp(-1) Traceback (most recent call last): File stdin, line 1, in module ValueError: timestamp out of range for platform localtime()/gmtime() function datetime.fromtimestamp(-0.5) Traceback (most recent call last): File stdin, line 1, in module ValueError: microsecond must be in 0..99 datetime.fromtimestamp(99) Traceback (most recent call last): File stdin, line 1, in module ValueError: timestamp out of range for platform time_t Would be nice if datetime.fromtimestamp(dt.totimestamp()) == dt worked for all datetimes. -- mvh Björn ___ 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
[Python-Dev] Italic text in the manual
(This might be a silly question..) In the dev stdlib reference there are lots of pages in which all text is in italics. Such as all chapters after chapter 18. Is it supposed to be that way? It looks quite ugly. -- mvh Björn ___ 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 364, Transitioning to the Py3K standard library
When Python's import machinery is initialized, the oldlib package is imported. Inside oldlib there is a class called ``OldStdlibLoader``. This class implements the PEP 302 interface and is automatically instantiated, with zero arguments. The constructor reads all the ``.mv`` files from the oldlib package directory, automatically registering all the remappings found in those ``.mv`` files. This is how the Python 2.x standard library is remapped. Will not reading all those .mv files add a lot of overhead? Disk seeks is not cheap. -- mvh Björn ___ 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] New syntax for 'dynamic' attribute access
Is even more syntactic sugar really what Python really needs? -- mvh Björn ___ 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 355 status
On 10/28/06, Talin [EMAIL PROTECTED] wrote: BJörn Lindqvist wrote: I'd like to write a post mortem for PEP 355. But one important question that haven't been answered is if there is a possibility for a path-like PEP to succeed in the future? If so, does the path-object implementation have to prove itself in the wild before it can be included in Python? From earlier posts it seems like you don't like the concept of path objects, which others have found very interesting. If that is the case, then it would be nice to hear it explicitly. :) So...how's that post mortem coming along? Did you get a sufficient answer to your questions? Yes and no. All posts have very exhaustively explained why the implementation in PEP 355 is far from optimal. And I can see why it is. However, what I am uncertain of is Guido's opinion on the background and motivation of the PEP: Many have felt that the API for manipulating file paths as offered in the os.path module is inadequate. Currently, Python has a large number of different functions scattered over half a dozen modules for handling paths. This makes it hard for newbies and experienced developers to to choose the right method. IMHO, the current API is very messy. But when it comes to PEPs, it is mostly Guido's opinion that counts. :) Unless he sees a problem with the current situation, then there is no point in writing more PEPs. And the more interesting question is, will the effort to reform Python's path functionality continue? I certainly hope so. But maybe it is better to target Python 3000, or maybe the Python devs already have ideas for how they want the path APIs to look like? So what happens next? I really hope that Guido will give his input when he has more time. Mvh Björn ___ 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 355 status
On 10/1/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 9/30/06, Giovanni Bajo [EMAIL PROTECTED] wrote: It would be terrific if you gave us some clue about what is wrong in PEP355, so that the next guy does not waste his time. For instance, I find PEP355 incredibly good for my own path manipulation (much cleaner and concise than the awful os.path+os+shutil+stat mix), and I have trouble understanding what is *so* wrong with it. You said it's an amalgam of unrelated functionality, but you didn't say what exactly is unrelated for you. Sorry, no time. But others in this thread clearly agreed with me, so they can guide you. I'd like to write a post mortem for PEP 355. But one important question that haven't been answered is if there is a possibility for a path-like PEP to succeed in the future? If so, does the path-object implementation have to prove itself in the wild before it can be included in Python? From earlier posts it seems like you don't like the concept of path objects, which others have found very interesting. If that is the case, then it would be nice to hear it explicitly. :) -- mvh Björn ___ 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 Doc problems
If there are rampant criticisms of the Python docs, then those that are complaining should take specific examples of their complaints to the sourceforge bug tracker and submit documentation patches for the relevant sections. And personally, I've not noticed that criticisms of the Python docs are rampant, but maybe there is some I hate Python docs newsgroup or mailing list that I'm not subscribed to. Meh! The number one complaint IS that you have to take your complaints to the sourceforge bug tracker and submit documentation patches. For documentation changes, that is way to much overhead for to little gain. But thankfully I think there are people working on fixing those problems which is very nice. -- mvh Björn ___ 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] Rounding float to int directly (Re: struct module and coercing floats to integers)
On 8/2/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Greg Ewing wrote: In all my programming so far I've found numerous uses for round-to-int, and exactly zero uses for round-binary-float-to-decimal- places. So from my point of view, the YAGNI applies to the *current* behavour of round()! Most typical uses of round() don't use the optional argument, true, but I still fail to see what returning an integer instead of a float would buy you. One hundred and sixty two type conversions! http://www.google.se/search?hl=svq=filetype%3Apy+%22int%28round%22btnG=S%C3%B6kmeta= -- mvh Björn ___ 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] Minor: Unix icons for 2.5?
I know the .desktop files have become fairly standard, but are these our responsibility or does that rest with the distributions/integrators? (I'm not objecting, but I'm not sure what the right thing really is since Python is an interpreter, not a desktop application.) The same anal argument could of course be made for every piece of software. Is Emacs a desktop application or a lisp interpreter? Is vim a desktop app? Are games? There is no reason add yet another task to to multiple distributors/integrators (that they won't do) when the problem can be fixed at the source. -- mvh Björn ___ 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] Switch statement
On 6/23/06, Edward C. Jones [EMAIL PROTECTED] wrote: Python is a beautiful simple language with a rich standard library. Python has done fine without a switch statement up to now. Guido left it out of the original language for some reason (my guess is simplicity). Why is it needed now? What would be added next: do while or goto? The urge to add syntax should be resisted unless there is a high payoff (such as yield). There are much better ways for the developers to spend their time and energy (refactoring os comes to mind). Please keep Python simple. -1 on the switch statement. I agree. IMHO switch is a useless statement which can cause many problems in any language. It misleads programmers to dispatch in the wrong way. If you have switch with 5 cases, an if-elif chain fits just fine. If the switch is larger use a dictionary that maps values to functions. In C, many times a switch block starts small (40 lines) but grows as the number of values to dispatch on increases. Soon it becomes a 500 line monstrosity that is impossible to refactor because variables from the enclosing space is used frivolously. I don't get the speed argument either. Who cares that if-elif-chains are O(n) and switch O(1)? If n 10 you are doing something wrong anyway. I don't think I have ever seen in any language a switch construct that, barring speed concerns, wouldn't be better written using any other dispatch mechanism than switch. -- mvh Björn ___ 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] Pre-PEP: Allow Empty Subscript List Without Parentheses
And from a syntax perspective, it's a bad idea. x[] is much more often a typo than an intentional attempt to index a zero-dimensional array. but how often is it a typo? for example, judging from c.l.python traffic, forgetting to add a return statement is a quite common, but I haven't seen anyone arguing that we deprecate the implied return None behaviour. Sounds like a terrific idea. The implicit None behaviour has hit me many times and: something = somefunc() is almost always an error if somefunc() doesn't have an explicit return statement. I don't know how difficult it is to get rid of the implicit return None or even if it is doable, but if it is, it should, IMHO, be done. -- mvh Björn ___ 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 3102: Keyword-only arguments
would have thought that the one obvious way to get rid of the wanky feeling would have been to write: def make_person(name, age, phone, location): ... make_person(name, age, phone, location) This doesn't fly in something like PyGUI, where there are literally dozens of potential arguments to many of the constructors. The only sane way to deal with that is for them to be keyword-only, at least conceptually if not in actual implementation. Probably. I don't know enough about library design in Python to meaningfully criticize the Keyword-only arguments suggestion. However, I do know enough about Python to know that the make_person function is a really bad example. The one obvious way to write make_peson is to use four positional arguments, name, age, phone, location and not complicate the function by throwing in required keyword arguments. It would be nice to instead see some real examples of the usefulness of the required keyword-only arguments. Like from your PyGUI or maybe from the standard library? But IMHO, your design is broken if you need to send dozens of arguments to any function or method. -- mvh Björn ___ 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 3102: Keyword-only arguments
make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. I meant it to do the same thing as make_person(name=name, age=age, phone=phone, location=location) I come across use cases for this fairly frequently, usually when I have an __init__ method that supplies default values for a bunch of arguments, and then wants to pass them on to Me too! I would have thought that the one obvious way to get rid of the wanky feeling would have been to write: def make_person(name, age, phone, location): ... make_person(name, age, phone, location) IMHO, keyword arguments are often overused like that. Many times they don't improve readability any more than naming your variables sensibly do. No, I have not studied how my API:s are used (and how they evolve) over a longer period of time. -- mvh Björn ___ 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 3000 Process
Please don't respond with answers to these questions -- each of them is worth several threads. Instead, ponder them, and respond with a +1 or -1 on the creation of the python-3000 mailing list. We'll start discussing the issues there -- or here, if the general sense is not to split the list. -0 on separate mailing list and PEP numbers. Because to much separation between python 2.x and python 3.x makes 3.x seem more like vaporware that will never happen (Perl 6). I would have hoped that the transition to 3.x would be evolutionary in small steps; removal of string exceptions in one major release, replacement of print with a function in the next and so on. A total redesign from bottom up in one release has a very high probability of failing IMHO. Or at least very annoying for end users that who to deal with two parallel and incompatible versions. The reality is that discussions about python 3000 has a high probability of being a total waste of time. I think all those of us who have for lengths argued whether lambda should stay or be dropped knows that. :) -- mvh Björn ___ 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] quit() on the prompt
do {
cmd = readline()
do_stuff_with_cmd(cmd);
} while (!strcmp(cmd, quit));
printf(Bye!);
exit(0);
KISS?
--
mvh Björn
___
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] Path PEP and the division operator
On 2/4/06, Guido van Rossum [EMAIL PROTECTED] wrote: I won't even look at the PEP as long as it uses / or // (or any other operator) for concatenation. That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html -- mvh Björn ___ 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] The path module PEP
I've submitted an updated version of the PEP. The only major change is that instead of the method atime and property getatime() there is now only one method named atime(). Also some information about the string inheritance problem in Open Issues. I still have no idea what to do about it though. -- mvh Björn ___ 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] Path inherits from string
[M.-A. Lemburg]
I don't see why this is critical for the success of the Path
object. I agree with Thomas that interfaces should be made
compatible to Path object.
See the steps I mentioned. Unless step #1 is completed there is no way
to make the following code work:
open(Path(foobar))
Well, there is one alternative which is:
open(Path(foobar).tostring())
And that is a Java-esque workaraound that I think noone would be happy
with.
Why not ? We've added Unicode support to at least some
file I/O APIs - adding support for instances which
support the string interface shouldn't be all that
difficult :-)
BTW, if you're fine with this API:
class File:
def __unicode__(self):
return utest.txt
then the required change is minimal: we'd just need to
use PyObject_Unicode() in getargs.c:837 and you should
be set.
Alright! If that is true then maybe step #1 isn't as hard as I
thought. First problem is the string interface. What exactly is the
string interface? It needs to be specified. I would have guessed that
it was equal to the stuff in the builtin str class.. :) Then you need
to modify Python's C code so that it accepts all objects implementing
the string interface. That may not be a trivial task [1]. Also don't
forget that Path probably also should work with:
isinstance(Path('.'), basestring)
Because one of the big selling points of Path is that it acts as a
drop-in replacement for strings [2]. And you don't want to mess with
the current canonical way of testing if an object implements the
string interface. But you aren't supposed to subclass basestring
[3].
All I'm saying is that I don't have the technical knowledge required
to modify Python to make Path work without subclassing string. If you,
or someone else, do then pretty please with sugar on top make a patch
so that Path doesn't have to subclass string.
Then you could have a much more pure Path without the dead
methods. But even then, one could argue that Jason Orendorffs original
Path module is still more practical (atleast for compatibility
reasons).
def save_data(somedir, fpath, data):
open(somedir + / + fpath.lower(), w).write(data)
The above code isn't going to work unless fpath is a string (or an
object that inherits from string). It isn't good code, but it isn't
extremely uncommon either.
1 http://mail.python.org/pipermail/python-dev/2006-January/059780.html
2 http://mail.python.org/pipermail/python-list/2005-July/291213.html
3 http://mail.python.org/pipermail/python-dev/2006-January/059782.html
--
mvh Björn
___
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
[Python-Dev] Path inherits from string
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
Really, it is the same arguments that have been rehashed over and over
again. I also think that they have been suitably countered already -
Practicality beats Purity. The fact that you can plug Path into
already existing code is a major benefit. It makes it possible to use
and integrate the Path class *now* and not wait until the mythical
Python 3000 when every single flaw in Python have been fixed. Remember
that the Path module have existed for three years in the wild and is
extra-ordinarily well-liked. If the fact that Path inherits from
string is such a big deal, then *why* is the path module so hugely
popular?? :)
The inheritance is a design trade-off. An implementation detail, an
insignificant wart in an otherwise very practical design. Over the
years I have used the path module this wart has never ever hurt
me. Not even once. But if someone can construct a Path class that does
*not* inherit from string and that works equally well as Path then
ofcourse, that is preferable. However, because of this (and similar
issues) I don't think it is possible:
class Foo:
def __str__(self):
return foo
open(Foo())
TypeError: coercing to Unicode: need string or buffer, instance found
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
Also note that because compatibility with existing code is important,
Path can not override or change any methods at all from str - Liskov
Substitution Principle. As Path is, it only violates LSP once:
type(Path()) == type('')
False
And there is absolutely nothing that can be done about that. As far as
I can tell, the string inheritance is either livable with or is a
showstopper. If it is the latter, then:
1. Someone has to make the required modifications to the Python
core.
2. Create a Path class (or adapt the existing one so) that does
not inherit from string.
3. Release it and wait a few years hoping for it to gain
widespread acceptance in the Python community.
4. Make a PEP (or adapt this PEP) that gets accepted.
This scenario makes me sad because it basically means that there will
never be a Path module in Python, atleast not during my lifetime. :(
Why? Because Jason Orendorff's path module already exists and
works. But I may be overestimating the problems and doing what Jason
suggests in [2] may be enough. Maybe someone who knows what he is
talking about can expand on it further?
1 http://mail.python.org/pipermail/python-dev/2001-August/016674.html
2 http://mail.python.org/pipermail/python-dev/2006-January/060030.html
--
mvh Björn
___
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] / as path join operator (was: Re: The path module PEP)
I think that everything that can be said aboud __div__() has already been said. But this argument was really convincing: [Tony Meyer] The vast majority of people (at least at the time) were either +0 or -0, not +1. +0's are not justification for including something. There is no clear consensus either way. Ultimately, Guido will decide if he thinks it is clever or not. Meanwhile I'll remove it from the PEP and keep it as an optional extension. Also, like Jason said, the removal of __div__() leads to the ultimate demise of joinpath(), woho! [Jason Orendorff] in which case I propose using the Path constructor as the replacement for os.path.join(). In that case, Path.joinpath can be dropped. Path.cwd() / foobar == Path(Path.cwd(), foobar) Path(foo) / bar / baz == Path(foo, bar, baz) Still, in the simpler cases, __div__() looks really handy: os.chdir(pkgdir / include) == os.chdir(Path(pkgdir, include)) Oh well. You can't have everything, can you? The updated PEP and an implementation is availible from http://wiki.python.org/moin/PathClass. -- mvh Björn ___ 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] The path module PEP
My comments on the issues. It was easier this way than trying to reply on every message individually. Inheritance from string (Jason) This issue has been brought up before when people were discussing the path module. I think the consensus is that, while the inheritance isn't pure, practicality beats purity. It would require to big changes to Python and would break to much existing code to not extend string. I'll add this to Resolved Issues if nobody minds. * http://mail.python.org/pipermail/python-dev/2001-August/016663.html * http://mail.python.org/pipermail/python-dev/2001-August/016665.html * http://mail.python.org/pipermail/python-list/2005-July/291091.html * http://mail.python.org/pipermail/python-list/2005-July/291152.html Remove __div__ (Ian, Jason, Michael, Oleg) This is one of those where everyone (me too) says I don't care either way. If that is so, then I see no reason to change it unless someone can show a scenario in which it hurts readability. Plus, a few people have said that they like the shortcut. * http://mail.python.org/pipermail/python-list/2005-July/292251.html * http://mail.python.org/pipermail/python-dev/2005-June/054496.html * http://mail.python.org/pipermail/python-list/2005-July/291628.html * http://mail.python.org/pipermail/python-list/2005-July/291621.html Remove redundant methods (Eric, Ian, Jason, Ronald, Toby) I think it is a good idea to take out some of Path's methods. Especially the ones that exist as both methods and properties. I have updated the pep and dumped basename(), dirname(), splitdrive() and splitext(). I think that glob() should also go away because I can't of the top of my head think of a scenario where it would be suitable over listdir(), dirs() or files(). Plus, for contrived examples; like glob.glob(/*bin/*foo*) the Path way doesn't look so good: Path(/).glob(*bin/*foo*). Renaming methods because of PEP 8 (Gustavo, Ian, Jason) I'm personally not keen on that. I like most of the names as they are. abspath(), joinpath(), realpath() and splitall() looks so much better than abs_path(), join_path(), real_path() and split_all() in my eyes. If someone like the underscores I'll add it to Open Issues. Removing open() and methods that manipulate the whole file at once (Ian, Jason) I think this is settled with the addition of the with statement? My idea when scrubbing these methods was that it would make it easier to get the PEP accepted. However, even with with, these methods save some typing. * http://mail.python.org/pipermail/python-dev/2005-June/054439.html * http://mail.python.org/pipermail/python-list/2005-July/291435.html ?time properties and get?time() methods Clearly, Path has either the properties or the methods, not both at once. Yet another I don't care either way. * http://mail.python.org/pipermail/python-dev/2005-June/054439.html * http://mail.python.org/pipermail/python-list/2005-July/291424.html * http://mail.python.org/pipermail/python-list/2005-July/291460.html I have also the corrected the copy-paste errors I inadvertedly introduced. Path should *not* have an __iter__. :) * match() and matchcase() wraps the fnmatch.fnmatch() and fnmatch.fnmatchcase() functions. I believe that the renaming is uncontroversial and that the introduction of matchcase() makes it so the whole fnmatch module can be deprecated. I have created an implementation of Path that corresponds to the specification in the PEP (which I hope will appear on www.python.org/peps soon). It is based on Reinhold's (Georg Brandl) implementation from pre-PEP threads in c.l.p last summer. But I have no place to upload it. I would also like if some people wants to co-author this PEP with me - it's really neither my PEP nor my module. -- mvh Björn ___ 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] New Pythondoc by effbot
Have you studied wikipedia's approach? It's multi-layered and worth learning from (start with their FAQ on editing). (And by the way, I am *not* advocating writing the docs as one big wikipedia -- only the user commentary.) to clarify, I'm advocating maintaining the docs via a restricted wiki-like system, and using a blog-style discussion board or a wiki to collect non- specific user commentary. Why does it have to be wiki-like? Why can't it be a wiki? MediaWiki seem to work pretty well for a lot of software projects that have put their documentation in a wiki. Talk pages for commentary and primary pages for reviewed content. -- mvh Björn ___ 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] Should the default equality operator compare values instead of identities?
How would the value equality operator deal with recursive objects? class Foo: def __init__(self): self.foo = self Seems to me that it would take atleast some special-casing to get Foo() == Foo() to evalute to True in this case... -- mvh Björn ___ 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] Adding a conditional expression in Py3.0
I did this for my favorite proposal, and ended up with the list shown further down below. I think they all looks great! The fact that so few were found in whole of the standard library does put the use case into question, though, no? Though I am sure more could be found with a more thorough scan. There's lots of code in it that looks like this: def __init__(self, foo = None): if foo is not None: self.foo = foo else: self.foo = self.getFooDefault() With if/else it can be written: def __init__(self, foo = None): self.foo = foo if foo is not None else self.getFooDefault() However, I'm convinced that the latter version is less readable than the former. Often the line becomes more than 80 characters so there's no gain in translating it to an if-else expression because you would still have to split the line, other times the condition is so complex that it deserves its own line. Many opportunities for uses, but atleast as many for abuses. -- mvh Björn ___ 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] Adding a conditional expression in Py3.0
I think I'd prefer (if expr then expr else expre) i.e. no colons. My problem with this syntax is that it can be hard to read: return if self.arg is None then default else self.arg looks worryingly like return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME That can already be written in Python: return self.arg or default And maybe the syntax of the future conditional operator could be extended so that: return self.arg else default Would be equivalent to the previous line. For stuff were a conditional expression really is needed, like in: return if self.arg then yes else no One would hope that whoever writes the conditional expression doesn't make the expressions so long and complicated that it looks like NAME NAME.NAME NAME... It doesn't matter which syntax proposal that wins, it will still be very tempting to write unreadable code with it (think nested/chained conditional expressions). That (and the fact that I've never felt a real need for a conditional expression thanks to the or operator) is my very humble argument against it. -- mvh Björn ___ 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] and and or operators in Py3.0
While you're at it, maybe we should switch to and || as well? That's another thing I always mistype when switching between languages... You're joking, surely? for Python 3000, I'd recommend switching to and then and or else instead of the current ambiguous single-keyword versions. Wouldn't it be possible to omit and and or to just then and else? x = 3 and 7 or 44 x = 3 and then 7 or else 44 x = 3 then 7 else 44 And then have another set of and and or for non short-circuiting? -- mvh Björn ___ 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] Replacement for print in Python 3.0
Something I've noticed from teaching C++ to newbies, is that you should NOT (never ever) start with cout Hello, world! endl;. You should start with printf(Hello, world\n); The cout thingy is impossible to explain to a newbie because it uses much underlying magic and has a very different behaviour from everything else a newbie sees in C++. It therefore causes lots of confusion. I wonder if the magic of print might have the same effect on newcomers to Python, whos first experience is print 'Hello, world!'... It would be very interesting to know. -- mvh Björn ___ 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] partition() (was: Remove str.find in 3.0?)
I like partition() but maybe even better would be if strings supported
slicing by string indices.
key, sep, val = 'foo = 32'.partition('=')
would be:
key, val = 'foo = 32'[:'='], 'foo = 32'['=':]
To me it feels very natural to extend Python's slices to string
indices and would cover most of partition()'s use cases. The if sep:
idiom of parition() could be solved by throwing an IndexError: e.g:
_, sep, port = host.partition(':')
if sep:
try:
int(port)
except ValueError:
becomes:
try:
port = host[':':]
int(port)
except IndexError:
pass
except ValueError:
An advantage of using slices would be that you could specify both a
beginning and ending string like this:
s
'http://192.168.12.22:8080'
s['http://':':']
'192.168.12.22'
Sorry if this idea has already been discussed.
--
mvh Björn
___
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] Chaining try statements: eltry?
I surely find them useful, and see them as a Python originality (a welcome one). They are indeed an original invention. (One day I looked at the similarity between if and while and noticed that there was a use case for else after while too.) The question remains whether Python would be easier to learn without them. And if so, the question would remain whether that's offset by their utility for experienced developers. All hard to assess impartially! I dislike them because I can never read looping constructs with else: without thinking hard about what it does. Like: for x in alist: if x == foo: break else: print foo was not found. Is a better way of doing: found = False for x in alist: if x == foo: found = True break if not found: print foo was not found. So the else: is taken if the break wasn't executed. I think that is hard to grasp because it makes the for and break into a kind of conditional statement where break makes it evalute to true. But I think the best way to code this silly example is to write: def finder(): for x in alist: if x == foo: return True return False if not finder(): print foo was not found. Which is how I write when someone else might had used a else. So IMHO, the use cases are weak. It's also confusing that try: has a different kind of else. else in try is a good thing - no exception occured. else in a for/while is (usually) a bad thing - as item was not found. -- mvh Björn ___ 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] Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python
*cough* Would it also be possible for the PEP-maintainers not to accept PEPs that are obvious jokes unless thedate is April I? *uncough* -- mvh Bjrn ___ 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] Wishlist: dowhile
do: block until cond Written like this it is not very obvious that the 'unil' is part of the do-until suite. I also imagine it to be difficult to parse and it breaks the rule that suites end when there is a dedentation. So, IMHO using an indented 'until' is the least evil of a number of evils. Not difficult to parse at all, nor un-Pythonic. Multi-part blocks abound in Python: if / elif / else, try / finally, etc. Oh. I had the impression that the reason do-while's (or do-until's which I like more) wasn't implemented in the language was because it was impossible to find an acceptable looking syntax. Yes, but grepping the stdlib produces over 300 hits for while 1: and while True: combined. Some of those a if cond: break in the middle and some would be better written as generators, but lots of them would be rewritten as do-while's. So I think there is more than enough use cases for syntactic sugar for do-while loops. The PEP 315 solution looks much better than an until that isn't what it looks like. What do you mean by that? The proposed until would work exactly like it do in languages that support until loops. I'm also reasonably happy with PEP 315, except that it seems to force you to end it with a pass if the condition is last in the loop. But is discussing do-while's beating a dead horse or is there a possibility that do-while's will someday make it into the language? -- mvh Björn ___ 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] Wishlist: dowhile
In contrast, the dowhile solution only takes about 30 seconds to get used to. Maybe that idea should follow the path of the genexp PEP, get rejected now, and then get resurrected as a bright idea two years from now. Or maybe not. nothing about foo here dowhile foo != 42: 10 lines of body foo = random.randint(1, 50) Now it becomes annoying because the name is visible long before it is bound to something. I would like to have do-while's like this: do: body until cond But I'm sure that has problems too. -- mvh Björn ___ 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] Wishlist: dowhile
do: body until cond But I'm sure that has problems too. [Raymond Hettinger] That looks nice to me. [Nick Coghlan] And this could easily be extended to allow code both before and after the 'until', giving a fully general loop: do: body-1-or-more-times until cond body-0-or-more-times else: on-natural-loop-exit Which is exactly like PEP 315 except there 'until' must be spelled 'while not' and the while is properly indented. (I'm still not sure whether BJörn *meant* the 'until' to be indented or whether he simply made a mistake; his proposal resembles a Pythonic version of Pascal's repeat-until, which would have an unindented until-clause.) Sorry, I should have made that clear. I *meant* for 'until' to be indented. I envisonaged it to be treatened similar to how the raise, pass and return statements work. Those statements are indented in a suite and they always end the current block. Well, technically you can write stuff like this: suite: block raise Exception block2 But 'block2' will always be dead code. Emacs, for example, always dedents when you write any of those three statements. The reason I suggested was not so that you could extend it to fully general loops like Nick suggested (which I can't comment on because I never use else: in looping constructs and always keep the condition check and the top or bottom), but because I thought that a dedented 'until' would be very hard to parse and in general look very unpythonic: do: block until cond Written like this it is not very obvious that the 'unil' is part of the do-until suite. I also imagine it to be difficult to parse and it breaks the rule that suites end when there is a dedentation. So, IMHO using an indented 'until' is the least evil of a number of evils. Why are you so excited about having until indented? You didn't give any examples with multiple occurrences. A single occurrence works just fine unindented, as PEP 315 has already shown. The indented until sounds like unnecessary syntactic sugar for 'if X: break' -- not very Pythonic. Yes, but grepping the stdlib produces over 300 hits for while 1: and while True: combined. Some of those a if cond: break in the middle and some would be better written as generators, but lots of them would be rewritten as do-while's. So I think there is more than enough use cases for syntactic sugar for do-while loops. -- mvh Björn ___ 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 340: Only for try/finally?
Guido How many try/finally statements have you written inside a loop? Guido In my experience this is extrmely rare. I found no Guido occurrences in the standard library. [Skip again] How'd we start talking about try/finally? Because it provides by far the dominant use case for 'block'. The block-statement is intended to replace many boilerplace uses of try/finally. In addition, it's also a coroutine invocation primitive. Maybe I'm not understanding something, but why should block only be for less boilerplate in try/finally's? I spent an hour grepping through the standard library and there are indeed lots of use cases for some blocks to replace try/finallys. There are opportunities for block opening(file) and block locked(mutex) everywhere! But why stop there? Lots of functions that takes a callable as argument could be upgraded to use the new block syntax. Because it is a cool way to do template method, isn't it? Take wrapper() in curses/wrapper.py for example. Why have it like this: wrapper(curses_wrapped_main) when you can have it like this: .block wrapper(): .(main program stuff) .(...) Or assertRaises in unittest.py, why call it like this: self.assertRaises(TypeError, lambda: a*x) When you can squash the lambda like this: .block self.assertRaises(TypeError): .a*x Or for another use case, in gl-code you often write glBegin().. glDrawBlah().. glEnd(). Make it properly indented!: .block glNowDraw():# glBegin(); yield; glEnd() .glDrawBlah() Make your own repeat-until loop: .def until(cond): .while True: .yield None .if cond: .break .block until(lambda: s == quit): .s = sys.stdin.readline() It seems like the possibilities are endless. Maybe too endless? Because this new feature is so similar to anonymous functions, but is not quite anonymous functions, so why not introduce anonymous functions instead, that could make all the things block can, and more? But as I said, I'm misunderstanding something. -- mvh Björn ___ 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] anonymous blocks
RSMotD (random stupid musing of the day): so I wonder if the decorator syntax couldn't be extended for this kind of thing. @acquire(myLock): code code code Would it be useful for anything other than mutex-locking? And wouldn't it be better to make a function of the block wrapped in a block-decorator and then use a normal decorator? -- mvh Björn ___ 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] Adding any() and all()
Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of (all) things. In my mind it doesn't make sense (yet) that all(seq) returns true if all elements of seq is true and false otherwise, I would have expected all to return a list. any is better because it is very obvious it can only return one thing. -- mvh Björn ___ 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] LinkedHashSet/LinkedHashMap equivalents
I would LOVE for **kwargs to be an ordered dict. It would allow me to write code like this: .class MyTuple: .def __init__(self, **kwargs): .self.__dict__ = ordereddict(kwargs) . .def __iter__(self): .for k, v in self.__dict__.items(): .yield v . .t = MyTuple(r = 99, g = 12, b = 4) .r, g, b = t .print r, g, b I know it goes beyond the original intention of the proposal, but I figure I'd mention it anyway because the unorder of **kwargs has been bugging me alot. -- mvh Björn ___ 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
