Hiho,
in case noone didn't notice yet: the "Windows MSI Installer" link at
http://www.python.org/download/releases/2.5/ points to Python 2.4!
Regards,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
Maybe "switch" became a keyword with the patch..
Regards,
Michael
On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Hi all,
> >
> > As the subject of this e-mail says, the attached patch adds a "switch"
> > statement to the Python language.
> >
> > However, I've been re
>>> 1/2
0
>>> (-1) ** (1./2)
Traceback (most recent call last):
File "", line 1, in ?
ValueError: negative number cannot be raised to a fractional power
Regards,
Michael
On 2/20/06, Jonathan Barbero <[EMAIL PROTECTED]> wrote:
> Hello!
> My name is Jonathan, i´m new with Python.
>
>I try
It doesn't seem to me that math.nice has an obvious meaning.
Regards,
Michael
On 2/14/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Alan Gauld <[EMAIL PROTECTED]> wrote:
> > >> However I do dislike the name nice() - there is already a nice() in the
> > >> os module with a fairly
The behavior of libiberty's alloca() replacement might be interesting as well:
http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-alloca-59
Regards,
Michael
On 11/18/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote:
>
> > Portability may al
FWIW, the Perl 6 community is also investigating STM, so it appears to
be a worthwhile idea for an impure, multi-paradigm language as well.
Regards,
Michael
On 9/29/05, Bruce Eckel <[EMAIL PROTECTED]> wrote:
> This paper looks very interesting and promises some good ideas. It
> also looks like it
is the guard."
>
> In predicate calculus, the phrase, "strengthening the guard" has a
> specific meaning with the "guard" part being consistent with the above.
> One example:
>
>http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf
>
>
Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
"guard" metaphor, but I see what you mean (not allowing "entry", so to
say, right?). Not sure.
Michael
On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > "Guarding a scope with a decimal.Context() object ."
>
> Doesn't "
Hmm:
"Guarding a scope with a decimal.Context() object ."
What do you think? (I'm not sure myself, but we even got a "with" in there :-)
Michael
On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Michael Walter]
> > How about simply "wit
How about simply "with block" or "guarded scope" or something like that?
Michael
On 7/3/05, Ron Adam <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > On the other hand 'enter and exit' rolls off the tongue
> > significantly better than 'enter and leave'
>
> My only concern is enter and ex
On 4/28/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> Guido> You mean like this?
>
> if x > 0:
> ...normal case...
> elif y > 0:
> abnormal case...
> else:
> ...edge case...
>
> T
On 4/26/05, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote:
> IMVHO, macros are readability assassins. The power (for any developer)
> to introduce new syntax is *not* a desirable feature, but something
> to be avoided. And that alone should be a stronger argument than
> a hundred use case
A couple of examples out of my tired head (solely from a user perspective) :-)
Embedding domain specific language (ex.: state machine):
stateful Person:
state Calm(initial=True):
def react(event):
self.chill_pill.take()
ignore(event)
state Furious:
def react(event):
On 4/21/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
> > Now the pattern matching is more interesting, but again, I'd need to
> > see a proposed syntax for Python before I could begin to consider it.
> > If I understand it properly, pattern matching in Haskell relies
> > p
On 4/19/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > RSMotD (random stupid musing of the day): so I wonder if the decorator
> > syntax couldn't be extended for this kind of thing.
> >
> > @acquire(myLock):
> > code
> > code
> > code
>
> Would it be useful for anything other than
On Thu, 17 Mar 2005 14:34:23 +1300, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Not to mention that if the seq is empty, there's no
> way of knowing what T to instantiate...
You just use the same T as inferred for seq : sequence[T] .
Michael
___
Python-Dev
On Wed, 16 Mar 2005 08:28:22 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > > Thinking ahead to generic types, I'd like the full signature to be:
> > >
> > > def sum(seq: sequence[T], initial: T = 0) -> T.
> >
> > Would this _syntax_ work with generic types:
> >
> > def sum(seq: sequenc
On Tue, 15 Mar 2005 07:47:20 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> But I'm not so sure now. Thinking ahead to generic types, I'd like the
> full signature to be:
>
> def sum(seq: sequence[T], initial: T = 0) -> T.
Would this _syntax_ work with generic types:
def sum(seq: seque
That is like Lisp's +, must be good :P
Michael
On Sun, 13 Mar 2005 08:38:42 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> There are a few design choices we could have made for sum(); in
> particular, for non-empty sequences we could not have used the
> identity element (the optional secon
But... only as an additional option, not as a replacement, right?
Michael
On Sat, 19 Feb 2005 03:01:14 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > This is something I've typed way too many times:
> > >
> > > Py> class C():
> > > File "", line 1
> > > class C():
> > >
would like to manifest
that in the type instead of implicitely by the code). Your concept is
cool, tho :-)
Michael
On Thu, 13 Jan 2005 08:52:21 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 10:18 PM 1/13/05 +1000, Nick Coghlan wrote:
> >Michael Walter wrote:
> >>Y
On Thu, 13 Jan 2005 01:04:01 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 12:01 AM 1/13/05 -0500, Michael Walter wrote:
> >What am I missing?
>
> The fact that this is a type-declaration issue, and has nothing to do with
> *how* types are checked.
I was talking ab
> instead interfaces can be defined in terms of individual operations, and
> those operations can be initially defined by an abstract base, concrete
> class, or an "interface" object.
I think this is quite problematic in the sense that it will force many
dummy interfaces to be created. At least w
On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter
<[EMAIL PROTECTED]> wrote:
> [...] Possible slogan for Python: "Fast enough, and better in many ways".
> [...]
Let's make it faster first :-)
Cheers,
Michael
___
Python-Dev mailing list
[EMAIL PROTEC
If I parse you correctly, this would be great.
- Michael
On Thu, 09 Dec 2004 16:37:59 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
>
>
> >On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
> >
> > > The only thing that will fix the
Hi!
I think you were the omitting the more interesting closure examples
(namely with free variables inside the closure's source):
def foo(): pass
def bar(x):
def fiep(): return x()
return fiep
what's bar(foo).__source__?
Generally, I'm opposed to the feature -- I don't think it provides a
r
26 matches
Mail list logo
