Re: [Python-Dev] conditional expressions - add parens?
Joe Smith wrote:
Steve Holden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Jim Jewett wrote:
I think that adding parentheses would help, by at least signalling that
the logic is longer than just the next (single) expression.
level = (0 if absolute_import in self.futures else -1)
Contrast with the bleeding obvious:
level = 0
if absolute_import in self.futures:
level = -1
or even, if a certain obscurity is desirable:
level = - (absolute_import in self.futures)
Wait a second.
I may be just a user but if the above is correct then that syntax needs to
die!
There is no logical reason for XX if YY else ZZ to be roughly equivlent
to:
if (YY) then {ZZ} else {XX} , but AFAICT that is pretty much the way you
expanded that.
I hope I misunderstood, or that there was a typo in a post.
There was a typo in the post.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd www.holdenweb.com
Love me, love my blog holdenweb.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] how about adding ping's uuid module to the standard lib ?
Fredrik Lundh wrote: see subject and http://python.org/sf/1368955 comments ? Fine with me. 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] conditional expressions - add parens?
On 3/6/06, Alex Martelli [EMAIL PROTECTED] wrote: On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression. level = (0 if absolute_import in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable. Recent language features seem to be suffereing from excessive parenthesisitis. I worry that people will stop remembering which expressions requirement parens in which context. Perhaps the solution is to require parens around all expressions, a simple consistent rule. If so, then adding parens around all statements is a fairly natural extension, which solves a number of problems like how to make a richer lambda. Jeremy ___ 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] conditional expressions - add parens?
On 3/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote: On 3/6/06, Alex Martelli [EMAIL PROTECTED] wrote: On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression. level = (0 if absolute_import in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable. Recent language features seem to be suffereing from excessive parenthesisitis. Agreed. Mandatory parentheses purely for readability are ultimately futile - I bet I can write unreadable code even if the parens were required :-) The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed. +0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general code should be readable in my view. Paul. ___ 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] conditional expressions - add parens?
Paul Moore wrote: On 3/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote: On 3/6/06, Alex Martelli [EMAIL PROTECTED] wrote: On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression. level = (0 if absolute_import in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable. Recent language features seem to be suffereing from excessive parenthesisitis. Agreed. Mandatory parentheses purely for readability are ultimately futile - I bet I can write unreadable code even if the parens were required :-) The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed. +0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general code should be readable in my view. Agreed - and often the best way to make a conditional expression readable is to not use it in the first place, which is a concept that an official policy on parentheses may mask. And then there's the question of how to parenthesise chained conditional expressions. Mandatory parentheses in that case would make me wonder if I was writing a certain language that isn't Python. . . Given that the main reason PEP 308 was finally implemented was to provide OOWTDI for conditional expressions (instead of the handful of not-at-all-obvious and not-quite-right-either workarounds that had developed in their absence), I expect to see of rush of enthusiastic overuse of the new expression, which will eventually settle down as everyone remembers that not every problem is a nail to be hit with the shiny new hammer ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
[Python-Dev] as mania
Hi, while as is being made a keyword, I remembered parallels between with and a proposal made some time ago: with expr as f: do something with f while expr as f: do something with f if expr as f: do something with f elif expr as f: do something else with f What do you think? Georg ___ 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 mania
I suggest you file those as products of an overactive imagination. :-) Have you even tried to define precise semantics for any of those, like the expansion of with E as V: B in PEP 343? --Guido On 3/7/06, Georg Brandl [EMAIL PROTECTED] wrote: Hi, while as is being made a keyword, I remembered parallels between with and a proposal made some time ago: with expr as f: do something with f while expr as f: do something with f if expr as f: do something with f elif expr as f: do something else with f What do you think? Georg ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 mania
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote: Hi, while as is being made a keyword, I remembered parallels between with and a proposal made some time ago: with expr as f: do something with f while expr as f: do something with f if expr as f: do something with f elif expr as f: do something else with f What do you think? I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C, while ( (x=next_x()) threshold ) ... being able to capture (by `as') only the whole (true or false) condition meets a minority of the use cases, so I'm unenthusiastic about it. Alex ___ 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] conditional expressions - add parens?
On 3/7/06, Paul Moore [EMAIL PROTECTED] wrote: The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed. The out-of-order evaluation is a very large change, because now we have a situation where normal parsing completes an expression, but needs to avoid evaluating it, just in case. Currently, we can write: if False: print r else: print 6 6 r Traceback (most recent call last): File pyshell#14, line 1, in -toplevel- r NameError: name 'r' is not defined In the above example, r doesn't get evaluated because the if ahead of it says to skip that branch. But with conditional expressions, that flow control is changed from *later* in the program. I don't think we'll see the equivalent of Intercal Suck Points anywhere but intentionally obfuscated code, but I do expect to see: side_effect() if condition In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me You're not done yet; keep reading. ack(r,r) if r not in cache log(message) if error_flag -jJ ___ 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] conditional expressions - add parens?
Jim Jewett wrote: On 3/7/06, Paul Moore [EMAIL PROTECTED] wrote: The parentheses around genexps were (AFAICT) different - without them, the grammar was ambiguous, so some way of disambiguating was needed. The out-of-order evaluation is a very large change, because now we have a situation where normal parsing completes an expression, but needs to avoid evaluating it, just in case. Currently, we can write: if False: print r else: print 6 6 r Traceback (most recent call last): File pyshell#14, line 1, in -toplevel- r NameError: name 'r' is not defined In the above example, r doesn't get evaluated because the if ahead of it says to skip that branch. But with conditional expressions, that flow control is changed from *later* in the program. I don't think we'll see the equivalent of Intercal Suck Points anywhere but intentionally obfuscated code, but I do expect to see: side_effect() if condition In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me You're not done yet; keep reading. ack(r,r) if r not in cache log(message) if error_flag I think you've misunderstood the nature of the change. HTe new conditionals are *expressions*, they aren't postfix conditionals for statements. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.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] conditional expressions - add parens?
On Mar 7, 2006, at 7:29 AM, Steve Holden wrote: ... In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me You're not done yet; keep reading. ack(r,r) if r not in cache log(message) if error_flag I think you've misunderstood the nature of the change. HTe new conditionals are *expressions*, they aren't postfix conditionals for statements. Right, but the only effect of that on the examples is that they both need an 'else None' continuation or thereabouts. I also predict widespread over-use of the new toy and agree with Jim that mandatory parentheses around the whole (X if Y else Z) construct would ameliorate legibility a bit. Alex ___ 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] Scientific Survey: Working Conditions in Open Source Projects
We like to invite you to a survey about the working conditions in Free/Open-Source Software development. This survey is conducted by the Open-Source Research Group of the University of Würzburg (Germany). We will compare work design in open source and proprietary software development. Our findings should be used to adjust the working conditions of software development to the needs of the developers. The results will be published under the Creative Commons License. To start the survey, please follow the link: http://www.unipark.de/uc/open-source-task/ If you have any questions don't hesitate to contact us! Dirk Jendroska http://www.psychologie.uni-wuerzburg.de/ao/staff/jendroska.php?lang=en ___ 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] how about adding ping's uuid module to the standard lib ?
At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
see subject and http://python.org/sf/1368955
comments ?
Why can't the UUIDs be immutable, so they can be dictionary keys? Also, it
would be nice if you could just call UUID() to create a generic UUID in a
platform-appropriate way. PEAK's uuid module does this such that if
win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or
NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.:
http://svn.eby-sarna.com/PEAK/src/peak/util/_uuidgen.c?view=markup
and:
http://svn.eby-sarna.com/PEAK/src/peak/util/uuid.py?view=markup
for details. This implementation also has unit tests:
http://svn.eby-sarna.com/PEAK/src/peak/util/tests/uuid.py?view=markup
and has been in production use for several years now.
On the other hand, Ping's implementation is a lot simpler than ours; ours
does a lot of stuff to support e.g. /dev/urandom or fallback seeding,
whereas Python 2.4 offers os.urandom. We also use different fallback
algorithms for getting the MAC address, including a fallback to a
randomly-generated address if a system one could not be obtained. Ping's
version will fail if there is no way to get the address (e.g. on Windows
9X, which has no ipconfig.exe), and does not cache the address for repeated
uses, making its generation of verion-1 UUIDs *very* expensive.
I like the idea of having RFC-compliant UUIDs in the stdlib, but I really
want immutable ones, preferably without {} in their standard string
representation. And efficient use of platform-local UUID generation APIs
would also be preferable. (Note that using the Windows C API for UUIDs
would make it unnecessary to execute a separate program in order to get
version 1 UUIDs, and the same is true for the BSD variants with a UUID API.)
(In addition to the PEAK UUID implementation, OSAF's Chandler also has a
compliant UUID implementation that's written entirely in C, but I haven't
played with it much. I don't know whether it supports using platform APIs
for generation, but it does implement hashable, immutable UUID objects.)
___
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] how about adding ping's uuid module to the standard lib ?
On 3/7/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote: see subject and http://python.org/sf/1368955 comments ? would be nice if you could just call UUID() to create a generic UUID in a platform-appropriate way. PEAK's uuid module does this such that if win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: Given that ctypes is going to be in Python 2.5, it might be reasonable to use it to access platform-specific APIs like this. It certainly makes some sense for Windows, where running an external process is slow, and the existence of suitable external utilities (and the format of their output!) is unreliable... (I haven't looked at the code, so I don't know if this applies to Ping's use of ipconfig). Paul ___ 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] _bsddb.c ownership
Who 'owns' Modules/_bsddb.c, if anyone? The file doesn't mention whether it's a fork of pybsddb maintained separately or not. I ask because it seems to contain a number of refleaks, and I wanted to fix some of the style issues while I'm at it (and maybe even Py_ssize_t it,) but I'll happily send the patch to pybsddb instead. (Georg and I already checked in some fixes, anyway.)-- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] how about adding ping's uuid module to the standard lib ?
Having UUID in the stdlib would be very helpful.
Philip Eby writes:
I like the idea of having RFC-compliant UUIDs in the stdlib, but I really
want immutable ones, preferably without {} in their standard string
representation. And efficient use of platform-local UUID generation APIs
would also be preferable.
I completely agree with Philip.
Bill
___
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] how about adding ping's uuid module to the standard lib ?
Philip Eby writes: ... I completely agree with Philip. Sorry, I mean of course Phillip. Bill ___ 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 mania
[HPH the BDFL] I suggest you file those as products of an overactive imagination. :-) At least not only mine. ;) Have you even tried to define precise semantics for any of those, like the expansion of with E as V: B in PEP 343? Easily. if expr as name: BLOCK would be equivalent to name = expr if name: BLOCK del name Same for while. Georg ___ 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 mania
On 3/7/06, Georg Brandl [EMAIL PROTECTED] wrote: Have you even tried to define precise semantics for any of those, like the expansion of with E as V: B in PEP 343? Easily. if expr as name: BLOCK would be equivalent to name = expr if name: BLOCK del name You need to be a little more formal. What happens when there are elif or else clauses? Why the del at all? (with doesn't delete VAR). You also need to present a better motivation. What would be the point of having a separate name for the value True or False when you already know its value based on which branch you execute? And what exactly is the big savings? If you look at the motivation for with E as V, V is *not* assigned the value of E (but rather E.__context__().__enter__()) and the with statement as a whole has a very good reason for its existence. Your proposal here lacks that. Same for while. You aren't really trying, are you? What would the point be of NAME = EXPR while NAME: BLOCK del NAME (Hint: while needs EXPR to be reevaluated each time through the loop.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 mania
Alex Martelli wrote: I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C, while ( (x=next_x()) threshold ) ... being able to capture (by `as') only the whole (true or false) condition meets a minority of the use cases, so I'm unenthusiastic about it. There are use cases (because every value can be tested for true-ness), such as the likes of while file.readline() as line: BLOCK (which is not needed for builtin file objects, I know) or something like m = re.match(...) if m.group(1) as filename: do something with filename Georg ___ 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 mania
Georg Brandl [EMAIL PROTECTED] wrote: or something like m = re.match(...) if m.group(1) as filename: do something with filename Except that m could be None, which would raise an exception during the .group(1) call. Perhaps you meant... m = re.match(...) if m and m.group(1) as filename: do something with filename I'm -1 on the 'as'-itis. - Josiah ___ 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 mania
Guido van Rossum wrote: On 3/7/06, Georg Brandl [EMAIL PROTECTED] wrote: Have you even tried to define precise semantics for any of those, like the expansion of with E as V: B in PEP 343? Easily. if expr as name: BLOCK would be equivalent to name = expr if name: BLOCK del name You need to be a little more formal. What happens when there are elif or else clauses? Why the del at all? (with doesn't delete VAR). You also need to present a better motivation. What would be the point of having a separate name for the value True or False when you already know its value based on which branch you execute? And what exactly is the big savings? If you look at the motivation for with E as V, V is *not* assigned the value of E (but rather E.__context__().__enter__()) and the with statement as a whole has a very good reason for its existence. Your proposal here lacks that. Thinking over it, this is too much a difference between the with-as and my as, so I'm abandoning this idea. My as would just have been a shortcut to avoid writing longish expressions that have to be checked for true-ness and then tinkered with. Same for while. You aren't really trying, are you? No ;) I would have written a PEP anyway. Cheers, Georg ___ 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 mania
Thinking over it, this is too much a difference between the with-as and my as, so I'm abandoning this idea. My as would just have been a shortcut to avoid writing longish expressions that have to be checked for true-ness and then tinkered with. ML has a similar feature, which you may consider as an argument either for or against it depending on your taste. The point is that ML lets you write patterns that decompose data structures, and the as usage lets you talk about the whole data structure and the decomposed one at the same time. For example, in ML, :: works like cons in Lisp, so that x::y is a list with a first element of x and a tail of y, which must be a list. In other words, [3, 4, 5] is equivalent to (3::4::5::nil) in ML. Now consider the following: fun merge(nil, y) = y | merge(x, nil) = x | merge (x as xh::ht, y as yh::yt) = if xh yh then xh::merge(xt, y) else xt::merge(x, yt) Without the as clause, we would have had to write fun merge(nil, y) = y | merge(x, nil) = x | merge(x, y) = let val xh::xt = x val yh::yt = y in if xh yh then xh::merge(xt, y) else xt::merge(x, yt) end which is somewhat longer and harder to follow. As it turns out, Python has similar ways of decomposing data structures: (x, y) = foo or def bar((x, y)): # etc. and I have sometimes wished I could write z as (x, y) = foo or def bar(z as (x, y)): # etc. However, it's not real high on my list of priorities, and I suspect that many Pythonists consider these usages to be a frill anyway. ___ 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] _bsddb.c ownership
Thomas Wouters wrote: Who 'owns' Modules/_bsddb.c, if anyone? It's a fork of pybsddb, originally contributed by Gregory Smith (*). For all practical purposes, he also owns it, but hasn't objected to others making changes in the past. At the time it was imported, I recall the plan was to out-phase pybsddb, and only keep the version in Python. It appears that things have developed differently. http://mail.python.org/pipermail/python-dev/2002-June/025616.html http://mail.python.org/pipermail/python-dev/2002-June/025806.html http://mail.python.org/pipermail/python-dev/2002-October/029788.html http://mail.python.org/pipermail/python-dev/2002-November/030247.html Regards, Martin (*) although I did the original import. ___ 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 mania
On 3/7/06, Andrew Koenig [EMAIL PROTECTED] wrote: As it turns out, Python has similar ways of decomposing data structures: (x, y) = foo or def bar((x, y)): # etc. and I have sometimes wished I could write z as (x, y) = foo or def bar(z as (x, y)): # etc. However, it's not real high on my list of priorities, and I suspect that many Pythonists consider these usages to be a frill anyway. For the assignment case, you can do this: foo = (1,2) (x,y) = z = foo x 1 y 2 z (1, 2) Function arguments are not covered by this trick, but def bar(z): (x,y) = z probably isn't too much overhead... (Or did I miss your point?) Paul. ___ 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 mania
Function arguments are not covered by this trick, but def bar(z): (x,y) = z probably isn't too much overhead... It's not the machine overhead, it's the intellectual overhead. I know there are some who will disagree with me, but I would find it easier to read def foo(origin as (x1, y1), corner as (x2, y2)): than to read def foo(origin, corner): (x1, y1) = origin (x2, y2) = corner It's not a big deal, but it is not completely negligible either. ___ 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] str(Exception) changed, is that intended?
I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z ___ 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] str(Exception) changed, is that intended?
On 3/7/06, Thomas Heller [EMAIL PROTECTED] wrote: I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z It's a side-effect of making built-in exceptions new-style classes. Not sure how you would override the string representation of a class anyway to fix this. -Brett ___ 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] how about adding ping's uuid module to the standard lib ?
Paul Moore wrote: On 3/7/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote: see subject and http://python.org/sf/1368955 comments ? would be nice if you could just call UUID() to create a generic UUID in a platform-appropriate way. PEAK's uuid module does this such that if win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: Given that ctypes is going to be in Python 2.5, it might be reasonable to use it to access platform-specific APIs like this. It certainly makes some sense for Windows, where running an external process is slow, and the existence of suitable external utilities (and the format of their output!) is unreliable... (I haven't looked at the code, so I don't know if this applies to Ping's use of ipconfig). IMO that is a perfect use-case for ctypes - access 2 or 3 platform-specific api functions. Too bad that ctypes whill be an optional module, so I'm not sure if it could be used in the Python library itself. Thomas ___ 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] how about adding ping's uuid module to the standard lib ?
On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote: Too bad that ctypes whill be an optional module, so I'm not sure if it could be used in the Python library itself. try: import ctypes except ImportError: def fallback(): ... else: def real_thing(): ... 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] how about adding ping's uuid module to the standard lib ?
Oleg Broytmann wrote: On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote: Too bad that ctypes whill be an optional module, so I'm not sure if it could be used in the Python library itself. try: import ctypes except ImportError: def fallback(): ... else: def real_thing(): ... Personally, I don't like standard modules to behave different if I install other stuff, so please change 'could' to 'should' in this sentence: not sure if it could be used in the Python library itself. ___ 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] str(Exception) changed, is that intended?
On 3/7/06, Brett Cannon [EMAIL PROTECTED] wrote: On 3/7/06, Thomas Heller [EMAIL PROTECTED] wrote: I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z It's a side-effect of making built-in exceptions new-style classes. Not sure how you would override the string representation of a class anyway to fix this. IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] quit() on the prompt
Frederick suggested a change to quit/exit a while ago, so it wasn't just
a string with slight instructional purpose, but actually useful. The
discussion was surprisingly involved, despite the change really trully
not being that big. And everyone drifted off, too tired from the
discussion to make a change. I suppose it didn't help that the original
proposal struck some people as too magic, while there were some more
substantive problems brought up as well, and when you mix aesthetic with
technical concerns everyone gets all distracted and worked up. Anyway,
I would like to re-propose one of the ideas that came up (originally
from Ping?):
class Quitter(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return 'Use %s() to exit' % self.name
def __call__(self):
raise SystemExit()
quit = Quitter('quit')
exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current
behavior. It does not satisfy the just do what I said argument for
not requiring the call (quit() not quit), but eh -- I guess it seemed
like everything that didn't require a call had some scary corner case
where the interpreter would abruptly exit.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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] quit() on the prompt
Works for me.
On 3/7/06, Ian Bicking [EMAIL PROTECTED] wrote:
Frederick suggested a change to quit/exit a while ago, so it wasn't just
a string with slight instructional purpose, but actually useful. The
discussion was surprisingly involved, despite the change really trully
not being that big. And everyone drifted off, too tired from the
discussion to make a change. I suppose it didn't help that the original
proposal struck some people as too magic, while there were some more
substantive problems brought up as well, and when you mix aesthetic with
technical concerns everyone gets all distracted and worked up. Anyway,
I would like to re-propose one of the ideas that came up (originally
from Ping?):
class Quitter(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return 'Use %s() to exit' % self.name
def __call__(self):
raise SystemExit()
quit = Quitter('quit')
exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current
behavior. It does not satisfy the just do what I said argument for
not requiring the call (quit() not quit), but eh -- I guess it seemed
like everything that didn't require a call had some scary corner case
where the interpreter would abruptly exit.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] str(Exception) changed, is that intended?
On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? -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] str(Exception) changed, is that intended?
On 3/7/06, Barry Warsaw [EMAIL PROTECTED] wrote: On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? Anything that depends on the differences in behavior between classic and new-style classes, e.g. multiple inheritance if the inheritance graph contains a diamond, or type(exc) having a specific value (namely, the metaclass for classic classes), or certain broken behaviors (like read-only properties not being really read-only). It's hard to make a complete list. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Ian Bicking wrote:
class Quitter(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return 'Use %s() to exit' % self.name
def __call__(self):
raise SystemExit()
quit = Quitter('quit')
exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current
behavior. It does not satisfy the just do what I said argument for
not requiring the call (quit() not quit), but eh -- I guess it seemed
like everything that didn't require a call had some scary corner case
where the interpreter would abruptly exit.
It also nicely aligns with the way that license() and help() already work at
the interactive prompt.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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] 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] quit() on the prompt
I am probably the biggest proponent of magic variables, but this just
won't work.
First, commands and lines are not the same thing, so:
print \
exit
breaks your propossal.
Second, quit and exit are bindable variables, and you need to be sure
that they still mean _quit_, and not something else.
On 3/7/06, BJörn Lindqvist [EMAIL PROTECTED] wrote:
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/crutcher%40gmail.com
--
Crutcher Dunnavant [EMAIL PROTECTED]
littlelanguages.com
monket.samedi-studios.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] quit() on the prompt
BJörn Lindqvist wrote:
do {
cmd = readline()
do_stuff_with_cmd(cmd);
} while (!strcmp(cmd, quit));
printf(Bye!);
exit(0);
KISS?
I believe there were concerns that rebinding quit would cause strange
behavior. E.g.:
quit = False
while not quit: ...
quit
$
Or:
if raw_input('quit?') == 'yes':
... quit
will that work? Should it? Functions are pretty predictable in
comparison to these other options. So, at least to me, quit() == KISS
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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] quit() on the prompt
On 3/7/06, Ian Bicking [EMAIL PROTECTED] wrote:
Frederick suggested a change to quit/exit a while ago, so it wasn't just
a string with slight instructional purpose, but actually useful. The
discussion was surprisingly involved, despite the change really trully
not being that big. And everyone drifted off, too tired from the
discussion to make a change. I suppose it didn't help that the original
proposal struck some people as too magic, while there were some more
substantive problems brought up as well, and when you mix aesthetic with
technical concerns everyone gets all distracted and worked up. Anyway,
I would like to re-propose one of the ideas that came up (originally
from Ping?):
class Quitter(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return 'Use %s() to exit' % self.name
def __call__(self):
raise SystemExit()
quit = Quitter('quit')
exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current
behavior. It does not satisfy the just do what I said argument for
not requiring the call (quit() not quit), but eh -- I guess it seemed
like everything that didn't require a call had some scary corner case
where the interpreter would abruptly exit.
+1 from me. Only change I would make is pass an argument to
SystemExit() such as %s() called, although the chances of this
exception being caught is very slim.
-Brett
___
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
On 3/8/06, Brett Cannon [EMAIL PROTECTED] wrote:
On 3/7/06, Ian Bicking [EMAIL PROTECTED] wrote: class Quitter(object):def __init__(self, name):self.name
= namedef __repr__(self):return 'Use %s() to exit' % self.namedef __call__(self):raise SystemExit() quit = Quitter('quit')
exit = Quitter('exit')+1 from me.Only change I would make is pass an argument toSystemExit() such as %s() called, although the chances of thisexception being caught is very slim.
Raising SystemExit(quit() called) has an additional benefit (although the wording could use some work): raise SystemExit(quit() called)quit() called
(At least, I consider that a benefit :-)-- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] str(Exception) changed, is that intended?
On 3/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/7/06, Barry Warsaw [EMAIL PROTECTED] wrote: On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? Anything that depends on the differences in behavior between classic and new-style classes, e.g. multiple inheritance if the inheritance graph contains a diamond, or type(exc) having a specific value (namely, the metaclass for classic classes), or certain broken behaviors (like read-only properties not being really read-only). It's hard to make a complete list. Right, stuff dealing with the type could break. Instance-related stuff dealing with the interface will continue to work as expected and be fully backwards-compatible (unless someone complains about now having a proper __unicode__ method, in which case it will definitely go in one ear and out the other for me). -Brett ___ 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] quit() on the prompt
Ian reproposed: class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() The one change I would suggest is the string used in repr. Some of the objections to the current behavior boil down to If it knows what I mean, why didn't it do it? We probably can't explain first-class callables in a short message, but we could emphasize that it has to be *call*ed. Perhaps def __repr__(self): return 'Calling %s() will exit python' % self.name -jJ ___ 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] conditional expressions - add parens?
Paul Moore wrote: +0 for mentioning parens around conditional expressions in PEP 8. But it's aready covered by the general code should be readable in my view. Indeed. Writing readable code is ultimately the responsibility of the person doing the writing. It's enough that you *can* put parentheses around things if it helps readability. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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 mania
Alex Martelli wrote: On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote: with expr as f: do something with f I expect the with example here is a red herring, not intended to have anything to do with the new with statement that's just been added. I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C, while ( (x=next_x()) threshold ) ... IIUC, that would be while (next_x() as x) threshold: ... i.e. 'x as y' would be an expression. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] conditional expressions - add parens?
Greg Ewing wrote: Jeremy Hylton wrote: Perhaps the solution is to require parens around all expressions, a simple consistent rule. I actually designed a language with that feature once. It was an exercise in minimality, with hardly anything built-in -- all the arithmetic operators, etc. were defined in the language. A result was that there was no built-in notion of precedence, and my solution was to require parentheses around every infix operation. So instead of dsq = b * b - 4 * a * c you would have had to write dsq = ((b * b) - ((4 * a) * c)) I never got an implementation working well enough to find out how much of a disaster this would have been to use, though. :-) I already do that anyway, and even update other people's code in any open-source projects I contribute to, because I find it *far* easier to read and write 'unnecessary' parens than remember precedence rules. But I can understand why some people would balk at it, so +0.5 from me. ;) Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ 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] _bsddb.c ownership
On 3/7/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Wouters wrote: Who 'owns' Modules/_bsddb.c, if anyone?It's a fork of pybsddb, originally contributed by Gregory Smith (*).For all practical purposes, he also owns it, but hasn't objected to others making changes in the past.At the time it was imported, I recall the plan was to out-phasepybsddb, and only keep the version in Python. It appears that thingshave developed differently. Alright. It seems someone wink already made backward-incompatible changes to _bsddb.c (adding Py_ssize_t use), and various other things were fixed, too, so I just went ahead and checked in a bunch of small fixes. I'm not done yet, though. After I am done (which might be a while still, but hopefully before alpha1), I'll fix backward compatibility and send in a patch to the pybsddb project :) -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Long-time shy failure in test_socket_ssl
On 2/27/06, Tim Peters [EMAIL PROTECTED] wrote: Neal plugged another hole later, but-- alas --I have seen the same shy failure since then on WinXP. One of the most recent buildbot test runs saw it too, on a non-Windows box: http://www.python.org/dev/buildbot/trunk/g5%20osx.3%20trunk/builds/204/step-test/0 test_socket_ssl test test_socket_ssl crashed -- exceptions.TypeError: 'NoneType' object is not callable in the second test run there. For closure, I believe this problem was addressed by revs 42842 and 42844 to Lib/test/test_importhooks.py. If anyone sees spurious failures with the buildbot (one time failures, crashes, etc), please report the problems to python-dev. It would be great to see if you can reproduce the results with the same tests that failed. We need to determine if it is architecture specific, test-order related, or something else. n ___ 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
