> I have seen in PEP 3100 that callable() function is planned to be
> removed in Python 3000 with this replacement: "just call the object
> and catch the exception???". For one, the object (if it is
> callable) can raise exception itself, so you need to somehow to
> differentiate between exception
> Maybe Raymond's proposed record type should have two versions: one
> that's also a tuple, for compatibility, and one that's just a record.
FWIW, ML unifies tuples and records by defining a tuple to be a record whose
component names are all consecutive integers starting with 1.
For example, in M
> Unfortunately
>
>dict(keys=keys, values=values) == {keys: values}
Ummm, no:
dict(keys=keys, values=values) == {'keys': keys, 'values': values}
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/py
> If "real" and "imag" are themselves complex numbers, then normalizing
> the result will move the imaginary portion of the "real" vector into
> the imaginary part and vice versa.
Not quite.
>>> complex(1,1j)
0j
>>> complex(0,1j)
(-1+0j)
So it moves the imaginary portion of the "imag" argument i
> This pattern:
>
> while entry_cond:
> ...
> and while not exit_cond:
> ...
>
> has been suggested before, and I believe that at least one of the times it
> was suggested, it had some support from Guido. Essentially, the "and
> while not exit" is equivalent to an "
> (I don't think this has been suggested yet.)
>
> while , :
>
This usage makes me uneasy, not the least because I don't understand why the
comma isn't creating a tuple. That is, why whould
while x, y:
be any different from
while (x, y):
> So, if I understand correctly, in the presence of a global statement
> search
> just goes up the lexical chain looking for the first occurrence of the
> variable to modify?
>
> x = 0
> def f():
> x = 1
> def g():
> global x
> x = 2
> pr
> However I still don't believe "global" has the stretchiness in its
> meaning that you claim it has. Have you ever heard a Python programmer
> talking about closures use the word "global variable"?
I guess the term I've heard most often is "free variable," but I wouldn't be
surprised if I saw the
> Borrowing from Perl, the keyword 'my' is used to declare an explicitly
> scoped variable:
>
> def f1():
>my x = 1
>def f2():
> x = 2 # Does not create a new x
>
> In the above example, the statement 'my x = 1' declares that the scope
> of the variable 'x' is the
> Much though the Algol 60 tickles my nostalgia (it was my first
> programming language!) I don't think that it's a particularly strong
> argument. I like to think that we have better ways these days.
Even if so, that's not the point I was trying to make. The point is that
there is a programming
> I don't think "trivial" is the right word to use here,
> since it implies something that's of so little importance
> that it can be ignored. But the simple cases are precisely
> the ones where this wart hurts the most, so we can't
> ignore them.
I'd like to inject an example that might help make
> Don't recall what that was, but creating a new scope on each iteration
> sounds hard to explain in Python.
I don't think it's particularly hard to explain. For example, one way to
explain it is to say that
for i in <>:
body
is equivalent to
for <> in <>:
> "Fully functional" lexical scopes, then?
Fine-grained scopes?
___
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-archiv
> What about doing something similar to how import was changed?
>
> .a = 5 # this scope (self might be too magical
> ..a = 3 # up one scope
> ...a # up three
>
> Of course, this looks ... perhaps a bit strange. Also, counting is a
> bother.
I'd rather see a simpler rule: = never defines a variab
> a = []
> for i in range(10):
> a.append(lambda: i)
> print [x() for x in a]
>
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Aha! -- Thank you for jogging my memory.
You seem to be right -- the problem is not that Python is lexically scoped,
but that when you define a variable with =, it leaks out into
> I read "a la Scheme" here as "actually nothing like Scheme, except I
> want a non-tricky way to rebind a name from an enclosing scope within
> an enclosed scope".
Almost. What I really want is for it to be possible to determine the
binding of every name by inspecting the source text of the prog
> That sounds like a bug, not a feature. It's frequently useful to have
> forward references in function bodies to names that are not yet globally
> bound, e.g. for classes, or mutually-recursive functions.
The trouble is that you don't necessarily know in what scope they will be
defined, so I t
> That's not a very constructive proposal (especially since I don't know
> Scheme). Perhaps you could elaborate on what needs to change?
The fundamental principle is that the binding of every name is determined
during compilation, not during execution. This property does not quite
apply to Python
> I think it should increment (i.e. rebind) g, for the same reason that
>
> g = [1]
> def f():
> g[0] += 1
> f()
>
> rebinds g[0].
I saw messages out of sequence and did not realize that this would be a
change in behavior from 2.4. Sigh.
I hope Py3000 has lexica
> The question is, what behaviour is preferable for this code:
>
> g = 1
> def f():
> g += 1
>
> f()
>
> Should this raise an UnboundLocalError or should it increment g?
I think it should increment (i.e. rebind) g, for the same reason that
g = [1]
def f():
> > How about this?
> >
> > if any(x==5 for x in seq):
>
> Aren't all of these equivalent to:
>
> if 5 in seq:
> ...
Of course. However, the original example was pretty clearly intended to be
an illustrative instance of a more general problem. Rewriting the example
as any(x==5 for x
> sorry if this came up before, but I tried searching the archives and
> found nothing. It would be really nice if new builtin truth functions
> in 2.5 took a predicate argument(defaults to bool), so one could
> write, for example:
>
> seq = [1,2,3,4,5]
> if any(seq, lambda x: x==5):
> ...
>
> w
> 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
de
> 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
> I'm worried about the name. There are now exactly two names that behave
> like a special method without having the double-underscores around it.
> The first name is 'next', which is kind of fine because it's for
> iterator classes only and it's documented. But now, consider: the
> CPython imple
> I definately agree with the 0c664 octal literal. Seems rather more
> intuitive.
I still prefer 8r664.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
> Apart from making 0640 a syntax error (which I think is wrong too),
> could this be solved by *requiring* the argument to be a string? (Or
> some other data type, but that's probably overkill.)
That solves the problem only in that particular context.
I would think that if it is deemed undesirab
> Possibly os.chmod and os.umask could be extended to take a string
> argument so we could write chmod(path, "0640").
-1.
Would you really want chmod(path, 0640) and chmod(path, "0640") to have
different meanings?
___
Python-Dev mailing list
Python-
> The discussion about PEP 343 reminds me of the following. Bram Cohen
> pointed out in private email that, before PEP 342, there wasn't a big
> need for a shortcut to pass control to a "sub-generator" because the
> following for-loop works well enough:
> def main_generator():
> ...
>
> Of course I already knew all the alternatives using map and the generator
> expression, but I felt like mine was clearer for a reader, this is
> probably true but not enough to justify the change.
If there is to be any enhancement, I think I would prefer it to be an
enhancement to map, so that m
> so the new syntax would
> not be useful, unless it was something that provided access to the index
> item as a variable, like:
>
> yield foo(i) for i in x
>
> which barely saves you anything (a colon, a newline, and an indent).
Not even that, because you can omit the newline and indent:
> We yield values from inside for loops all over the place, but the
> yielded value is very rarely just the index value (only 1 of 14 yields)
> , but something calculated from the index value, so the new syntax would
> not be useful, unless it was something that provided access to the index
> item
> Sure, that would work. Or even this, if the scheduler would
> automatically recognize generator objects being yielded and so would run
> the the nested coroutine until finish:
This idea has been discussed before. I think the problem with recognizing
generators as the subject of "yield" state
> PEP 343 has been updated on python.org.
> Highlights of the changes:
>- changed the name of the PEP to be simply "The 'with' Statement"
Do you mean PEP 346, perchance? PEP 343 is something else entirely.
___
Python-Dev mailing list
Python-Dev
> Congragulations heartily given. I missed the ternary op in c... Way to
> go! clean and easy and now i can do:
> if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False):
> pass
> and check variables IF AND ONLY if they exist, in a single line!
Umm... Is this a joke?
__
> Interestingly enough, not all C++ compilers (Microsoft) hid variables
> created in for loops
> (http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2).
That's because the C++ spec changed during standardization, when the
standards committee realized the original idea was a mistake.
One of t
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> to me.
Interesting. What about
return if self.arg is None: default else:
> In C, C++, C#, Java, and JavaScript, what do you get when you print the
> result of 3 || 10?
In C and C++, you get 1. (in c++ the result is actually true, not 1, but
true prints as 1 by default for backward compatibility)
___
Python-Dev mailing lis
> The only practical reason to like this feature is sparing the need of
> finding an otherwise useless name for the formal argument. Another
> reason, but not practical at all, is that the concept conveys some
> elegance and originality (each programming language should ideally have
> a few of the
> I agree that we shouldn't mess with them in 2.x. Yet I think they are
> a candidate for being dropped from Py3K. While every feature is used
> by *someone* (as the feedback to Brett's query clearly shows) this one
> has several things against it. For every user who is fond of them
> there are pro
> A closure based accumulator (using Scheme):
>
> (define (accum n)
> (lambda (incr)
>(set! n (+ n incr))
>n))
> (define s (accum 0))
> (s 1) ; -> 1 == 0+1
> (s 5) ; -> 6 == 1+5
>
> So I thought the generator version might look like:
>
> def accum(n):
> while 1:
> incr =
> > I believe that Algol 68 loops looked like the following (in somewhat
> > more Python-like terms):
> >
> > [for [from ] [step ] to ]
> > [while ]
> > do od
> As far as I remember, it was:
> do
>
> while
>
> od
> It might be that this could be preceded by a 'for'
> > With PEP 315, a do-while loop would look like:
> >
> >do:
> >
> >while :
> >pass
> > But then, I'm reasonably happy with the 'break out of an infinite
> > loop' approach, so *shrug*.
> From Programming Languages 101 I remember this construct in Algol 68.
> It was then
> > But I cannot do this:
> >
> > def f(x as (a, b)):
> > # ...
> > which is what I was suggesting.
> Yeah, I knew that. How important is that to you?
I would really have liked it for a program I was working on at one time that
had lots of small methods that passed around values
> The issue is: if we allow VAR to be a
> comma-separated list of variables now, that cuts off the extension to
> (a) in the future; so the PEP would have to be amended to state that
> VAR must be a single variable or a list of variables IN PARENTHESES.
> Thoughts?
I am not sure how relevant this
> that we are having this discussion at all seems a signal that the
> semantics are likely too subtle.
I feel like we're quietly, delicately tiptoeing toward continuations...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mai
> This doesn't feel right to me. By that argument, people would want
> to "improve"
>
> (mapcar (lambda (x) (car x)) list-of-lists)
>
> to
>
> (mapcar list-of-lists (x) (car x))
>
> Have you ever heard someone complain about that lambda, though?
Wel Shouldn't you have written
> Mixing both suggestions:
>
> from as :
>
>
> That resembles an import statement which some
> may consider good (syntax/keyword reuse) or
> very bad (confusion?, value focus).
I have just noticed that this whole notion is fairly similar to the "local"
statement in ML, the syntax for
> for_stmt ::= "for" target_list "in" expression_list
> [ "and" expression ] ":"
> suite ["else" ":" suite]
It can't work. The expression_list could be just a variable, as could the
expression, in which case you get
"for" target_list "in" variable "and" variable ":"
and, of course
> >>Lambda will be more difficult. Eric Raymond adapted an anti-gun control
> >>slogan and said "you can pry lambda out of my cold dead hands." A bunch
> >>of folks will sorely miss the ability to create anonymous functions on
> >>the fly. When lambda is used for deferred argument evaluation (a
> duck typing?
That's the Australian pronunciation of "duct taping".
___
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-arc
Follow-up: When I install Python as Administrator, all is well. In that
case (but not when installing it as me), it asks whether I want to install
it for all users or for myself only. I then install pywin32 and it works.
So it may be that a caveat is in order to people who do not install 2.4 as
I'm using Windows XP SP2.
Uninstalled 2.3, installed 2.4 (running as me, not as administrator).
No problems so far.
Tried installing pywin32-203.win32-py2.4.exe
When I try to install it as me, it gets as far as "ready to install." When
I click Next, it says
Can't load Python for pre-in
53 matches
Mail list logo
