Re: [Python-Dev] Floor division
On Wednesday 24 January 2007 08:39, Alexey Borzenkov wrote: [me, about complex():] It seems pretty clear what it thinks it's doing -- namely, defining complex(a,b) = a + ib even when a,b are complex. And half of why it does that is clear: you want complex(a)=a when a is complex. Why b should be allowed to be complex too, though, it's hard to imagine. [Alexey:] I think that's the right thing to do, because that is mathematically correct. j is just an imaginary number with a property that j*j = -1. So (a+bj) + (c+dj)j = (a-d) + (b+c)j. Yes, thanks, I know what j is, and I know how to multiply complex numbers. (All of which you could have deduced from reading what I wrote, as it happens.) The question is whether it makes sense to define complex(a,b) = a+ib for all a,b or whether the two-argument form is always in practice going to be used with real numbers[1]. If it is, which seems pretty plausible to me, then changing complex() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. [1] For the avoidance of ambiguity: real is not synonymous with double-precision floating-point. Complex numbers are not just magic pairs with two numbers and have actual mathematical rules. Gosh, and there I was thinking that complex numbers were magic pairs where you just make stuff up at random. Silly me. -- Gareth McCaughan PhD in pure mathematics, University of Cambridge ___ 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] Floor division
On Wednesday 24 January 2007 10:20, Alexey Borzenkov wrote: I think that's the right thing to do, because that is mathematically correct. j is just an imaginary number with a property that j*j = -1. So (a+bj) + (c+dj)j = (a-d) + (b+c)j. Yes, thanks, I know what j is, and I know how to multiply complex numbers. (All of which you could have deduced from reading what I wrote, as it happens.) The question is whether it makes sense to define complex(a,b) = a+ib for all a,b or whether the two-argument form is always in practice going to be used with real numbers[1]. If it is, which seems pretty plausible to me, then changing complex() to complain when passed two complex numbers would (1) notify users sooner when they have errors in their programs, (2) simplify the code, and (3) avoid the arguably broken behaviour Tim was remarking on, where complex(-0.0).real is +0 instead of -0. Haven't looked in source code for complex constructor yet, but I think that if it changes sign of -0.0 then it just does something wrong and needs fixing without change in behaviour. Maybe it could check if numbers it got on input are real or complex and proceed accordingly so that it never gets to computing -0.0-(+0.0), i.e. when second argument is not a complex number it could just add it to imaginary part of first argument, but skip substracting inexistant 0.0 from first argument's real part. Change of behaviour like ignoring imaginary part of second argument seems bad to me, and that's my only point. Besides, documentation (at least for Python 2.4) clearly states that second argument can be a complex number: I'm not suggesting that it should ignore the imaginary part of the second argument, and I don't think anyone else is either. What might make sense is for passing a complex second argument to raise an exception. (I don't particularly object to the present behaviour either.) The fact that the documentation states explicitly that the second argument can be a complex number is probably sufficient reason for not changing the behaviour, at least before 3.0. -- g ___ 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] Floor division
On Tuesday 23 January 2007 07:01, Tim Peters wrote: complex_new() ends with: cr.real -= ci.imag; cr.imag += ci.real; and I have no idea what that thinks it's doing. Surely this isn't intended?!: complex(complex(1.0, 2.0), complex(10.0, 20.0)) (-19+12j) WTF? In any case, that's also what's destroying the sign of the imaginary part in complex(1.0, -0.0). It seems pretty clear what it thinks it's doing -- namely, defining complex(a,b) = a + ib even when a,b are complex. And half of why it does that is clear: you want complex(a)=a when a is complex. Why b should be allowed to be complex too, though, it's hard to imagine. -- g ___ 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: Adding data-type objects to Python
It might be better not to consider bit to be a type at all, and come up with another way of indicating that the size is in bits. Perhaps 'i4' # 4-byte signed int 'i4b' # 4-bit signed int 'u4' # 4-byte unsigned int 'u4b' # 4-bit unsigned int I like this. Very nice. I think that's the right way to look at it. I remark that 'ib4' and 'ub4' make for marginally easier parsing and less danger of ambiguity. -- g ___ 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] [slighly OT] Native speakers and hurting brains
(Attention conservation notice: the following is concerned almost entirely
with exegesis of an old python-dev thread. Those interested in improving Python
and not in history and exegesis should probably ignore it.)
On Tuesday 2006-07-11 13:43, Boris Borcic wrote:
I believe that in this case native linguistic intuition made the
decision...
The reason has nothing to do with language. Guido didn't
want sum() to become an attractive nuisance by *appearing*
to be an obvious way of joining a list of strings, while
actually being a very inefficient way of doing that.
sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way
of
chaining strings in a list (without actually being one).
It is a *short-term* attractive nuisance; anyone who tries it
will quickly find that it can't be used to sum strings;
whereas if this functionality of sum() had been retained
then users would much more readily have been led to use it
*and leave it in their programs*, to the detriment of their
efficiency.
Considerable effort was put into trying to make sum()
smart enough to detect when you were using it on a
list of strings and do .join behind the scenes, but
Guido decided in the end that it wasn't worth the
trouble, given that he only ever intended sum() to
be used on numbers in the first place.
That's not quite conform to the record. According to py-dev archives it
happened
on April 2003 with a thread Fwd: summing a bunch of numbers (or
whatevers)
initiated by Alex Martelli where he actually proposed a working
implementation
of sum() in C, that did short-circuit the case of strings to ''.join. That
was
Sat 19th of April.
Debate ensued, and by late Sunday 20th around 11PM;, the honorable author of
the
Zen of Python had killed that use case for sum() with
sum(sequence_of_strings)
hurts my brain. (Hello Tim, so what about sqrt(':(') ?)
Hardly killed, since discussion of sum(stringseq) continued after
Tim's comment, and since Tim was neither the only, nor the first, nor
(I think) the last, person to object to sum(stringseq).
Guido's first intervention in the thread was the next morning, and the two
very
first lines of his intervention where :
OK, let me summarize and pronounce.
sum(sequence_of_strings) is out
I admit that there is a step of arguable interpretation from these recorded
facts to my diagnostic, but the latter is compatible with the facts. Your
version otoh looks more robust in the role of eg creation myth.
Your interpretation is only compatible with the facts by means
of the hypothesis that Guido, despite saying OK, let me summarize
and pronounce (which, incidentally, was the *actual* opening of
that message, which was not Guido's first intervention in the
thread, but who cares about facts?), had only read Tim Peters's
message and not the rest of the thread. Including, for instance,
one of the last messages before Guido's, from Alex, reporting that
his sum() concatenated strings twice as slowly as ''.join. It also
requires one to ignore the fact that Guido said (in that same
message that you described as his first intervention)
| OTOH if we provide *any* way of providing a
| different starting point, some creative newbie is going to use
| sum(list_of_strings, ) instead of .join(), and be hurt by the
| performance months later.
and the fact that in Guido's *actual* first intervention he
said that he found sum(stringseq) weird and would continue to
use ''.join. (Remark: Guido is not a native speaker of English,
though he's a very competent one.) For that matter, Tim's
comment about sum(stringseq) hurting his brain was in direct
response to another part of that same message from Guido in
which he said that the name sum() strongly suggests that it's
summing up numbers. (Remark: Guido still isn't a native speaker
of English.)
Perhaps the fact that sum isn't a natural English term for
concatenation of strings -- which, indeed, it isn't -- was one
of his reasons; it demonstrably wasn't the only one; and it
seems to have been the non-native speaker Guido himself who
introduced that consideration to the discussion.
It appears to me that your interpretation is difficult to reconcile
with the facts and is based on an incorrect and narrow reading of the
original texts. What was that you were saying about creation myths?
(I agree that Greg's interpretation is also not well supported
by that thread; I don't know whether Guido later said anything
that would determine how much truth there is in it. Since sum()
was Alex Martelli's invention, it seems unlikely that Greg's
quite right.)
--
g
___
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
But only if it makes sense. I still think there are some severe conceptual difficulties with 0D arrays. One is the question of how many items it contains. With 1 or more dimensions, you can talk about its size along any chosen dimension. But with 0 dimensions there's no size to measure. Who's to say a 0D array has a size of 1, then? Part of my brain keeps saying it should be 0 -- i.e. it contains nothing at all! For what it's worth (probably little), I'm fairly sure that if you were to ask the question of a bunch of mathematicians you'd get absolute unanimity on a 0-D array containing exactly one element, indexed by the (unique) empty sequence. You'd probably also get absolute unanimous puzzlement as to why anyone other than mathematicians should care. I'd say there are conceptual difficulties in the sense that the concept is difficult to get one's head around, not in the sense that there's any real doubt what the Right Answer is. For anyone unconvinced, it may or may not be helpful to meditate on the fact that anything**0 is 1, and that an empty product is conventionally defined to be 1. None of the above is intended to constitute argument for or against Noam's proposed change to Python. Python isn't primarily a language for mathematicians, and so much the better for Python. -- Gareth McCaughan (unashamed pure mathematician, at least by training and temperament) ___ 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] PySet API
Terry Reedy wrote: [me:] For what it's worth[1], I think Raymond is absolutely on crack here. [Greg Ewing:] +1 on a good concrete set API from me, too. [Terry:] For what it's worth, I think Gareth's crack at Raymond is childish and out of place here. Er, it wasn't a crack at Raymond, it was a crack at a particular position he's taking on a particular issue. What I intended (but may have failed) to convey was: Raymond's a clever and sensible chap, and this is a very weird position for a clever and sensible person to be taking: must be the drugs. And, just in case it's still not clear, I wasn't in fact suggesting that Raymond *is* on drugs either. However: if Raymond, or anyone else, is offended, then I'm sorry. Now, what about the technical issues, as opposed to the way I happened to introduce my comments? -- g ___ 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] PySet API
We're clearly going in circles here, and it's obvious we're not going to agree. The fact that PySet_Next() can be used incorrectly is no reason not to include it. [etc] For what it's worth[1], I think Raymond is absolutely on crack here. [1] Not necessarily very much. There is none of my code in Python, so far as I know. * Simple API: The complexity of an API is not determined by the number of methods in it but by the variety of different things you can ask it to do, and it's not any simpler to have PyObject_CallMethod(x, foo) PyObject_CallMethod(x, bar) PyObject_CallMethod(x, baz) than to have PyObject_foo(x) PyObject_bar(x) PyObject_baz(x) API complexity is measured in brain cells, not in methods. * Ease of making mistakes: The Python API is absolutely stuffed with places where you can go wrong by forgetting about subtle refcounting issues. Sure, it's nice to minimize that pain, but it's never going to be possible to write much code that uses the C API without being alert to such issues. (Incidentally, the more things you have that can only be done by invoking PyObject_CallMethod, the more places you have where you have to assume that arbitrary Python code may have been called and that reference counts may have changed behind your back.) * Duck typing: Yup, supporting duck typing is good. That's why we have an abstract API. There are concrete APIs for all sorts of particular kinds of Python object; it seems pretty clear to me that this isn't a mistake, and that sets should be one such type. Clients get to choose how to trade off the benefits in efficiency, conciseness and clarity from using the concrete API against the benefits in generality from using the abstract one. And when PySet_Add is the obvious way to add items to sets, how much C code using sets is likely to work with things that merely walk and quack like sets, anyway? * Efficiency: Anyone measured this? The mere fact that the overhead of (say) emptying a set using PyObject_CallMethod is O(1) doesn't mean it's insignificant. For many applications the size of your sets is O(1) too. (Often with quite a small implicit constant, too.) -- Gareth McCaughan ___ 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] Py3k: Except clause syntax
On Friday 2006-03-17 05:04, Alex Martelli wrote: Hmmm, if we allowed '(expr as var)' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? I hope not. It looks a lot more like a binding construct than an assigning one. But what about pattern-matching? Currently, you can say def f((x0,y0), (x1,y1)): ... but wouldn't if be nice if you could say def f((x0,y0) as p0, (x1,y1) as p1): ... and have both the packed and unpacked forms available? (Prior art: some functional languages that let you define a function with multiple pattern-matching clauses have a similar feature.) -- g ___ 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: defaultdict
d.get(key, [], True).append(value) hmm. are you sure you didn't just reinvent setdefault ? I'm reasonably sure I copied it on purpose, only with a name that isn't 100% misleading as to what it does ;) Heh. From the original Usenet posting that suggested the capability that was added in the form of setdefault: | I suggest a minor change: another optional argument to | get so that | | dict.get(item,default,flag) | | is equivalent to | | if dict.has_key(item): | VALUE IS dict[item] | else: | if flag: dict[item] = default-- This is all that's new | VALUE IS default | | but presumably more efficient. The response was a chorus of people saying Not a bad idea, but that flag sucks. It needs a separate method. :-) -- g ___ 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)
Steven Bethard wrote:
My only fear with the / operator is that we'll end up with the same
problems we have for using % in string formatting -- the order of
operations might not be what users expect. Since join is conceptually
an addition-like operator, I would expect:
Path('home') / 'a' * 5
to give me:
home/a
If I understand it right, it would actually give me something like:
home/ahome/ahome/ahome/ahome/a
Is there any very deep magic that says / is the One True Operator
to use for this, given that there's to be an operator for it? For
instance, has lower correct precedence (so that Path('home') 'a'*5
does something less unexpected), and doesn't look quite so much
as if it denotes arithmetic, and avoids semantic interference
from the idea that / should divide things or make them smaller.
(Though, for what it's worth, I think sticking another subdirectory
onto a path *is* dividing and making smaller: think of a path as
representing a subtree.) You do lose the pun on the Unix path separator,
which is a shame.
--
g
___
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 with base
On Wednesday 2006-01-18 16:55, Steven Bethard wrote: [Raymond] Perhaps introduce a single function, base(val, radix=10, prefix=''), as a universal base converter that could replace bin(), hex(), oct(), etc. +1 on introducing base() Introducing a new builtin with a name that's a common, short English word is a bit disagreeable. The other thing about the name base is that it's not entirely obvious which way it converts: do you say base(123,5) to get a string representing 123 in base 5, or base(123,5) to get the integer whose base 5 representation is 123? Well, one option would be to have both of those work :-). (Some people may need to do some deep breathing while reciting the mantra practicality beats purity in order to contemplate that with equanimity.) Alternatively, a name like to_base that clarifies the intent and is less likely to clash with variable names might be an improvement. Or there's always %b, whether that ends up standing for binary or base. Or %b for binary and %r for radix, not forgetting the modifiers to get numbers formatted as Roman numerals. -- Gareth McCaughan ___ 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 with base
On Tuesday 2006-01-17 15:19, [EMAIL PROTECTED] wrote: Alex Identically the same situation as for int: the base argument is Alex only accepted if the first argument is a str (not a float, etc). Alex Just the same way, the base argument to str will only be accepted Alex if the first argument is an int (not a float, etc). A shortcoming in int() hardly seems like a good reason to mess with str(). How's it a shortcoming in int() that it doesn't do anything with, say, int(2.345,19)? (What would you like it to do?) Or are you saying that the fact that int(a string) lets you specify a base to interpret the string in is itself a shortcoming, and if so why? -- g ___ 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] a quit that actually quits
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to exit')
exit = _Quitter('The exit command. Type exit() to exit')
I think you meant
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to quit')
exit = _Quitter('The exit command. Type exit() to exit')
:-)
--
g
___
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
On Saturday 2005-09-24 04:21, Terry Reedy wrote: Never wrote a single line, and may have not read one (in DDJ? Byte?) for 15-20 years. How do *you* read such C? Cond 'Qmark' ? I seldom have to read C code aloud, and the ?: operator is rare-ish; but I would suggest reading a?b:c as a chooses b else c or (shaving a syllable) a gives b else c or something like that. Or, ploddingly but unambiguously, a query b colon c. Now, can you honestly say that you would (naively) read return foo if bar else baz and be certain you knew what it meant? I can't imagine *actually* reading it as if foo were the condition. But I can imagine reading it, to begin with, as if it were a Perlish conditionalized statement: (return foo) if bar else ... aw heck, that can't be right. Which is probably benign but slows down comprehension. -- g ___ 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
The reason I like a if b else c is because it has the most natural word order. In English, My dog is happy if he has a bone, else sad. sounds much more natural than My dog is, if he has a bone, happy, else sad. Neither sounds very natural to me; conditional expressions don't occur much in English. It's much more common to hear something like My dog is happy if he has a bone; otherwise he's sad. And that would correspond to a postfix conditional operator on *statements*, not expressions; Perl and Ruby have this, but it doesn't seem very Pythonic. Interestingly, it looks *more* odd to me if parens are included: return (self.arg if self.arg is not None else default) I think this is because, without the parens, I tend to read the if as applying to the whole phrase return self.arg, not just to the self.arg. Which is one reason why I *don't* like the proposed consequent if antecedent else alternative syntax; it looks like a statement modifier when it isn't really one. When you're forced (by the parens) to read it correctly, you stop liking it! :-) * Conditional expressions do occur in English, though, and they do generally have the consequent at the front. But ... they also generally have the else-marker right at the end. Buy some pork if it's going cheap, and some beef if not. You can divide an angle into N equal parts with ruler and compasses if N is a power of 2 times a product of distinct Fermat primes, but not if N has any other form. I sleep all night and work all day. I don't think a syntax that authentically mirrors the structure of conditional expressions in English is likely to be very good. x = (123 if p==q; 321 otherwise) x = (123 if p==q, else 321 if not) x = (123 if p==q; else 321 if r==s; else 999 if not) :-) -- g ___ 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] Visibility scope for for/while/if statements
On Thursday 2005-09-22 20:00, Josiah Carlson wrote:
[Alexander Myodov:]
But for the performance-oriented/human-friendliness factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
C does not have pseudo-namespaces or variable encapsulation in for loops.
Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
does not rival C in the performance/friendliness realm? Who are you
trying to kid?
I think you've misunderstood Alex here; he's saying that Python
and C don't occupy the same region of the spectrum that runs
from high performance, human-unfriendly to lower performance,
human friendly. Which is correct, unlike some other things he's
said :-).
for (int i = 0; i 10; i++) works fine nowadays.
I'm sorry, but you are wrong. The C99 spec states that you must define
the type of i before using it in the loop. Maybe you are thinking of
C++, which allows such things.
No, Alex is right on this one too. Maybe you are thinking of C89,
which forbids such things.
6.8.5.3 The for statement
[#1] Except for the behavior of a continue statement in the
loop body, the statement
for ( clause-1 ; expr-2 ; expr-3 ) statement
and the sequence of statements
{
clause-1 ;
while ( expr-2 ) {
statement
expr-3 ;
}
}
are equivalent (where clause-1 can be an expression or a
declaration).123)
...
123Thus, clause-1 specifies initialization for the loop,
possibly declaring one or more variables for use in the
loop; expr-2, the controlling expression, specifies an
evaluation made before each iteration, such that
execution of the loop continues until the expression
compares equal to 0; expr-3 specifies an operation (such
as incrementing) that is performed after each iteration.
If clause-1 is a declaration, then the scope of any
variable it declares is the remainder of the declaration
and the entire loop, including the other two expressions.
(This is from a late draft of the C99 spec; I'm fairly sure
the final version is no different.)
--
g
___
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] Visibility scope for for/while/if statements
Alexander Myodov wrote: Thus, your example falls to case 1: i variable is newly declared for this loop. Well, we don't reuse old value of i to start the iteration from a particular place, like below? i = 5 for i in [3,4,5,6,7]: print i, More general, the variables could be assumed local only to the *same or higher* indentation level. So (since you're talking about if as well as for and while) you're suggesting that x = 0 if foo(): x = 1 else: x = 2 should always leave x == 0? Or that the same bit of code, without the first line, should always leave x undefined? JC Python semantics seem to have been following the rule of we are all JC adults here. I always believed that the programming language (as any computer program) should slave to the human, rather than a human should slave to the program. Right. And some of us humans *don't want* the change you're proposing. For what it's worth, I think it might well have been better if for and comprehensions had made their loop variables block-local; especially comprehensions. But making every for/while/if introduce a new level of scoping would be horrible. Perhaps you think it's what you want, but I think if you tried it for a month then you'd change your mind. -- g ___ 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. None of the other expression forms (list comprehensions and generator expressions) involving statement keywords use colons. FWLIW, this was my (strong) preference back at the time of the original discussion. -- g ___ 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
On Tuesday 2005-09-20 11:40, Raymond Hettinger wrote: 2) When going back and forth between languages, it is easy to forget that only Python returns something other than a boolean. As others point out, this isn't true. In C, C++, C#, Java, and JavaScript, what do you get when you print the result of 3 || 10? JavaScript does the same as Python, according to section 11.11 of the EMCA standard as of December 1999, which is what I have to hand. The others you mention don't, because doing so would fit very uncomfortably with their static type systems. Those are not the only languages that exist other than Python. Perl and Ruby both have Python-like behaviour in this respect. So do all the Lisp variants I can readily check (CL, elisp, Scheme, Dylan). So does Lua. I can't, offhand, think of any dynamically typed language that doesn't behave this way. Oh, except Smalltalk, which has a radically different approach to the whole business. -- g ___ 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
On 9/6/05, Barry Warsaw [EMAIL PROTECTED] wrote:
printf('$1 forgot to frobnicate the $2!\n', username, file.name,
to=sys.stderr)
...
For me, the problem with that proposal is not the precise format syntax,
but the fact that formatting is tied to a specific function which _also_
outputs stuff to screen.
So borrow a trick from Common Lisp and use a destination of None
to mean return the formatted text as a string.
x = printf($2 $1, 123,321)
321 123
print x
None
x = printf($2 $1, 123,321, to=None)
print x
321 123
Or is that too cryptic?
--
g
___
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] Revising RE docs
Guido wrote: They *are* cached and there is no cost to using the functions instead of the methods unless you have so many regexps in your program that the cache is cleared (the limit is 100). Sure there is; the cost of looking them up in the cache. ... So in this (highly artificial toy) application it's about 7.5/2.5 = 3 times faster to use the methods instead of the functions. Yeah, but the cost is a constant -- it is not related to the cost of compiling the re. True. (You should've shown how much it cost if you included the compilation in each search.) Why should I have? I don't dispute that the caching helps -- I bet it helps a *lot*. I was just observing that it's not true that there's no cost to using the functions instead of the methods. I haven't looked into this, but I bet the overhead you're measuring is actually the extra Python function call, not the cache lookup itself. Hmm, that's possible. But what matters in practice is how big the cost of using re.search(...,...) rather than compiling once and using the RE object's search method is, not where it comes from. -- g ___ 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] string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
If people know of other languages that have a different approach to
string formatting, it might be useful to see them.
Common Lisp has something broadly C-like but bigger and hairier.
It includes powerful-but-confusing looping and conditional
features, letting you say things like
(format t ~{~^, ~A~} 1 2 3 wombat)
which produces
1, 2, 3, wombat
or -- you may wish to be sitting down before reading further --
(format t ~#[nothing~;~S~;~S and ~S~:;[EMAIL PROTECTED]; and~] ~S~^
,~}~]. 1 2 3 wombat)
which produces
1, 2, 3, and wombat
and also does the Right Thing with 0, 1 or 2 items. (The first
argument to FORMAT, in case you were wondering, determines where
the output should go. Feeding in T, as here, sends it to stdout.
You can also give it an arbitrary stream, or NIL to return the
formatted result as a string.)
For the impressive and horrifying full story, see
http://www.lisp.org/HyperSpec/Body/sec_22-3.html
Most of the features of CL's formatted output are probably,
shall we say, inappropriate for Python. It might still be worth
a look, to see if there's anything under the rococo exterior
that would fit.
*
Some languages have picture formats, where the structure
of the format string more closely mimics that of the desired
output. (This is true, e.g., of some Basics and of one variety
of Perl output.) The trouble with this is that it limits how
much information you can provide about *how* each value is
to be formatted within the available space.
*
C++'s operator represents another way to do formatted
output. I regard it as an object lesson in bad design.
--
g
___
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] string formatting and i18n
On Monday 2005-09-05 17:07, Antoine Pitrou wrote: Le lundi 05 septembre 2005 à 16:52 +0100, Gareth McCaughan a écrit : ... and should add: Of course it's usually seen as being about output more than about formatting, but in fact if you want to do what Python does with %, C with sprintf and Common Lisp with (format nil ...) then the Right Thing in C++ (in so far as that exists) is usually to use with a string stream. Uh, what about internationalization (i18n) ? In i18n you can't avoid the need for parameterized strings. For example I want to write : _(The file '%s' is read only) % filename not : _(The file) + ' + filename + ' + _(is read only) because the splitting in the second form will not translate correctly into other languages. You *have* to supply the whole non-splitted sentence to the translators. Yes. If you think I was arguing the opposite, then I failed to communicate clearly and I apologize. The bottom line, IMHO, is that there are frequent uses that mandate a nice and easy to use formatting operator. Python has it, let's not remove it. It's clear (I think) that a good way of formatting strings is necessary. It's less clear what the best way is. Python's % is pretty good; perhaps it's possible to do even better. For instance, take your I18N example. Not all languages have the same word order, as you've observed. When there's more than one parameter, Python's %-interpolation isn't enough in general; you'd need something that can reorder the parameters. I don't know whether this is worth complicating string formatting for, but it's not obvious that it isn't. -- g ___ 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] Revising RE docs
On Thursday 2005-09-01 18:09, Guido van Rossum wrote: They *are* cached and there is no cost to using the functions instead of the methods unless you have so many regexps in your program that the cache is cleared (the limit is 100). Sure there is; the cost of looking them up in the cache. import re,timeit timeit.re=re timeit.Timer(re.search(r(\d*).*(\d*), abc123def456)).timeit(100) 7.6042091846466064 timeit.r = re.compile(r(\d*).*(\d*)) timeit.Timer(r.search(abc123def456)).timeit(100) 2.6358869075775146 timeit.Timer().timeit(100) 0.091850996017456055 So in this (highly artificial toy) application it's about 7.5/2.5 = 3 times faster to use the methods instead of the functions. -- g ___ 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
We scientists still use these for debugging. We never 'move on' very far from the tutorial. The salient feature about print statements is that they live to be put in and commented out 10 minutes later, without some import being required or other enabling object being around. Easy things should be easy. Hard things should be possible. I don't believe the person who said the trailing comma case mixed up anybody, not for more than 10 seconds anyway. Damn right. No, I mean: damn write :-). I've used Python for teaching beginner programmers, for quick-hack scripts, for interactive diddling about, for scientific computation, for algorithmic experimentation, for GUI applications. I'd appreciably miss print for *all* of these, even the last. (My GUI applications sometimes have bugs. How about yours?) So far as I can see, two arguments against print have been proposed. 1. It has some ugly features, like the trailing-comma hack. 2. It's a statement that does something ordinary and could be replaced by a function. Against which, we have 3. It's convenient for debugging, interactive use, simple scripts, and various other things. 4. It's beginner-friendly. Now, I'm sure I remember hearing something that was relevant to this. Pragmatism beats purification? No, that's not quite it. Practice beats perfection? No. Ah yes, I remember: Practicality beats purity. But, of course, that wasn't talking about Python 3000. :-) -- g ___ 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
3. It's convenient for debugging, interactive use, simple scripts, and various other things. Interactive use is its own mode and works differently to the base language. To print the value of something, just type an expression. Doesn't do the same thing. The problem with print is it becomes a barrier to extending a script into something more ambitious. This then leads to ugly 'features' like '' and trailing commas. By all means provide a simple syntax for i/o with the standard streams but ensure it is something that is a firm basis for extension. Do you have any suggestion that's as practically usable as print? -- g ___ 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] Remove str.find in 3.0?
Just to put my spoke in the wheel, I find the difference in the ordering of return values for partition() and rpartition() confusing: head, sep, remainder = partition(s) remainder, sep, head = rpartition(s) My first expectation for rpartition() was that it would return exactly the same values as partition(), but just work from the end of the string. IOW, I expected www.python.org.partition(python) to return exactly the same as www.python.org.rpartition(python) Yow. Me too, and indeed I've been skimming this thread without it ever occurring to me that it would be otherwise. Anyway, I'm definitely +1 on partition(), but -1 on rpartition() returning in reverse order. +1. -- g ___ 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] Remove str.find in 3.0?
I wrote: [Andrew Durdin:] IOW, I expected www.python.org.partition(python) to return exactly the same as www.python.org.rpartition(python) Yow. Me too, and indeed I've been skimming this thread without it ever occurring to me that it would be otherwise. And, on re-skimming the thread, I think that was always the plan. So that's OK, then. :-) -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
Here's an excerpt from the check-in note for sha512module.c: RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); Perhaps OS X has some sort of Steve Jobs special constant suffix ULL that Mr. Gates and the ANSI C folks have yet to accept ;-) It's valid C99, meaning this is an unsigned long long. -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
On Tuesday 2005-08-23 16:51, Fredrik Lundh wrote: Gareth McCaughan wrote: It's valid C99, meaning this is an unsigned long long. since when does Python require C99 compilers? /F It doesn't, of course, and I hope it won't for a good while. I was just responding to this: | Perhaps OS X has some sort of Steve Jobs special constant suffix ULL | that Mr. Gates and the ANSI C folks have yet to accept since in fact Mr Gates and the ANSI C folks (and the gcc folks, and probably plenty of others I can't check so easily) *have* accepted it. -- g ___ 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] while:
On Thursday 2005-07-21 01:22, Martin Blais wrote: The Rule of Least Surprise says to me that while: would do the least unexpected thing. There are only two possibilities: the test is implicitly false, in which case while: would make no sense (i.e. the block would be ignored). Therefore the other only sensible case is that the test is implicitly true, which can be useful (and also happens to be a very common idiom). To me, the least unexpected thing for while: to do is to raise a syntax error. The principle of least surprise doesn't mean that for every sequence of tokens you should pick the least surprising thing it could do, and give it that definition. (That's what they do in C++, except for the bit about picking the least surprising semantics.) -- g ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
[GvR:] Huh? C unsigned ints don't flag overflow either -- they perform perfect arithmetic mod 2**32. [Keith Dart:] I was talking about signed ints. Sorry about the confusion. Other scripting languages (e.g. perl) do not error on overflow. C signed ints also don't flag overflow, nor do they -- as you point out -- in various other languages. (c) The right place to do the overflow checks is in the API wrappers, not in the integer types. That would be the traditional method. I was trying to keep it an object-oriented API. What should know the overflow condition is the type object itself. It raises OverFlowError any time this occurs, for any operation, implicitly. I prefer to catch errors earlier, rather than later. Why should? Sure, catch errors earlier. But *are* the things you'd catch earlier by having an unsigned-32-bit-integer type actually errors? Is it, e.g., an error to move the low 16 bits into the high part by writing x = (y16) 0x instead of x = (y0x) 16 or to add 1 mod 2^32 by writing x = (y+1) 0x instead of if y == 0x: x = 0 else: x = y+1 ? Because it sure doesn't seem that way to me. Why is it better, or more object-oriented, to have the checking done by a fixed-size integer type? (b) I don't know what you call a normal integer any more; to me, unified long/int is as normal as they come. Trust me, that's the case for most users. Worrying about 32 bits becomes less and less normal. By normal integer I mean the mathematical definition. Then you aren't (to me) making sense. You were distinguishing this from a unified int/long. So far as I can see, a unified int/long type *does* implement (modulo implementation limits and bugs) the mathematical definition. What am I missing? Most Python users don't have to worry about 32 bits now, that is a good thing when you are dealing only with Python. However, if one has to interface to other systems that have definite types with limits, then one must hack around this feature. Why is checking the range of a parameter with a restricted range a hack? Suppose some other system has a function in its interface that expects a non-zero integer argument, or one with its low bit set. Do we need a non-zero-integer type and an odd-integer type? I was just thinking how nice it would be if Python had, in addition to unified (real, normal) integers it also had built-in types that could be more easily mapped to external types (the typical set of signed, unsigned, short, long, etc.). Yes, you can check it at conversion time, but that would mean extra Python bytecode. It seems you think this is a special case, but I think Python may be used as a glue language fairly often, and some of us would benefit from having those extra types as built-ins. Well, which extra types? One for each of 8, 16, 32, 64 bit and for each of signed, unsigned? Maybe also non-negative signed of each size? That's 12 new builtin types, so perhaps you'd be proposing a subset; what subset? And how are they going to be used? - If the conversion to one of these new limited types occurs immediately before calling whatever function it is that uses it, then what you're really doing is a single range-check. Why disguise it as a conversion? - If the conversion occurs earlier, then you're restricting the ways in which you can calculate the parameter values in question. What's the extra value in that? I expect I'm missing something important. Could you provide some actual examples of how code using this new feature would look? -- g ___ 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] Is PEP 237 final -- Unifying Long Int egers and Integers
On Wednesday 2005-06-22 13:32, Nick Coghlan wrote: Gareth McCaughan wrote: [Keith Dart:] By normal integer I mean the mathematical definition. Then you aren't (to me) making sense. You were distinguishing this from a unified int/long. So far as I can see, a unified int/long type *does* implement (modulo implementation limits and bugs) the mathematical definition. What am I missing? Hmm, a 'mod_int' type might be an interesting concept (i.e. a type that performs integer arithmetic, only each operation is carried out modulo some integer). Then particular bit sizes would be simple ints, modulo the appropriate power of two. It might indeed, but it would be entirely the opposite of what (I think) Keith wants, namely something that raises an exception any time a value goes out of range :-). -- g ___ 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] AST manipulation and source code generation
?!ng: Well, i should refine that a bit to say that the Lisp macro system is a little more specific. Whereas AST transformations in Python are open-ended (you could generate any result you want), the key interesting property of Lisp macros is that they are constrained to be safe, in the sense that the bindings of variable names are always preserved. I'm not quite sure what ?!ng means by the bindings of variable names are always preserved, but I conjecture that he is thinking of the hygienic macros in Scheme rather than the macros in Common Lisp which permit arbitrary code transformations. -- g ___ 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 2.4 won the Jolt productivity award last night
On Thursday 2005-03-17 15:42, Guido van Rossum wrote: Python 2.4 won the Jolt productivity award last night. That's the runner-up award; in our category, languages and development tools, the Jolt (the category winner) went to Eclipse 3.0; the other runners-up were IntelliJ and RealBasic (no comment :-). Like usually, open source projects got several awards; both Subversion and Hibernate (an open source Java persistency library) got Jolts. Maybe from now on we should add award-winning whenever we refer to Python 2.4. If someone can find out the website where the results are summarized (I'm sure there is one but I'm too lazy to Google). http://www.sdmagazine.com/jolts/ , but it's not been updated yet and therefore still has last year's winners on it. I haven't found anything with more up-to-date results. This year's finalists are listed at http://www.sdmagazine.com/jolts/15th_jolt_finalists.html . -- g ___ 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] comprehension abbreviation (was: Adding any() and all())
On Monday 2005-03-14 12:42, Eric Nieuwland wrote:
Gareth McCaughan wrote:
I'd like it, and my reason isn't just to save typing.
There are two reasons.
1 Some bit of my brain is convinced that [x in stuff if condition]
is the Right Syntax and keeps making me type it even though
I know it doesn't work.
2 Seeing [x for x in stuff if condition] triggers my internal
duplicated-stuff alarm, and it's distracting, in the same sort
of way as it's distracting in C or C++ seeing
The full syntax is:
[ f(x) for x in seq if pred(x) ]
being allowed to write 'x' instead of 'identity(x)' is already a
shortcut, just as dropping the conditional part.
Remember we're doing set theory stuff here. IMHO we should follow its
notation conventions as much as we can.
I'm well aware of what the full syntax is; being allowed to
write x instead of identity(x) is *not* a shortcut but
a perfectly straightforward unexceptional instance of the
usual syntax; list comprehensions already have neither the
syntax nor the semantics of set-theorists' comprehensions;
and in fact no set theorist would be at all troubled by seeing
{ x in S : predicate(x) }
which is the nearest equivalent in mathematical notation
for the abbreviated comprehension expressions being discussed.
Other than that, I quite agree :-).
--
g
___
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] 2.4 news reaches interesting places
On Wednesday 2004-12-08 22:39, Phillip J. Eby wrote: [Guido:] One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation (but it's so flexible, but it's fast enough) but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas? [Philip:] The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce native executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient security blanket to stop people FUDding about it. Unfortunately, this may not be enough. Consider, by way of counterexample, Common Lisp, which - is compiled to native code - has optional type declarations - actually *does* run fast when compiled - has had all these properties for years and years but is still almost universally decried as slow by people who have never actually used it. It's true that it doesn't (as part of the standard, and in the free implementations I know of) have the ability to generate standalone executables with filenames ending in .exe; perhaps that's the key thing. The other thing that might work is to change the name of the language to C plus optional punctuation. -- g ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
