Ralf W. Grosse-Kunstleve wrote:
> I can work around it, sure. Everybody can work around it, of course. But
> consider that one hour of a professional person is at least $100 with benefits
> etc. included. (If that sounds high, I know people charging much more than
> that; also consider that the goi
Aahz wrote:
> 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.
It works fine for me. One way
Guido van Rossum wrote:
> Here's an argument for allowing names (this argument has been used
> successfully for using names instead of string literals in many APIs):
> if there is a spelling error in the string literal, the case will
> silently be ignored, and who knows when the bug is detected. I
Raymond Hettinger wrote:
> The static() keyword works like Forth's brackets for forcing
> compile-time evaluation. The issue for us is that unlike other Python
> expressions, there are inconvenient limitiations on what can be
> expressed inside:
>
>five = 5
>eight = [8]
>def f(x,
--- 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
> > > alternati
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 eac
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 th
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
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 warn
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? Wh
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
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
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
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
>
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]) <*>
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
obj
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 wit
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(s
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 i
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)
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 th
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
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
nuisan
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 w
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 cach
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 Pyth
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 f
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
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
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, 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
[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
>>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 p
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-pack
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 cor
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 exist
At 11:13 AM 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.
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
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: ...
> Sorry, no go. You can say "supports key use cases found in real code"
> as often as you like,
Those were not empty words. I provided two non-trivial worked-out examples
taken from sre_constants.py and opcode.py. Nick provided a third example from
decimal.py. In all three cases, the proposal
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
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
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
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, y
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 la
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
46 matches
Mail list logo
