Martin v. Löwis wrote:
> I think Fredrik Lundh points to svk at such occasions.
SVK makes it trivial to mirror a remote SVN repository, and make zillions
of local light-weight branches against that repository (e.g.one branch
per bug you're working on); see e.g.
http://gcc.gnu.
Michael Hudson wrote:
> Could it just be that instantiating instances of new-style classes is
> slower than instantiating instances of old-style classes? There's not
> anything in what you've posted to suggest that exceptions are involved
> directly.
python -mtimeit -s "class Exception(object):
Fredrik Lundh wrote:
>> Could it just be that instantiating instances of new-style classes is
>> slower than instantiating instances of old-style classes? There's not
>> anything in what you've posted to suggest that exceptions are involved
>> direc
so, which one is correct ?
Python 2.4.3
>>> "".replace("", "a")
''
>>> u"".replace(u"", u"a")
u'a'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
>>> -1 * (1, 2, 3)
()
>>> -(1, 2, 3)
Traceback (most recent call last):
File "", line 1, in
TypeError: bad operand type for unary -
We Really Need To Fix This!
[\F]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Guido van Rossum wrote:
>> We Really Need To Fix This!
>>
>> [\F]
>
> Doesn't the real effbot have /F as sig?
yeah, we've had some trouble with fake bots lately. I mean, there's a
timbot posting to this thread, but I know for sure that the real Tim got
tired of hacking on Python earlier tonig
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Fredrik Lundh wrote:
> no need to wait for any raymond-cycles here; just point me to the latest
> version of the proposal, and it'll be in the trunk within 30 minutes.
are these still valid?
http://mail.python.org/pipermail/python-dev/2005-August/055764.html
http://mail
Sean Reifschneider wrote:
>> - Treat the negative as a reverser, so we get back (3, 2, 1).
>
> Then we could get:
>
>>>> print -123
>321
>
> Yay!
and while we're at it, let's fix this:
>>> 0.66 * (1, 2, 3)
(1, 2)
and maybe even this
>>> 0.5 * (1, 2, 3)
(1, 1)
bu
Fred L. Drake, Jr. wrote:
> Even better:
>
> "123"*-1
>
> We'd get to explain:
>
> - what the "*-" operator is all about, and
>
> - why we'd use it with a string and an int.
>
> I see possibilities here. :-)
the infamous "*-" clear operator? who snuck that one into python?
_
Guido van Rossum wrote:
> I don't know what epoll is.
>
> On a related note, perhaps the needforspeed folks should look into
> supporting kqueue on systems where it's available? That's a really
> fast BSD-originated API to replace select/poll. (It's fast due to the
> way the API is designed.)
ro
Raymond Hettinger wrote:
> 1) Is str.rpartition() still wanted?
>
> Yes.
I might have missed my earlier 30-minute deadline with one minute (not
my fault! I was distracted! seriously!), but this time, I actually
managed to get the code in there *before* I saw the pronouncement ;-)
_
several string methods accepts either strings or objects that support
the buffer api, and ends up raising a "expected a character buffer
object" error if you pass in something else. this isn't exactly helpful
for non-experts -- the term "character buffer object" doesn't appear in
any python tu
Terry Reedy wrote:
>> def isgenerator(func):
>>return func.func_code.co_flags == 99
>>
>> but it is rather ugly (horrible indeed).
>
> To me, part of the beauty of Python is that is so easy to write such things
> so compactly, so that we do not need megaAPIs with hundreds of functions
> and
Neal Norwitz wrote:
>> Also, it would be easy to detect METH_OLDARGS in PyCFunction_New and raise
>> an appropriate exception.
>
> I agree with Martin this should raise a deprecation warning in 2.5.
why?
this is a clear case of unnecessary meddling. removing it won't remove
much code (a whopp
Armin Rigo wrote:
> As it turns out, I measured only 0.5% performance loss in Pystone.
umm. does Pystone even call lookdict?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
Thomas Wouters wrote:
> I know which 'it' I meant: the same 'it' as struct already accepts in
> Python 2.4 and before. Yes, it's inconsistent between formatcodes and
> valuetypes -- fixing that the whole point of the change -- but that's
> how you define 'compatibility'; struct, by default, sho
Armin Rigo wrote:
> At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously on
> the tests I try to time, and even going into an infinite loop consuming
> all my memory - since the NFS sprint. Am I allowed to be grumpy here,
> and repeat that speed should not be used to justify bugs
Armin Rigo wrote:
> Ah, it's a corner case of str.find() whose behavior just changed.
> Previously, 'abc'.find('', 100) would return -1, and now it returns 100.
> Just to confuse matters, the same test with unicode returns 100, and has
> always done so in the past. (Oh well, one of these again...
Guido van Rossum wrote:
>>> well, the empty string is a valid substring of all possible strings
>>> (there are no "null" strings in Python). you get the same behaviour
>>> from slicing, the "in" operator, "replace" (this was discussed on the
>>> list last week), "count", etc.
>
>> Although Tim p
Armin Rigo wrote:
> I know this. These corner cases are debatable and different answers
> could be seen as correct, as I think is the case for find(). My point
> was different: I was worrying that the recent change in str.find() would
> needlessly send existing and working programs into infinite
Tim Peters wrote:
"abc".count("", 100)
> 1
u"abc".count("", 100)
> 1
which is the same as
>>> "abc"[100:].count("")
1
"abc".find("", 100)
> 100
u"abc".find("", 100)
> 100
>
> today, although the idea that find() can return an index that doesn't
> exist in the string is parti
Neal Norwitz wrote:
> I've been starting to get some of the buildbots working again. There
> was some massive problem on May 25 where a ton of extra files were
> left around. I can't remember if I saw something about that at the
> NFS sprint or not.
bob's new _struct module was checked in on Ma
Georg Brandl wrote:
> > I'd be satisfied with a deprecation warning for PyArg_Parse, though we
> > (*) should really figure out how to make it work on Windows. I
> > haven't seen anyone object to the C compiler deprecation warning.
>
> There is something at
> http://msdn2.microsoft.com/en-us/libr
Martin v. Löwis wrote:
>> That's why I'd like my alternative 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)
Georg Brandl wrote:
>> and links to
>>
>> http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx
>>
>> which provides a pragma that does the same thing, and is documented to work
>> for both C and C++, and also works for macros.
>
> But we'd have to use an #ifdef for every deprecated function
M.-A. Lemburg wrote:
> AFAIK, there were no real issues with pybench, only with the
> fact that time.clock() (the timer used by pybench) is wall-time
> on Windows and thus an MP3-player running in the background
> will cause some serious noise in the measurements
oh, please; as I mentioned back
M.-A. Lemburg wrote:
> Seriously, I've been using and running pybench for years
> and even though tweaks to the interpreter do sometimes
> result in speedups or slow-downs where you wouldn't expect
> them (due to the interpreter using the Python objects),
> they are reproducable and often enough h
Neal Norwitz wrote:
> Any ideas?
this is a recent change, so it looks like the box simply didn't get
around to rebuild the unicodeobject module.
(I'm beginning to wonder if I didn't forget to add some header file
dependencies somewhere during the stringlib refactoring, but none of the
other b
M.-A. Lemburg wrote:
> Of course, but then changes to try-except logic can interfere
> with the performance of setting up method calls. This is what
> pybench then uncovers.
I think the only thing PyBench has uncovered is that you're convinced that it's
always right, and everybody else is always
M.-A. Lemburg wrote:
> I believe that using wall-clock timers
> for benchmarking is not a good approach due to the high
> noise level. Process time timers typically have a lower
> resolution, but give a better picture of the actual
> run-time of your code and also don't exhibit as much noise
> as
Terry Reedy wrote:
> But even better, the way to go to run comparison timings is to use a system
> with as little other stuff going on as possible. For Windows, this means
> rebooting in safe mode, waiting until the system is quiescent, and then run
> the timing test with *nothing* else active
M.-A. Lemburg wrote:
> I just had an idea: if we could get each test to run
> inside a single time slice assigned by the OS scheduler,
> then we could benefit from the better resolution of the
> hardware timers while still keeping the noise to a
> minimum.
>
> I suppose this could be achieved by:
Martin v. Löwis wrote:
>> since process time is *sampled*, not measured, process time isn't exactly in-
>> vulnerable either.
>
> I can't share that view. The scheduler knows *exactly* what thread is
> running on the processor at any time, and that thread won't change
> until the scheduler makes
Martin v. Löwis wrote:
> Sure: when a thread doesn't consume its entire quantum, accounting
> becomes difficult. Still, if the scheduler reads the current time
> when scheduling, it measures the time consumed.
yeah, but the point is that it *doesn't* read the current time: all the
system does it
Tim Peters wrote:
> Maybe this varies by Linux flavor or version? While the article above
> was published in 2001, Googling didn't turn up any hint that Linux
> jiffies have actually gone away, or become better loved, since then.
well, on x86, they have changed from 10 ms in 2.4 to 1 ms in early
Phillip J. Eby wrote:
> If this *has* to be added to the modules that don't currently do any
> logging, can we please delay the import until it's actually needed?
now that we've had a needforspeed sprint, it's clear that it's time to
start working on slowing things down again ;-)
> I think it
Thomas Heller wrote:
> In Include/structmember.h, there is no T_... constant for Py_ssize_t
> member fields. Should there be one?
do you need one? if so, I see no reason why you cannot add it...
___
Python-Dev mailing list
Python-Dev@python.org
htt
Jim Jewett wrote:
> For pkgutil in particular, the change is that instead of writing to
> stderr (which can scroll off and get lost), it will write to the
> errorlog. In a truly default setup, that still ends up writing to
> stderr.
umm. if pkgutil fails to open a pkg file, isn't it rather like
Jim Jewett wrote:
> The existing logging that she is replacing is done through methods of
> the dispatcher class. The dispatcher class is only a portion of the
> whole module.
the dispatcher class is never used on its own; it's a base class for
user-defined communication classes.
asyncore user
Jim Jewett wrote:
> This does argue in favor of allowing the more intrusive additions to
> handlers and default configuration. It would be useful to have a
> handler that emitted only Apache log format records, and saved them
> (by default) to a rotating file rather than stderr.(And it *might*
>
M.-A. Lemburg wrote:
> This example is a bit misleading, since chances are high that
> the benchmark will get a good priority bump by the scheduler.
which makes it run infinitely fast ? what planet are you buying your
hardware on ? ;-)
___
Python-D
M.-A. Lemburg wrote:
> * Linux:
>
> time.clock()
> - not usable; I get timings with error interval of about 30%
> with differences in steps of 100ms
> resource.getrusage()
> - error interval of less than 10%; overall < 0.5%
> with differences in steps of 10ms
hmm. I cou
M.-A. Lemburg wrote:
> One interesting difference I found while testing on Windows
> vs. Linux is that the StringMappings test have quite a different
> run-time on both systems: around 2500ms on Windows vs. 590ms
> on Linux (on Python 2.4). UnicodeMappings doesn't show such
> a signficant differen
M.-A. Lemburg wrote:
> Some more interesting results from comparing Python 2.4 (other) against
> the current SVN snapshot (this):
been there, done that, found the results lacking.
we spent a large part of the first NFS day to investigate all
reported slowdowns, and found that only one slowdown c
Raymond Hettinger wrote:
> When the result of an expression is None, the interactive interpreter
> correctly suppresses the display of the result. However, it also
> suppresses the underscore assignment. I'm not sure if that is correct
> or desirable because a subsequent statement has no wa
M.-A. Lemburg wrote:
> Still, here's the timeit.py measurement of the PythonFunctionCall
> test (note that I've scaled down the test in terms of number
> of rounds for timeit.py):
>
> Python 2.4:
> 10 loops, best of 3: 21.9 msec per loop
> 10 loops, best of 3: 21.8 msec per loop
> 10 loops, best
M.-A. Lemburg wrote:
> I put the headings for the timeit.py output on the
> wrong blocks. Thanks for pointing this out.
so how do you explain the Try/Except results, where timeit and pybench
seems to agree?
___
Python-Dev mailing list
Python-Dev@py
M.-A. Lemburg wrote:
> The pybench results match those of timeit.py on my test machine
> in both cases. I just mixed up the headers when I wrote the email.
on a line by line basis ?
> Testnamesminimum run-timeaverage run-time
> th
M.-A. Lemburg wrote:
> The pybench results match those of timeit.py on my test machine
> in both cases.
but they don't match the timeit results on similar machines, nor do they
reflect what was done at the sprint.
> Tools/pybench> ~/projects/Python/Installation/bin/python Calls.py
> 10 loops,
M.-A. Lemburg wrote:
> The results were produced by pybench 2.0 and use time.time
> on Linux, plus a different calibration strategy. As a result
> these timings are a lot more repeatable than with pybench 1.3
> and I've confirmed the timings using several runs to make sure.
can you check in 2.0 ?
M.-A. Lemburg wrote:
> Huh ? They do show the speedups you achieved at the sprint.
the results you just posted appear to show a 20% slowdown for function
calls, and a 10% speedup for exceptions.
both things were optimized at the sprint, and the improvements were
confirmed on several machines.
Ka-Ping Yee wrote:
> Quite a few people have expressed interest in having UUID
> functionality in the standard library, and previously on this
> list some suggested possibly using the uuid.py module i wrote:
>
> http://zesty.ca/python/uuid.py
+1!
> This module provides a UUID class, functio
M.-A. Lemburg wrote:
> You can download a current snapshot from:
>
> http://www.egenix.com/files/python/pybench-2.0-2006-06-09.zip
believe it or not, but this hangs on my machine, under 2.5 trunk. and
it hangs hard; nether control-c, break, or the task manager manages to
kill it.
if it's any
[EMAIL PROTECTED] wrote:
> Fredrik> 6. Combine 2 and 3: require the user to pass in a MAC argument
> Fredrik> to uuid1, but provide a SlowGetMacAddress helper that wraps
> Fredrik> the existing code.
>
> Or make the MAC address an optional arg to uuid1. If given, use it.
Ka-Ping Yee wrote:
> And from a syntax perspective, it's a bad idea. x[] is much
> more often a typo than an intentional attempt to index a
> zero-dimensional array.
but how often is it a typo?
for example, judging from c.l.python traffic, forgetting to add a return
statement is a quite common
Neal Norwitz wrote:
> There is still the missing documentation for ctypes and element tree.
> I know there's been progress on ctypes. What are we going to do about
> ElementTree? Are we going to have another undocumented module in the
> core
if all undocumented modules had as much documentatio
Fred L. Drake, Jr. wrote:
> With the introduction of the xmlcore package in Python 2.5, should we
> document
> xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I
> don't think they're going to get xml.etree, which will be really confusing.
> We can be sure that xmlcore.
Simon Percivall wrote:
>> how about tweaking the xml loader to map "xml.foo" to "_xmlplus.foo"
>> only if that subpackage really exists ?
>
> I'm a bit confused by what the problem is. I though this was all
> handled like it should be now.
that's how I thought things were done, but then I read F
Talin wrote:
> I don't have any specific syntax proposals, but I notice that the suite
> that follows the switch statement is not a normal suite, but a
> restricted one, and I am wondering if we could come up with a syntax
> that avoids having a special suite.
don't have K&R handy, but I'm pre
Guido van Rossum wrote:
> Maybe we should get serious about slimming down the core distribution
> and having a separate group of people maintain sumo bundles containing
> Python and lots of other stuff.
there are already lots of people doing that (most Linux distributions add
stuff, directly
or
Brett Cannon wrote:
> But I don't think this is trying to say they don't care. People just want
> to lower the overhead of maintaining the distro.
well, wouldn't the best way to do that be to leave all non-trivial maintenance
of a
given component to an existing external community?
(after all,
Bill Janssen wrote:
> If it's Python, it has to comply with the Python specification,
> regardless of what Java does.
what specification ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
I just ran the PIL test suite using the current Python trunk, and the
tests for a user-contributed plugin raised an interesting exception:
ValueError: can't unpack IEEE 754 special value on non-IEEE platform
fixing this is easy, but the error is somewhat confusing: since when is
a modern Intel
Phillip J. Eby wrote:
> I'd still rather have a Packages/ directory, but beggars can't be
> choosers.
there's plenty of time to work on that for 2.6...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
Phillip J. Eby wrote:
> I just want changes made by the Python core developers to be reflected in
> the external releases.
and presumably, the reason for that isn't that you care about your ego,
but that you care about your users.
___
Python-Dev ma
Tim Peters wrote:
> Which OS and compiler were in use? A possible cause is that the
> platform didn't supply #defines for SIZEOF_DOUBLE and/or SIZEOF_FLOAT
> when Python was compiled. This was, e.g., true on Windows before rev
> 46065.
and looking again, I was indeed running 2.5 alpha 2 (revisi
M.-A. Lemburg wrote:
> Here's the command I used:
>
> svn copy svn+pythonssh://[EMAIL PROTECTED]/external/pybench-2.0 \
> svn+pythonssh://[EMAIL PROTECTED]/python/trunk/Tools/pybench
>
> Am I missing some final slash in the copy command or is there
> a different procedure which should
pronounced on this in May:
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 5/4/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > I'm +1 on adding --help and --version, +1 on adding -? and /? for
windows only,
> > -0=slightly sceptical
M.-A. Lemburg wrote:
> Since replace() only works on string objects, it appears
> as if a temporary string object would have to be created.
> However, this would involve an unnecessary allocation
> and copy process... it appears as if the refactoring
> during the NFS sprint left out that case.
wha
Giovanni Bajo wrote:
> It was discussed before, and the agreement was to use VS 2003 for another
> cycle
> (i.e. 2.5). But the fact that VS 2003 is no longer available for download is
> an
> important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages
M.-A. Lemburg wrote:
> The winerror module is intended to be able to use symbolic
> names for code using .winerror (much like the errno
> serves this purpose for .errno).
couldn't this be implemented as an extra table in errno instead ?
___
Python-De
Aahz wrote:
> Did we make a final decision about whether the canonical location for
> ElementTree should be xml or xmlcore?
the original idea was to use "xml" to get the latest and greatest from
either the core or PyXML, "xmlcore" to use the bundled version. I see
no reason to change this just
Nick Coghlan wrote:
>> BTW, prove me Decimal is not fast enough, ;)
>
> C:\Python24>python -m timeit -s "x = 1.0" "x+x"
> 1000 loops, best of 3: 0.137 usec per loop
>
> C:\Python24>python -m timeit -s "from decimal import Decimal as d; x = d(1)"
> "x+x"
> 1 loops, best of 3: 48.3 usec p
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, why not just solve this on the
code generator level
Guido van Rossum wrote:
> But in most cases the 'constant' is actually an expression involving a
> global, often even a global in another module. (E.g. sre_compile.py)
> The compiler will have a hard time proving that this is really a
> constant, so it won't optimize the code.
unless we come up w
Fredrik Lundh wrote:
>> But in most cases the 'constant' is actually an expression involving a
>> global, often even a global in another module. (E.g. sre_compile.py)
>> The compiler will have a hard time proving that this is really a
>> constant, so it won&#
Guido van Rossum wrote:
>> which simply means that expr will be evaluated at function definition
>> time, rather than at runtime. example usage:
>>
>> var = expression
>> if var == constant sre.FOO:
>> ...
>> elif var == constant sre.BAR:
>> ...
>> elif var i
Guido van Rossum wrote:
>> def foo(value):
>> const bar = fie.fum
>> if value == bar:
>>...
>>
>> which would behave like
>>
>> def foo(value, bar=fie.fum):
>> if value == bar:
>> ...
>>
>> but without the "what if we pass in more than one
Guido van Rossum wrote:
>> well, I find the proposed magic behaviour of "case" at least as confusing...
>
> 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 obj
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:
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
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/
__
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.
___
Py
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
Josiah Carlson 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.
there's no shortage of Python constructs that are functionally identical
to existing constructs. as with all syntactic "sugar", the empha
Guido van Rossum wrote:
>> just map
>>
>> switch EXPR:
>> case E1:
>> ...
>> case in E2:
>> ...
>> else:
>> ...
>>
>> to
>>
>> VAR = EXPR
>> if VAR == E1:
>> ...
>> elif VAR in E2:
>> ...
>> else:
>> ...
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
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 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
Guido van Rossum wrote:
> Most school I proponents (perhaps you're the only exception) have
> claimed that optimization is desirable, but added that it would be
> easy to add hash-based optimization. IMO it's not so easy in the light
> of various failure modes of hash(). (A possible solution would
Alexander Belopolsky wrote:
> Setobject code allocates several internal objects on the heap that are
> cleaned up by the PySet_Fini function. This is a fine design choice,
> but it often makes debugging applications with embedded python more
> difficult.
given that CPython has about a dozen Fini
Nick Coghlan wrote:
> There certainly isn't anything in the code above to suggest to a reader that
> the condition attempting to guard evaluation of the switch statement might not
> do its job.
that's why the evaluation model used in the case statement needs to be explicit.
that applies to the "
Phillip J. Eby wrote:
> Hear, hear! We already have if/elif, we don't need another way to spell
> it. The whole point of switch is that it asserts that exactly *one* case
> is supposed to match
that's not true for all programming languages that has a switch construct,
though;
the common trait
Guido van Rossum wrote:
>> Is it unacceptable - or impractical - to break the addition of switch
>> to python in two (minor version separated) steps ?
>
> But what's the point? We have until Python 3000 anyway.
except that we may want to "reserve" the necessary keywords in 2.6...
__
Guido van Rossum wrote:
>> that's not true for all programming languages that has a switch construct,
>> though;
>> the common trait is that you're dispatching on a single value, not
>> necessarily that
>> there cannot be potentially overlapping case conditions.
>
> You have a point.
that can h
Gregor Lingl wrote:
> Already now, only one week after publishing it I have some very positive
> feedback and people start to use it. So I think there is some demand for
> it.
some demand != should be added to the core distribution a few days after
its first release. (and if everything that someo
Gregor Lingl wrote:
> What a shame!! An immanent bug, persistent
> for years now!
>
> Is this what Anthony Baxter calls
> "the most solid Python release ever"
do you really think stuff like this helps your cause ?
___
Python-Dev mailing list
Python-
[EMAIL PROTECTED] wrote:
> One other thought -- at PyCon, I talked with a group of
> educators. While they needed some minor tweaks to the Turtle
> module, there were no requests for an extensive rewrite or a
> fatter API. The name of the game was to have a single module
> with a minimal toolset
401 - 500 of 732 matches
Mail list logo
