On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote:
[Noam Raphael:]
> > The idea is to add a method called "dedent" to strings. It would do
> > exactly what the current textwrap.indent function does.
[Marc-Andre:]
> You are missing a point here: string methods were introduced
> to make switchi
> 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
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> i
ernatively, 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 f
On Thursday 2006-01-19 11:15, Thomas Wouters wrote:
> On Thu, Jan 19, 2006 at 10:23:30AM +0000, Gareth McCaughan wrote:
...
> > Introducing a new builtin with a name that's a common, short
> > English word is a bit disagreeable.
>
> While I don't particularly mind
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'
> >> 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
On Friday 2006-03-17 05:04, Alex Martelli wrote:
> Hmmm, if we allowed '( as )' 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
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 mail
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 Raymo
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
> - Before anybody asks, I really do think the reason this is requested
> at all is really just to save typing; there isn't the "avoid double
> evaluation" argument that helped acceptance for assignment operators
> (+= etc.), and I find redability is actually improved with 'for'.
I'd like it, and
On Monday 2005-03-14 12:09, Alex Martelli wrote:
>
> On Mar 14, 2005, at 10:57, Gareth McCaughan wrote:
>
> > of way as it's distracting in C or C++ seeing
> >
> > Thing thing = new Thing();
> >
> > with the type name appearing thre
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]
>
On Tuesday 2005-03-15 01:57, Guido van Rossum wrote:
> I think the conclusion should be that sum() is sufficiently
> constrained by backwards compatibility to make "fixing" it impossible
> before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is
> only used for empty lists.
Why's that
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
> ?!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
[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
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 u
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). Therefo
> 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[
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?
>
>
It doesn't, of course, and I hope it won'
> 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
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
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.
> 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 th
> > 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
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 (hi
> 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
I wrote:
> C++'s << operator represents another way to do formatted
> output. I regard it as an object lesson in bad design.
... 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"
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 Py
> > 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 whic
On Monday 2005-09-19 06:38, Josiah Carlson wrote:
> > > [ 'x', *a, 'y']
> > >
> > > as syntactic sugar for
> > >
> > > [ 'x' ] + a + [ 'y' ].
> > >
> > > Notes:
> > > - This is a common operation
> >
> > is it?
>
> Not in the code that I read/use. While "not all 3 line functions should
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 wh
> I think I'd prefer (if then else ) 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
__
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 b
> 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 occu
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 encapsul
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 c
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)
> I can say it stronger. Any resemblance between Python and Scheme or
> Lisp is purely a coincidence. Neither language is in Python's
> ancestry, at least not explicitly; I'd never used or tried to learn
> Scheme when I started Python (still haven't) and my Lisp experience
> was limited to copying
(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
> > 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
>
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?
airs 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
___
Pytho
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 wha
46 matches
Mail list logo
