--- "Martin v. L�wis" <[EMAIL PROTECTED]> wrote:
> The specific question was
>
> "Is there a way to set the warning options via an environment variable?"
>
> This has nothing to do with beta1; the warnings module was introduced
> many releases ago, along with all the mechanics to disable warni
--- Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > Thanks! This does the trick for me:
> >
> > #if PY_VERSION_HEX >= 0x0203
> > PyObject_CallFunction(
> > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
> > #else
> >
[/F]
> SC22WG14? is that some marketing academy? not a very good one, obviously.
That's because it's European ;-) The ISO standards process has highly
visible layers of bureaucracy, and, in full, JTC1/SC22/WG14 is just
the Joint ISO/IEC Technical Committee 1's SubCommittee 22's Working
Group 14
Guido van Rossum wrote:
> On 6/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>> > I don't get what the problem is here. A switch constant should have
>> > exactly the bahavior of a default value of a function parameter. We
>> > don't seem to have too many problems defining function
Guido van Rossum wrote:
> That sounds like a good solution all around. I hope that others can
> also find themselves in this.
>
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no su
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> SC22WG14? is that some marketing academy? not a very good one,
>> obviously.
>
> http://www.open-std.org/jtc1/sc22/wg14/
>
> Looks like python-dev for C, only with extra servings of international
> bureaucracy and ve
Fredrik Lundh wrote:
> Nick Maclaren wrote:
>
>> Unfortunately, that doesn't help, because it is not where the issues
>> are. What I don't know is how much you know about numerical models,
>> IEEE 754 in particular, and C99. You weren't active on the SC22WG14
>> reflector, but there were some lu
Thomas Heller wrote:
> Is it possible to take the CVS repository files (they can be accessed
> with rsync), and import that, preserving the whole history, into SVN?
Yes:
http://cvs2svn.tigris.org/
You just need a maintainer of the Python SVN repository to load the dump
files this tool generates.
> > In that case, I would argue that the proposed syntax is misleading.
> > Regardless of how it is implemented, a switch statement is
> > conceptually a chain of if/elif statements. As such, the 'in'
> > keyword, if it is allowed at all, should behave like it does in if
> > statements, rather tha
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote:
> Well, you can't "def" a dotted name, but I realize this isn't a
> binding.
I have actually wanted to do that before. It would be nice if you
could. :)
James
___
Python-Dev mailing list
Python-De
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> This is a good thing, because if switch/case ends up functionally
> identical to if/elif/else, then it has no purpose as a construct. On
> the other hand, because it is different from if/elif/else, and it is
> different in such a way to make
"Eric Sumner" <[EMAIL PROTECTED]> wrote:
>
> On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > No; in order to make it possible to use a single dict lookup for
> > dispatch, the set members are expanded into the dict key. If you have
> > a large contiguous range, you'll be better off (s
Ralf W. Grosse-Kunstleve wrote:
> Thanks! This does the trick for me:
>
> #if PY_VERSION_HEX >= 0x0203
> PyObject_CallFunction(
> (PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
> #else
> PyRange_New(start, len, step, 1)
> #endif
>
> I am compiling the
On Fri, 23 Jun 2006 13:38:35 -0700, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
>On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote:
>
>> Please keep Python simple.
>
>+1 on this sentiment.
>
I agree.
Jean-Paul
___
Python-Dev mailing list
Python-D
On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> No; in order to make it possible to use a single dict lookup for
> dispatch, the set members are expanded into the dict key. If you have
> a large contiguous range, you'll be better off (sometimes *much*
> better) doing an explicit if/elif c
On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Here are a few examples showing my objections against first-use.
[Problem with nested scopes; today this usually shows up as (invalid)
bug reports about lambda, in which failure to bind a "default"
variable "to itself" causes it to take on
On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote:
> Please keep Python simple.
+1 on this sentiment.
I use switch statements all the time in C, but I'd rather not see them
in Python - even though I'd use them if they were there! - purely to
keep the cognitive overhead low.
http:
This post is too long for me to respond right now. I'm inviting others
to respond. I've got a feeling you're coming late to this discussion
and we're going around in circles.
--Guido
On 6/23/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> In http://mail.python.org/pipermail/python-dev/2006-June/06640
On 6/23/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE
> wrote:
> >> Python prefers to evaluate expressions in the order that they
> >> appear in source code, ... "first-time use" preserves that
> >> property; "function definit
In http://mail.python.org/pipermail/python-dev/2006-June/066409.html,
Guido wrote
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
(A) I prefer a term other than 'static'.
Looking at various c
Thomas Heller wrote:
> What I did was at a certain time develop in the 'branch_1_0' branch, leaving
> HEAD for experimental work. Later I decided that this was wrong, cvs removed
> all
> files in HEAD, and added them back from a branch_1_0 checkout. Maybe doing
> this was another bad idea, as th
In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE wrote:
>> Python prefers to evaluate expressions in the order that they
>> appear in source code, ... "first-time use" preserves that
>> property; "function definition time" does not.
Guido wrote:
> But first-time has the ve
On 6/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Hm. Did I miss something, or did we just solve builtin lookup
> optimization? The only problem I see is that currently you can stick a new
> version of 'len()' into a module from outside it, shadowing the
> builtin. Under this scheme (of ma
Ralf W. Grosse-Kunstleve wrote:
>>> Is there a way to set the warning options via an environment variable?
>> This is off-topic for python-dev,
>
> What is the channel I should use? (I am testing a beta 1.)
The specific question was
"Is there a way to set the warning options via an environment v
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 would be added next: do while or goto? The
urge to add s
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> You later stated that decorators were the wrong way of handling it. I
> believe that the...
> static =
> ...would require too many changes to what some regular python users have
> come to expect from at least module namespaces. I have n
On 6/23/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > (3) A switch is implemented using a dict which is precomputed at the
> > same time its static expressions are precomputed. The switch
> > expression must be hashable. Overlap between different cases will
> > raise an
On 6/23/06, Eric Sumner <[EMAIL PROTECTED]> wrote:
> On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > (3) A switch is implemented using a dict which is precomputed at the
> > same time its static expressions are precomputed. The switch
> > expression must be hashable. Overlap between dif
At 07:51 PM 6/23/2006 +0200, M.-A. Lemburg wrote:
>Furthermore, the compiler could do other optimizations on the
>const declared names, such as optimizing away global lookups
>and turning them into code object constants lookups.
Technically, they'd have to become LOAD_DEREF on cells set up by the
Nick Maclaren wrote:
> The standard floating-point model is that it maps functions defined on
> the reals (sometimes complex) to approximations defined on floating-
> point.
OK.
> The conventional interpretation was that any operation that
> was not mathematically continuous in an open region in
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > > Independent from this, I wonder if we also need static names of the form
> > >
> > > static =
> > >
> > > which would be similar to
> >
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> (3) A switch is implemented using a dict which is precomputed at the
> same time its static expressions are precomputed. The switch
> expression must be hashable. Overlap between different cases will
> raise an exception at precomputation ti
Reading on in the thread it seems that there's agreement
on using "static" instead of "const", to s/const/static
:-)
M.-A. Lemburg wrote:
> Georg Brandl wrote:
>> M.-A. Lemburg wrote:
>>
>>> A nice side-effect would be that could easily use the
>>> same approach to replace the often used default-a
[delurking in response to the first really decisive message in the thread] ;-)
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
FWIW, +1.
Georg Brandl wrote:
> M.-A. Lemburg wrote:
>
>> A nice side-effect would be that could easily use the
>> same approach to replace the often used default-argument-hack,
>> e.g.
>>
>> def fraction(x, int=int, float=float):
>> return float(x) - int(x)
>>
>> This would then read:
>>
>> def fractio
"Alex Martelli" <[EMAIL PROTECTED]> wrote:
> On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Independent from this, I wonder if we also need static names of the form
> >
> > static =
> >
> > which would be similar to
> >
> >= static ()
> >
> > but also prevents from being assi
On 6/23/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Independent from this, I wonder if we also need static names of the form
> >
> > static =
> >
> > which would be similar to
> >
> >= static ()
> >
> > but also prevents from b
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > (1) An expression of the form 'static' has the semantics of
> > evaluating the atom at the same time as the nearest surrounding
> > function definition. If there is no surrounding function d
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expres
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluate
>> I think the best would be to import it into an url like
>>
>> http://svn.python.org/projects/sandbox/trunk/ctypes/
>>
>> Is it possible to take the CVS repository files (they can be accessed
>> with rsync), and import that, preserving the whole history, into SVN?
>
Gustavo Niemeyer schrieb:
> I think the best would be to import it into an url like
>
> http://svn.python.org/projects/sandbox/trunk/ctypes/
>
> Is it possible to take the CVS repository files (they can be accessed
> with rsync), and import that, preserving the whole history, into SVN?
It should be possible to use cvs2s
On 6/23/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Is it possible to take the CVS repository files (they can be accessedwith rsync), and import that, preserving the whole history, into SVN?I don't remember a svn-specific tool for it (although I am fairly out of touch in that regard). However, if
[Kevin Jacobs]
> ...
> A good place to start: You mentioned earlier that there where some
> nonsensical things in floatobject.c. Can you list some of the most serious
> of these?
I suspect Nick spends way too much time reading standards ;-) What he said is:
If you look at floatobject.c, you
Nick Maclaren wrote:
> Unfortunately, that doesn't help, because it is not where the issues
> are. What I don't know is how much you know about numerical models,
> IEEE 754 in particular, and C99. You weren't active on the SC22WG14
> reflector, but there were some lurkers.
SC22WG14? is that so
Nick Maclaren <[EMAIL PROTECTED]> writes:
>> > My intentions are to provide some numerically robust semantics,
>> > preferably of the form where straightforward numeric code (i.e. code
>> > that doesn't play any bit-twiddling tricks) will never invoke
>> > mathematically undefined behaviour withou
On 6/22/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> > Not a lot. Annex F in itself is only numerically insane. You need to> > know the rest of the standard, including that which is documented only> > in SC22WG14 messages, to realise the full horror.
[...]>Unfortunately, that doesn't help, beca
--- Tim Peters <[EMAIL PROTECTED]> wrote:
> [Ralf W. Grosse-Kunstleve]
> > Thanks! This does the trick for me:
> >
> > #if PY_VERSION_HEX >= 0x0203
> > PyObject_CallFunction(
> > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
>
> Note that this is extremely la
Now that ctypes is no longer an externally maintained module, imo the
repository should be moved from SF cvs to python.org svn.
The current layout is different than the main python trunk, and it
should be preserved so that I can still do standalone releases.
I think the best would be to import
Fredrik Lundh wrote:
> (now, if you're written "implied 'break'", I'm all for it)
note to self: the fact that it's a holiday doesn't mean that you should
post before you'd had enough coffee.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
[Ralf W. Grosse-Kunstleve]
> Thanks! This does the trick for me:
>
> #if PY_VERSION_HEX >= 0x0203
> PyObject_CallFunction(
> (PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
Note that this is extremely lax about possible overflow in the
arithmetic. For that rea
Fredrik Lundh wrote:
> I'd still prefer the "explicit is better than implicit" route, approach
> switch/case (if added) is defined in terms of if/elif, and optimizations
> are handled by the optimizer/code generator.
s/approach/where/
___
Python-De
Guido van Rossum wrote:
> That sounds like a good solution all around. I hope that others can
> also find themselves in this.
>
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no su
Phillip J. Eby wrote:
> I think I like it. I was confused by what Fredrik meant by "const", but
> your renaming it to "static" makes more sense to me;
footnote: I suggested static in my list of use cases; while "const"
makes sense in many cases, "static" makes more sense for things like this:
54 matches
Mail list logo
