On 6/25/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Gustavo Carneiro wrote:
However, PyObject_CallFunction does _not_
consume such an object reference, contrary to what I believed for
years.
Why do you say that? It certainly does.
Yes it does. I could almost swear it didn't last
The PyPy development team has been busy working and we've now packaged
our latest improvements, completed work and new experiments as
version 0.9.0, our fourth public release.
The highlights of this fourth release of PyPy are:
**implementation of stackless features**
We now support the
Sorry, no go. You can say supports key use cases found in real code
as often as you like, but limiting it only to literals drops many use
cases on the floor, and is unacceptable for me. There are no other
places in Python where only literals are allowed. In your eagerness to
rule out surprises,
On 6/24/06, Nick Coghlan [EMAIL PROTECTED] wrote:
[...] a syntactic nit that Eric Sumner pointed out. Since
it involves iteration over x to populate the jump table rather than doing a
containment test on x, using 'case in x' is misleading. It would be better
written as 'case *x'.
Then:
Neal Norwitz wrote:
I believe this change is all that's necessary on the Unix side to
install wsgiref. Can someone please update the Windows build files to
ensure wsgiref is installed in b2? Don't forget to update the NEWS
entry too.
It's installed in b1 already. The msi generator picks up
Dear all,
Some of you might be aware that a project has been granted to me for this
year's Google's Summer of Code, which aims at preparing a base
multidimensional array type for Python. While I had a late start at it, I
would like to go through with the project.
The focus is on preparing a
Talin wrote:
In fact, I'd like to point out something that hasn't been brought up,
which is that in many cases having a closure rebind the switch cases
defeats the purpose of the thing. For example:
def outer():
def inner(x):
switch(x):
case 1: ...
Phillip J. Eby wrote:
I don't see this as much of a problem, really: we can simply restrict
the optimization to well-known data types (homogenous switches using
integers or strings should cover 99.9% of all practical cases), and then
add an opcode that checks uses a separate dispatch object
On 6/24/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote: Yep.That API will be used directly in the changes to pymalloc and PyMem_*() macros (or at least the basic idea).It is not *only* for extension modules but for the core as well.
Existing extension modules and existing C code in
On 6/24/06, Bob Ippolito [EMAIL PROTECTED] wrote:
On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote: Brett Cannon wrote: Yep.That API will be used directly in the changes to pymalloc and PyMem_*() macros (or at least the basic idea).It is not *only* for
extension modules but for the core as well.
Sorry for the untrimmed conversation, but I've cc'ed jython-dev, my
comments are at the bottom.
On 6/12/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/12/06, Samuele Pedroni [EMAIL PROTECTED] wrote:
Fabio Zadrozny wrote:
Python and Jython import semantics differ on how sub-packages
No thanks. That is its own can of worms. The obvious solutions (like const
declarations, macros, or a syntax to force compile-time expression
evaluation)
are unlikely to sit well because they run afoul Python's deeply ingrained
dynamism.
I think perhaps you haven't been paying close
[EMAIL PROTECTED] wrote:
I'm not asking you to describe SC22WG14 or post detailed technical summaries
of the long and painful road. I'd like you to post things directly relevant
to Python with footnotes to necessary references. It is then incumbent on
those that wish to respond to your
On Sat, 24 Jun 2006, Raymond Hettinger wrote:
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a case statement, and 3) handling overlapping cases.
Here's a simple approach that will
On Jun 25, 2006, at 1:08 PM, Brett Cannon wrote:On 6/24/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote: Brett Cannon wrote: Yep. That API will be used directly in the changes to pymalloc and PyMem_*() macros (or at least the basic idea). It is not
On Sat, 24 Jun 2006, Phillip J. Eby wrote:
At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
Cases values must be ints, strings, or tuples of ints or strings.
-1. There is no reason to restrict the types in this fashion. Even if you
were trying to ensure marshallability, you could still
Raymond Hettinger wrote:
No thanks. That is its own can of worms. The obvious solutions (like const
declarations, macros, or a syntax to force compile-time expression
evaluation)
are unlikely to sit well because they run afoul Python's deeply ingrained
dynamism.
I think perhaps you
On Sun, 25 Jun 2006, Guido van Rossum wrote:
In your eagerness to
rule out surprises, you're creating the biggest surprise of all: the
restriction to literals is certainly a surprise!
I disagree. Perhaps what we mean by surprise is different. In
Raymond's design, there is a simple rule for
It seems to me that the main reason to provide constantification (in a
switch statement or anywhere else) is to be able to optimize execution
by caching the result locally for later use. The problem comes from
trying to determine exactly when and how a value gets calculated, as
most values in
On Sun, Jun 25, 2006, Eric Sumner wrote:
In general, a cached value can be used (rather than re-evaluating the
expression) if:
- The expression has no side effects,
- The result of all operations is deterministic, and
- None of the expression parameters have changed since the cached
On 6/25/06, Eric Sumner [EMAIL PROTECTED] wrote:
It seems to me that the main reason to provide constantification (in a
switch statement or anywhere else) is to be able to optimize execution
by caching the result locally for later use. The problem comes from
trying to determine exactly when
Guido van Rossum wrote:
I'm currently leaning
towards making static expressions outside a function illegal and limit
switches outside a function to compile-time-constant expressions.
I'm not sure I like the idea of having things that
are illegal outside a function, because it can be a
nuisance
On 6/25/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Sun, 25 Jun 2006, Guido van Rossum wrote:
In your eagerness to
rule out surprises, you're creating the biggest surprise of all: the
restriction to literals is certainly a surprise!
I disagree. Perhaps what we mean by surprise is
On 6/25/06, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I'm currently leaning
towards making static expressions outside a function illegal and limit
switches outside a function to compile-time-constant expressions.
I'm not sure I like the idea of having things that
are
On Mon, 26 Jun 2006, Georg Brandl wrote:
Raymond Hettinger wrote:
five = 5
eight = [8]
def f(x, six=6):
seven = 7
a = static(five + 4)# this is legal
b = static(six + 4) # this is illegal
c = static(seven + 4) # this is
On 6/25/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Unfortunately, a mechanism that would let you register a callback for
when a particular variable or attribute used in a cached expression is
used, is pretty hard to implement without affecting the performance of
code that doesn't use it.
On 6/25/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Mon, 26 Jun 2006, Georg Brandl wrote:
Raymond Hettinger wrote:
five = 5
eight = [8]
def f(x, six=6):
seven = 7
a = static(five + 4)# this is legal
b = static(six + 4) # this is
On 6/25/06, Eric Sumner [EMAIL PROTECTED] wrote:
On 6/25/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Unfortunately, a mechanism that would let you register a callback for
when a particular variable or attribute used in a cached expression is
used, is pretty hard to implement without
On Sun, 25 Jun 2006, Guido van Rossum wrote:
What do you think of Nick C's 'once'?
It's a bit closer to the right meaning... but what about:
def f(x):
def g(y):
return y + once x
return g
Does once mean not really once here, but once for each new function
object
Has anyone else tried doing an admin install with compile .py files
checked? It's causing my install to blow up, but I'd prefer to assume
it's some weird Windows config/bug unless other people also have it, in
which case I'll file an SF report.
--
Aahz ([EMAIL PROTECTED]) *
At 01:37 PM 6/25/2006 -0700, Raymond Hettinger wrote:
No thanks. That is its own can of worms. The obvious solutions (like const
declarations, macros, or a syntax to force compile-time expression
evaluation)
are unlikely to sit well because they run afoul Python's deeply ingrained
dynamism.
Martin v. Löwis wrote:
Actually, your application *was* pretty close to being broken a few
weeks ago, when Guido wanted to drop the requirement that a package
must contain an __init__ file.
BTW, when that was being discussed, did anyone consider
allowing a directory to be given a .py suffix
On 6/25/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Sun, 25 Jun 2006, Guido van Rossum wrote:
What do you think of Nick C's 'once'?
It's a bit closer to the right meaning... but what about:
def f(x):
def g(y):
return y + once x
return g
Does once mean
On 6/24/06, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
Actually, your application *was* pretty close to being broken a few
weeks ago, when Guido wanted to drop the requirement that a package
must contain an __init__ file. In that case, import math would have
imported the directory, and given
On 6/23/06, Edward C. Jones [EMAIL PROTECTED] wrote:
Python is a beautiful simple language with a rich standard library.
Python has done fine without a switch statement up to now. Guido left it
out of the original language for some reason (my guess is simplicity).
Why is it needed now? What
On Sunday 25 June 2006 20:48, Greg Ewing wrote:
BTW, when that was being discussed, did anyone consider
allowing a directory to be given a .py suffix as an
alternative way to mark it as a package?
I'd certainly be a lot happier with that than with the current behavior.
Silly little
On 6/25/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Sunday 25 June 2006 20:48, Greg Ewing wrote:
BTW, when that was being discussed, did anyone consider
allowing a directory to be given a .py suffix as an
alternative way to mark it as a package?
:-)
I'd certainly be a lot
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than
anything
Google has yet released. Twisted also has a reasonably plausible
technical reason to dislike this change.
Talin wrote:
def outer():
def inner(x):
switch(x):
case 1: ...
case 2: ...
case 3: ...
return inner
If the switch cases are bound at the time that 'inner' is defined, it
means that the hash table will be rebuilt each time
--- Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/25/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Sunday 25 June 2006 20:48, Greg Ewing wrote:
BTW, when that was being discussed, did anyone consider
allowing a directory to be given a .py suffix as an
alternative way to mark
40 matches
Mail list logo
