--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
string version is an anomaly.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
any string contains infinitely many
empty substrings).
No. That's what older versions of Python did, and it was changed to
the current behavior, except someone screwed up the edge case for
8-bit strings.
--
--Guido van Rossum (home page: http://www.python.org/~guido
to also take slice arguments; then everybody
ends up doing duplicate work.
If you really need this for speed, I recommend you make it a custom extension.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
, that's debatable but can't be fixed until py3k
-- surely lots of code (perhaps accidentally) depends on it.
Still unclear which one \F wanted fixed...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
? was this a real design or a Py3K bluesky idea?
I suggest to forget about that particular idea and just do what you
were thinking of originally. str.partition() and unicode.partition()
should be as simple as possible, to cover the 80% use case FAST.
--
--Guido van Rossum (home page: http
this be
('f', 'o', 'obar')
or not?
And what about:
print s2(foobar).partition(x)
Currently this prints
(s2('foobar'), '', '')
These are both fine with me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido
://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Dörwald [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 5/26/06, Walter Dörwald [EMAIL PROTECTED] wrote:
[...]
And what happens if the separator is an instance of a subclass?
class s2(str):
def __repr__(self):
return s2(%r) % str(self)
print foobar.partition(s2(o
that's the major use case.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
but warning that this
will change in 2.6.
I'm not sure what we gain by leaving other std modules depending on
struct's brokenness broken. But I may be misinterpreting which modules
you're referring to.
--
--Guido van Rossum (home page: http://www.python.org/~guido
too many uses. I wouldn't be surprised if after INCREF and
DECREF it's the most commonly used C API method...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
, Thomas proposed accepting it (whatever that means) until 3.0.
Fine with me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
.
These modules can be converted.
I think that should be done for 2.5, but nothing else. Or, perhaps
a deprecation warning could be generated if it is still used.
I'll let Martin decide this one.
--
--Guido van Rossum (home page: http://www.python.org/~guido
be
polymorphic. read() can't be due to the asymmetry in the API. I guess
struct objects are different.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
), count, etc.
Although Tim pointed out that replace() only regards
n+1 empty strings as existing in a string of lenth
n. So for consistency, find() should only find them
in those places, too.
And abc.count() should return 4.
--
--Guido van Rossum (home page: http://www.python.org/~guido
proposal (int as ABC and two
subclasses that may remain anonymous to the Python user); it'll save
the alignment waste for short ints and will let us use a smaller int
type for the size for long ints (if we care about the latter).
--
--Guido van Rossum (home page: http://www.python.org/~guido
Seems ok, except I don't know what the backwards incompatibilities would be...
On 5/30/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Bob Ippolito wrote:
It seems that we should convert the crc32 functions in binascii,
zlib, etc. to deal with unsigned integers.
+1!!
--
--Guido van Rossum
that the binaries produced by the
Sun compiler segfault... :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
an underscore before _into.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it ASAP IMO.)
While we're still using SF, developers should probably get in the
habit of sending an email to the assignee when assigning a bug...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
it is an
obstacle. (I do understand your use case -- I just don't believe it's
as important as the bug-catching property you'd be throwing away by
supporting that use case.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
a buffer from a
(unicode) string at all.
Unhelpfully,
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
()
lmnop
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http
to maintain compatibility, so be it.
Really? The old situation is really evil, and the new approach is at
least marginally better by giving users a way to migrate to a new
non-evil approach. What exactly is the backwards incompatibility you
speak of?
--
--Guido van Rossum (home page: http://www.python.org
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 6/9/06, Nicko van Someren [EMAIL PROTECTED] wrote:
On 9 Jun 2006, at 17:44, Guido van Rossum wrote:
This is an elaborate joke, right?
On 6/9/06, Noam Raphael [EMAIL PROTECTED] wrote:
...
It's simply this: Currently, the expression x[] is a syntax
error. I
suggest
, such code would have to be changed.
--Guido
On 6/12/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote:
I notice that file() throws an IOError when it detects an invalid mode
string. Wouldn't a ValueError be more appropriate?
--
--Guido van Rossum (home page: http://www.python.org/~guido
to it going
forward, and that we try to get rid of it as we can.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido
this only if the imported module is really a Java
package. If it's a Python package it should stick to python semantics
if possible.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
On 6/12/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote:
On 6/12/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
IOW I think PEP 360 is an unfortunate historic accident, and we would
be better
on Python 3000.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
On 6/12/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I personally think that, going forward, external maintainers should
not be granted privileges such as are being granted by PEP 360, and
an inclusion of a package in the Python tree should be considered a
fork
any instances of that actually happened? That would be a problem
with *any* code in the Python library, not just external
contributions, so I'm not sure why external contribions should be
treated any differently here.
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 6/12/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Yup, although it's a change in behavior that would need to be studied
carefully for backwards incompatibilities. Usually it's given as a
constant, so there won't be any problems; but there might be code
annoying
changes, I agree it should be left for P3K now regardless. I'll
change the PEP accordingly to make this explicit.
Agreed again. Thanks for updating the PEP.
PS Tim: did you get my private email about SequenceMatcher?
--
--Guido van Rossum (home page: http://www.python.org/~guido
No, because ValueError is the better exception for an invalid mode string.
On 6/12/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 6/12/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Yup, although it's a change in behavior that would need
On 6/12/06, Edward C. Jones [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
developers contributing code without wanting
to give up control are the problem.
That hits the nail on the head. If something is added to the standard
library, it becomes part of Python and must be controlled
are.
Agreed.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
it
themselves (or defend their change -- so a public discussion can
ensue).
Disagreements should not be settled by battling checkins; I'd like to
see that developers who ignore this rule repeatedly risk having their
commit privileges taken away temporarily.
--
--Guido van Rossum (home page: http
? This might be a good OpenSpace topic if you
haven't already secured your speaking slot. It so happens that I saw a
talk about Mercurial at last week's baypiggies meeting and the author
claimed that it's as fast as Git.
--
--Guido van Rossum (home page: http://www.python.org/~guido
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
Is it perhaps time to move this discussion to c.l.py? The behavior
isn't going to change.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
.
That cannot be the only motivation. He can have mutable values today
without any new syntax. (Either he can use x[()] or he can use
attribute assignment.)
But more to the point, this discussion is pointless, since I won't
accept the syntax change.
--
--Guido van Rossum (home page: http
this to generate a computed goto, and I
don't see a need for that -- if we decide to add that (either as
syntax or as an automatic optimization) I see no problem adding a new
bytecode. Python's bytecode is not sacred or frozen like Java's.
--
--Guido van Rossum (home page: http://www.python.org/~guido
On 6/18/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
On 6/18/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The 'bug fix' solution would be:
1. Change main.c and PySys_SetPath so that '' is NOT prepended to
sys.path
when the -m
On 6/18/06, Noam Raphael [EMAIL PROTECTED] wrote:
2006/6/18, Guido van Rossum [EMAIL PROTECTED]:
But more to the point, this discussion is pointless, since I won't
accept the syntax change.
OK, too bad!
But don't say I haven't warned you, when you will all use my fabulous
package and get
.
But it could theoretically affect search order for other modules. I
still see nothing wrong with . After all that's also the default if
you run a script using python path/to/file.py .
--
--Guido van Rossum (home page: http://www.python.org/~guido
to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that a switch should only exist for speedup.
--
--Guido van Rossum (home page: http://www.python.org/~guido
be surprised if that rewrite were to use pure
Python code.) Py3k will be released later than Python 2.6, but most
likely before 2.7.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
-- others will weigh in there).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
TypeError and
AttributeError is hopeless. But if you want to submit a patch to
reduce a particular bit of inconsistency (without increasing it
elsewhere) it might well be accepted.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 6/18/06, Josiah Carlson [EMAIL PROTECTED] wrote:
[...] Offering arbitrary expressions whose
meaning can vary at runtime would kill any potential speedup (the
ultimate purpose for having a switch statement
. OTOH the hash table semantics
don't require us to commit to a definition of hashable, which is an
advantage.
How's that for a wishy-washy answer. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
someone give a complete implementation a try, and then try
to modify as much standard library code as possible to use it. Then
report back. That would be a very interesting experiment to do. (And
thanks for the pointer to sre_compile.py as a use case!)
--
--Guido van Rossum (home page: http
van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
game.
Georg, are you up to it?
Georg is a bot? :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On 6/19/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
Perhaps I misunderstood Josiah's comment; I thought he was implying
that a switch should be significantly *faster* than if/elif, and was
arguing against features that would jeopardize that speedup
over; it's still mostly relevant.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
On 6/20/06, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Well, the hypothetical use case is one where we have an arbitrary
object of unknown origin or type, and we want to special-case
treatment for a few known values.
I'd need convincing that this use case is anything
On 6/20/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:26 PM 6/21/2006 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
But it would be easy enough to define a dict-filling function that
updates only new values.
Or evaluate the case expressions in reverse order.
-1; stepping
On 6/20/06, Guido van Rossum [EMAIL PROTECTED] wrote:
case A: ... if x == A...
cases S: ...if x in A...
or perhaps (saving a keyword):
case A: ... if x == A...
case in S: ...if x in A...
I was too quick with cut/paste here; I meant
case S: ...if x in S...
or
case in S
it a bit I think that if it's not immediately
contained in a function, it should be implemented as alternative
syntax for an if/elif chain.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
reason for the syntax
to be different from if/elif chains.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On 6/21/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
if you're now in the efficiency camp
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
After thinking about it a bit I think that if it's not immediately
contained in a function, it should be implemented as alternative
syntax for an if/elif chain.
That worries me a little
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:55 AM 6/21/2006 -0700, Guido van Rossum wrote:
BTW a switch in a class should be treated the same as a global switch.
But what about a switch in a class in a function?
Okay, now my head hurts. :)
Welcome to the club. There's a Monty
++ programmers
beware, although the syntax is familiar, this is really a name-binding
statement, not a value-copying statement.
There are many other examples. Function and class definition for
example (look like definitions but are run-time constructs unlike in
most other languages). Etc.
--
--Guido van
= expression
if var == constant sre.FOO:
...
elif var == constant sre.BAR:
...
elif var in constant (sre.FIE, sre.FUM):
...
This gets pretty repetitive. One might suggest that 'case' could imply
'constant'...?
--
--Guido van Rossum (home page: http
the paths have changed. Are there other options to get rid of the warnings?
Check out the -W command line option and the warnings module. These
document how to suppress warnings.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
this feeling, surely you're overusing global.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
an interesting question for the language lawyers.
That's no problem for the parser, as long as the expressions are
indented. ABC did this.
But I think I like an explicit case keyword better; it gives a better
error message if the indentation is forgotten.
--
--Guido van Rossum (home page: http
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:16 PM 6/21/2006 -0700, Guido van Rossum wrote:
Yeah, but if you have names for your constants it would be a shame if
you couldn't use them because they happen to be defined in the same
scope.
Maybe the real answer is to have a const
On 6/22/06, Greg Ewing [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
switch x:
case == 1: foo(x)
Aesthetically, I don't like that.
Me neither.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
where to store the dict.
I'd say that we should just add a warning against switches in nested
functions that are called only once per definition.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
property of names, just like global. But that requires too much
repetition when a constant is imported.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
# exposure, but I think I prefer the explicit
when using approach...
It may be not enough C# exposure, but I don't know exactly which
approach you are referring to.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x)
2: bar(x
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you
On 6/22/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
So the constant would be evaluated at function definition time? I find
that rather confusing.
well, I find the proposed magic behaviour of case at least as confusing...
It's not magic if it can be explained. def
you can see what I'm actually proposing, before
the minutiae of responding the objections you raised to stuff I threw out
either in my previous message or the message before that. Hopefully this
will help.
At 10:44 AM 6/22/2006 -0700, Guido van Rossum wrote:
Please, think through the notion
On 6/22/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
It's not magic if it can be explained. def goes over all the cases
and evaluates them in the surrounding scope and freezes the meaning of
the cases that way as long as the function object survives is not
magic
van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote:
Summarizing our disagreement, I think you feel that
freeze-on-first-use is most easily explained and understood while I
feel that freeze-at-def-time is more robust. I'm not sure how to get
On 6/23/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition. If there is no surrounding function definition
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 name = expression
which would be similar to
name = static (expression)
but also prevents
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 different
really hairy code. The semantics aren't 100% clear.
I'm all for telling people you can do that yourself or even here is
a standard library module that solves your problem. But the solution
needs to satisfy a certain cleanliness standard.
--
--Guido van Rossum (home page: http://www.python.org/~guido
are static and disallow
assignments to these. It would also have to export __dict__ as a proxy
that disallows such assignments. I think it can be made to work.
I do think this would require static names as well as static
expressions. This is definitely still in the brainstorm phase!
--
--Guido van
901 - 1000 of 5880 matches
Mail list logo
