Raymond Hettinger wrote:
Python 3 doesn't need it because it is possible to not give a result
at all. Python 2 does need it because we have to give *some*
result.
That's not true -- it's possible for comparisons to raise
an exception in 2.x, and they sometimes do already:
Python 2.5.4 (r254:
Nick Coghlan wrote:
Mark Dickinson wrote:
It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of our rational types would be the right
thing to do.
Isn't this only solving half the
Antoine Pitrou wrote:
We forbid comparisons when there is a real danger or ambiguity, such as unicode
vs. bytes. There is no such danger or ambiguity when comparing a decimal with a
float.
So do you think that float("0.1") and Decimal("0.1") should be
equal or not, and why?
--
Greg
__
Glenn Linderman wrote:
Sounds to me like containment checking is wrong; that if it gets an
exception during the comparison that it should assume unequal, rather
than aborting, and continue to the next entry.
What exception would it catch, though? Catching something as
generic as TypeError wou
Glenn Linderman wrote:
In order to do
implicit comparisons, one must do an implicit coercion. Hence the PEP
actually already prohibits implicit comparisons, as well as implicit
arithmetic.
Not necessarily -- you could compare them as though they
had both been converted to the equivalent rati
Glenn Linderman wrote:
One can argue that either way, that it is completely different, or
completely the same.
An important difference is that there is no intermediate type
that can be compared with both ints and strings.
Another relevant difference is that numbers are just one of
many possib
Adam Olsen wrote:
For a little context, we have this numeric tower:
int -> Fraction -> float -> complex
Decimal is more precise, and pays a performance cost for it. It also
seems odd to stick it between float and complex (nobody's planning a
ComplexDecimal, right?) That suggests it should go
Mark Dickinson wrote:
Except that float is fixed-width (typically 53 bits of precision),
while Decimal allows a user-specified, arbitrarily large, precision;
Yes, but it still has *some* fixed limit at any given
moment, so the result of an operation on Decimals always
has the potential to prod
Nick Coghlan wrote:
Note that Antoine's point was that float("0.1") and
Decimal.from_float(0.1) should compare equal.
That would mean that Decimal("0.1") != float("0.1"), which might be
surprising to someone who didn't realise they were mixing floats
and decimals.
--
Greg
Michael Foord wrote:
Well, the documentation you pointed to specifies that __getattr__ will
be called if __getattribute__ raises an AttributeError, it just doesn't
specify that it is done by object.__getattribute__ (which it isn't).
If __getattribute__ raises an exception, it won't get a chan
Nick Coghlan wrote:
int -> Decimal -> Fraction -> float -> complex
I don't think it's a good idea to put Decimal below Fraction,
because Decimal has to be considered an implicitly inexact
type like float, and we don't want to coerce from an inexact
type to an exact one.
--
Greg
__
Nick Coghlan wrote:
That's fine - binary floats *are* surprising. That's why Decimal exists
in the first place.
This argument could equally well be used the other way --
someone using Decimal is doing so precisely because they
*don't* want to be surprised, in which case they would
probably pre
Raymond Hettinger wrote:
Remember, the notion of inexactness is a taint,
not an intrinsic property of a type. Even the Scheme numeric
tower recognizes this. LIkewise, the decimal specification also
spells-out this notion as basic to its design.
I'm not sure it really does, otherwise every de
Raymond Hettinger wrote:
Since decimal also allows arbitrary sizes, all long ints can be
exactly represented (this was even one of the design goals
for the decimal module).
There may be something we need to clarify here. I've been
imagining that the implicit conversions to Decimal that
we're t
Raymond Hettinger wrote:
The question of
where to stack decimals in the hierarchy was erroneously
being steered by the concept that both decimal and binary floats
are intrinsically inexact. But that would be incorrect, inexactness
is a taint, the numbers themselves are always exact.
I don't
Raymond Hettinger wrote:
The question of
where to stack decimals in the hierarchy was erroneously
being steered by the concept that both decimal and binary floats
are intrinsically inexact. But that would be incorrect, inexactness
is a taint, the numbers themselves are always exact.
I don't
Steven D'Aprano wrote:
Then they're in for a terrible, terrible disappointment. Rounding issues
don't go away because you're using Decimal instead of float,
No, but what I mean is that they prefer to be surprised in
unsurprising ways, so to speak.
Everyone knows that floating point numbers ha
Mark Dickinson wrote:
But the Fraction type is going to mess this up: for Decimal +
Fraction -> Decimal, I don't see any other sensible option than to
convert the Fraction using the current context, since lossless
conversion isn't generally possible.
You could convert the Decimal to a Fracti
Nick Coghlan wrote:
http://docs.python.org/library/decimal.html#decimal.Inexact
(Part of the thread context rather than the individual decimal values,
but if you use it properly it tells you whenever an inexact operation
has occurred in the current thread)
My problem was that the statement "A
Antoine Pitrou wrote:
In light of this issue, I'm -0.5 on __pycache__ becoming the default caching
mechanism. The directory ownership/permissions issue is too much of a mess,
especially for Web applications (think __pycache__ files created by the Apache
user).
Doesn't the existing .pyc mechani
Antoine Pitrou wrote:
Oh, and by the way, there can be a race condition between __pycache__
creation and deletion (if it fails the test)
You can check whether the directory would be created with
the right user beforehand, and if not, don't create one
at all.
To exploit a race condition there,
Pascal Chambon wrote:
I don't follow you there - in my mind, the default __getattribute__
could simply have wrapped all its operations inside soem kind of
"try..catch AttributeError:" mechanism, and thus been able to fallback
to __getattr__ in any way.
But then it would be incorrect to say t
Mark Dickinson wrote:
It might make sense for
Decimal + complex mixed-type operations to be disallowed, for example.
As long as you're allowing Decimal-float comparisons,
Decimal-complex comparison for equality has an obvious
interpretation.
--
Greg
Antoine Pitrou wrote:
Having the Web server execute ad hoc system
administration code is far from elegant and user-friendly.
With the right piece of code, you could create yourself
a setuid-apache shell and solve this problem once and for
all. :-)
--
Greg
__
Antoine Pitrou wrote:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's one point, but I'm not sure it's the *main* one.
Personally I
Antoine Pitrou wrote:
Well, if I can create a setuid apache shell, I can probably su as root or apache
as well.
("su -c rm -r whatever")
Or are you talking about a Web-based shell?
I'm just saying that if there is any way of running code of
your choice as the apache user, you can get it to ma
Steven D'Aprano wrote:
If the user has write permission and the __pycache__ folder is created,
but the umask is screwy and no .pyc files can be created, no .pyc file
is created and the import uses the .py file only despite the existence
of an empty __pycache__ folder.
Sounds okay to me.
--
Russell E. Owen wrote:
If .pyc files are to be shared, it seems essential to (by default)
generate them at install time and make them read-only for unprivileged
users.
This in turn implies that we may have to give up some support for
dragging python modules into site-packages
No, I don't t
Pascal Chambon wrote:
All I've found is "If the class also defines __getattr__(),
the latter will not be called unless __getattribute__()
either calls it explicitly or raises an AttributeError
Hmmm. Well, it still implies that there is some mechanism
outside of __getattribute__ that will catc
Isaac Morland wrote:
the
benefit to me and to Greg and to others writing .py code is that our
directories will contain *.py and __pycache__, rather than *.py and
*.pyc. So it will be much easier to see what is actually there.
Yes. When using MacOSX I do most of my work using the
Finder's colu
Raymond Hettinger wrote:
Conceptually, it's a bug. The numeric tower treats non-complex
numbers as special cases of complex where the imaginary
component is zero (that's why the non-complex types all support
real/imag), and since complex numbers are not allowed to compare
to themselves, they sh
Georg Brandl wrote:
Thinking of each value created by float('nan') as
a different nan makes sense to my naive mind, and it also explains
nicely the behavior present right now.
Not entirely:
x = float('NaN')
y = x
if x == y:
...
There it's hard to argue that the NaNs being compared
r
Steven D'Aprano wrote:
I'd like to turn the question around ... what algorithms are there that
rely on NaN == NaN being True?
That seems to be a straw question, since AFAIK nobody
has suggested that there are any such algorithms.
On the other hand, it has been claimed that some
algorithms exi
Curt Hagenlocher wrote:
Wait, what? I haven't been paying much attention, but this is backwards.
There are multiple representations of NaN in the IEEE encoding;
I think Nick's point is that there aren't enough bits
to give the result of every operation its own unique
NaN.
The payload of a NaN
Steven D'Aprano wrote:
By analogy: the Lizard King of Russia does not exist; the Vampire Queen
of New Orleans also does not exist. We don't therefore conclude that
the Lizard King and the Vampire Queen are therefore the same person.
But it's equally invalid to say that they're *not* the
same
Steven D'Aprano wrote:
What do we do with Decimal? Aren't we committed to matching the Decimal
standard,
It's been pointed out that the Decimal standard only defines
some abstract operations, and doesn't mandate that they
be mapped onto any particular language syntax. That gives
us enough flex
I impulsively wrote:
The payload of a NaN in typical hardware implementations
is quite small, because it has to fit into the exponent
field.
...which turns out to be precisely wrong. Some day I'll
learn to wait until somebody else in the thread has checked
the facts for me before posting. :-)
Steven D'Aprano wrote:
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception.
Yes, I don't think anyone would disagree that NaN should compare
unequal to anything that isn't a NaN. Problems only arise when
comparing two NaNs.
--
Greg
_
Carl M. Johnson wrote:
* It would make "method" in dir(obj) marginally faster
Wouldn't hasattr(obj, "method") be a better way
to do that?
* Even though the order isn’t important for code, it’s convenient at
the interactive prompt to see the methods of an item in alphabetical
order for quick
Antoine Pitrou wrote:
Steve Bonner gmail.com> writes:
What do we think of adding a built-in nonlocals() function that would
be similar to globals() and locals()?
These scopes don't have parallel capabilities:
Maybe it would be better to deprecate globals() and locals()
and replace them wit
will...@ufpa.br wrote:
for a college project, I proposed to create a compiler for python. I've
read something about it and maybe I saw that made a bad choice. I hear
everyone's opinion respond.
I don't want to discourage you if you really want to try,
but you need to be aware that you'd be taki
Craig Citro wrote:
In the
event of an exception, the Python call frames are constructed as the C
call stack is unwound.
Although in Pyrex the frames have just enough info in them to
find out the file name and line number -- the rest (f_stack,
f_locals, etc.) are filled with dummy values.
--
Gr
Reid Kleckner wrote:
If I remember correctly, the exec statement is going away in py3k, and
calling exec() with one argument can modify the local scope.
I've been kind of wondering what the deal is with exec in py3.
I always thought the reason for making exec a statement was so
that locals opt
Maciej Fijalkowski wrote:
Except none of the things mentioned above is actually a "Python
compiler".
No, but they grapple with many of the same issues that a Python
compiler would face, and it would be informative to see how
they tackle those issues. If you want to advance the state of
the art
Cesare Di Mauro wrote:
It will certainly. There's MUCH that can be optimized to let CPython
squeeze more performance from static analysis (even a gross one) on locals.
But can the existing locals() function be implemented in
the face of such optimisations?
If it can, then a "locals view" obje
Michael Foord wrote:
*However*, a project that would be interesting - and that I have wanted
to do in order to program microcontrollers with *very* small memory
address spaces [1] - would be to compile a static subset of Python down
to C.
That would be an excellent project -- if the result w
Nick Coghlan wrote:
I thought RPython already supported this? (admittedly, my knowledge of
of the inner workings of PyPy is fairly sketchy, but I thought static
compilation of RPython to a variety of backend targets was one of the
key building blocks)
Maybe so, but one would still have to crea
I thought type-class unification was supposed to mean
that all objects now have a __class__ attribute. But
traceback objects don't seem to:
import sys
try:
raise ValueError
except ValueError:
tb = sys.exc_info()[2]
print tb
print tb.__class__
results in:
% python2.6 traceback_class.py
Nick Coghlan wrote:
I'm not sure what build you're getting that behaviour on, but my svn
build of 2.6 has a __class__ attribute for traceback objects,
It's 2.6.1. Guess it's been fixed since then.
--
Greg
___
Python-Dev mailing list
Python-Dev@python
Jesus Cea wrote:
About controversial... keepalive are usually sent only when the
connection is 100% idle for a while, when "while" can be >15 minutes, so
the load should be "none" for regular connections.
I guess the concern would be that the keepalive probe itself
is subject to uncertain dela
Michael Foord wrote:
Building Python requires, I
believe, the XCode development tools to be installed. Even then,
building a full version of Python - with *all* the C extensions that are
part of a Python release - is not a trivial task.
What's non-trivial about it? I usually find that the nor
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string keys,
remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you make of a situation
where Python says "T
John Arbash Meinel wrote:
Because you wouldn't want to have
A.echo()
Say that it takes 1 argument and (-1 given) ?
Something like "1 argument in addition to 'self'" would be
reasonably clear and would cover both situations.
+1 on fixing this from me, too. Even when you understand
exactly wh
Ben Finney wrote:
Something like "1 argument in addition to 'self'" would be reasonably
clear and would cover both situations.
Except that there's nothing special to the syntax or parser about the
name ‘self’.
That's true, but the use of the word 'self' here isn't meant
to refer to the name
Floris Bruynooghe wrote:
Not having looked at the code I don't know how hard it is for the code
that raises this traceback to notice if it's a bound or unbound method
tough.
The way things currently work, it would be quite difficult.
The exception is raised when attempting to call the function
Giampaolo Rodolà wrote:
"unbound method echo() must be called with A instance as first
argument (got nothing instead)"
It talks about "arguments" while no arguments are actually involved in
the problem: just a class I forgot to initialize.
It's hard to see how this could be improved. If you h
Glyph Lefkowitz wrote:
Finally, why isn't this just a module on PyPI? It doesn't seem like
there's any particular benefit to making this a stdlib module and going
through the whole PEP process
I'm inclined to agree. This needs to be field-tested before
being considered for stdlib inclusion.
Brian Quinlan wrote:
The good news in this case is that the same API has been used
successfully in Java and C++ for years so it is unlikely that any major
changes will need to be made.
That doesn't follow. An API that's appropriate for Java or
C++ is not necessarily appropriate for Python. Sl
Brian Quinlan wrote:
Simple modules are unlikely to develop a following because it is too
easy to partially replicate their functionality.
I don't think it needs a particularly large following.
What it does need is at least a few people using it in
some real projects.
No matter how much disc
Andrew Svetlov wrote:
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
I think this is an English vs. American thing. Double 'l'
looks right to me, but then I was brought up as a loyal
subject of the antipodean branch of the British Empire. :-)
--
Greg
Having read through the PEP again, here are my thoughts.
* I'm bothered by the term "future". To my mind, it's
too long on cleverness and too short on explanativeness.
I think that the standard library is no place for
cuteness of naming. The name of a stdlib module should
reflect its functionali
Brian Quinlan wrote:
I think that Jesse was planning to add some functionality to this
namespace.
Even if that happens, the existing threading and multiprocessing
modules would remain outside of it.
You could have general thread pools that aren't related to executors
Yes, but it should be
Mark Dickinson wrote:
code = """\
... y = 3
... def f():
... return y
... f()
... """
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the fi
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2. wait until the future finishes and then exit
I'd go for (1). I don't think it's unreasonable to
expect a program that wants all its tasks to finish
to explic
On 27/05/10 01:48, Nick Coghlan wrote:
I would say it is precisely that extra configurability which separates
the executor pools in the PEP implementation from more flexible general
purpose pools.
Wouldn't this be better addressed by adding the relevant
options to the futures pools, rather tha
On 27/05/10 11:33, Michael Foord wrote:
On 27/05/2010 00:38, Greg Ewing wrote:
Maybe the second scope argument to exec() should
be deprecated?
Sounds good to me, certainly ends the confusion over this undoubtedly
unintuitive behaviour. :-)
Although it's a fair point that it can be u
On 27/05/10 12:04, Jesse Noller wrote:
Namespaces are
only a honking great idea if you actually let them do the job
they're designed for.
concurrent.* is the namespace, futures is the package within the
namespace - concurrent.futures is highly descriptive of the items
contained therein.
I wa
On 27/05/10 12:37, Colin H wrote:
This is a major use
case for exec() - defining code from strings (e.g. enabling you to
store python code in the database), and using it at runtime. It seems
to me this must have been the point of locals in the first place.
I suspect that originally it just fel
On 27/05/10 12:38, Guido van Rossum wrote:
the compiler normally uses syntactic clues to decide
whether to generate code using closures, in particular, the presence
of nested functions.
Well, the compiler could be passed a flag indicating that
the code is being compiled for an exec statement.
Another approach to all this might be to generalise the
mechanism by which a lookup of the globals falls back
to a lookup of __builtins__.
If this were done recursively, then the "stuff" could
be attached to the globals dict, e.g.
stuff['__builtins__'] = __builtins__
g = dict(__builtins__ =
Brian Quinlan wrote:
I think that the "Executor" suffix is a good indicator of the interface
being provided.
It's not usually considered necessary for the name of a
type to indicate its interface. We don't have 'listsequence'
and 'dictmapping' for example.
I think what bothers me most about
Nick Coghlan wrote:
We can accept PEP 3148 by saying that we're happy to add the extra
namespace level purely for disambiguation purposes,
If that's the only rationale for the namespace, it makes it
sound like a kludge to work around a poor choice of name.
--
Greg
sm...@gmx.net wrote:
Now, the problem is, Python appears to read-access the deallocated memory
still after tp_dealloc.
It's not clear exactly what you mean by "after tp_dealloc".
The usual pattern is for a type's tp_dealloc method to call
the base type's tp_dealloc, which can make further refer
Guido van Rossum wrote:
bind the instance to the first argument when it
is called on an instance. I can't think of a good name for that one
right now, but we'll think of one.
dynamicmethod?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
Benjamin Peterson wrote:
IIRC this was because UserDict tries to be a MutableMapping but abcs
require new style classes.
Are there any use cases for UserList and UserDict in new
code, now that list and dict can be subclassed?
If not, I don't think it would be a big problem if they
were left o
Ronald Oussoren wrote:
That's because setgroups(3) is limited to 16 groups
> (that is, the kernel doesn't support more than 16 groups at all).
So how does an account being a member of 18 groups ever work?
--
Greg
___
Python-Dev mailing list
Python-D
Scott Dial wrote:
But the only motivation for doing this with .pyc files is that the .py
files are able to be shared,
In an application made up of a mixture of pure Python and
extension modules, the .py files are able to be shared too.
Seems to me that a similar motivation exists here as well.
Terry Reedy wrote:
On 6/24/2010 1:38 PM, Bill Janssen wrote:
We have separate types for int,
float, Decimal, etc. But they're all numbers, and they all
cross-operate.
No they do not. Decimal only mixes properly with ints, but not with
anything else
I think there are also some important di
Tres Seaver wrote:
I do know for a fact that using a UCS2-compiled Python instead of the
system's UCS4-compiled Python leads to measurable, noticable drop in
memory consumption of long-running webserver processes using Unicode
Would there be any sanity in having an option to compile
Python wit
Stefan Behnel wrote:
Greg Ewing, 26.06.2010 09:58:
Would there be any sanity in having an option to compile
Python with UTF-8 as the internal string representation?
It would break Py_UNICODE, because the internal size of a unicode
character would no longer be fixed.
It's not fixed a
Eric Smith wrote:
But isn't this currently ignored everywhere in python's code?
It's true that code using a utf-8 build would have to be
aware of the fact much more often. But I'm thinking of
applications that would otherwise want to keep all their
strings encoded to save memory. If they do th
R. David Murray wrote:
Having such a poly_str type would probably make my life easier.
A thought on this poly_str type: perhaps it could be
called "ascii", since that's what it would have to be
restricted to, and have
a'xxx'
as a literal syntax for it, seeing as literals seem to
be one of
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + "1"
into
raise TypeError()
at compile time?
It would have to be
raise TypeError("Exactly the message that would have been produced at run
time")
That might be acceptable, but then you have to ask, is it really
Craig Citro wrote:
Ok, I'm obviously being silly here, but sure you can:
dis.dis("raise TypeError()")
If producing different bytecode were considered a reason
against performing an optimisation, then no code optimisations
would be permissible at all!
--
Greg
Steven D'Aprano wrote:
if the keyhole optimizer raised SyntaxError (or
some other exception) on seeing this:
def f():
return 1 + "1"
That might break code that was deliberately trying to raise
an exception. Sometimes you see things like
try:
1/0
except Exception, e:
...
Usua
Craig Citro wrote:
However, in this particular case, here's a question: *why* would
someone write "return 1 + '1'"?
They might not intend to execute the code at all -- e.g.
they may want to pass the compiled code to dis() to find
out what bytecode gets generated. Having it refuse to
compile wo
M.-A. Lemburg wrote:
Note that using UTF-8 as internal storage format would not work
in Python, since Python is a Unicode producer, i.e. it needs to
be able to generate and work with code points that are not allowed
in UTF-8, e.g. lone surrogates.
Well, it wouldn't strictly be UTF-8, any more
Titus von der Malsburg wrote:
None of the examples I found used the pythonic
exception style, that's why I assumed that checking the "return value"
is the only possibility. Reading the PEP carefully would have helped.
:-)
I had to read the pep fairly carefully before I noticed
this too, so per
Fred Drake wrote:
Not when both modules are at the top level; both acceptably provide
the same name. The let's-play-with-it script just wasn't *intended*
to be a module.
I wonder whether this kind of problem would be less prevalent
if the tutorials etc. encouraged naming top-level scripts wit
Giampaolo Rodolà wrote:
One of the main problems with IDLE is the lack of tabs for editing
multiple files within the same window.
While tabs seem to work well for web browsing, I'm not so
sure about using them for source editing. Often I want to
display two or more files side by side, which can
Nick Coghlan wrote:
I use tabbed editors all the time (Kate, Notepad++) and find them to
be excellent. Tastes will obviously vary though, since there are even
people out there that use vim and emacs voluntarily ;)
It's probably all right if you have the ability to move
tabs from one window to
Tim Golden wrote:
That said, it's not clear just how far the stdlib should go to
mimic every switch and option of shell commands...
I don't think it's a matter of mimicking switches just because
they're there.
The operation of "make sure this directory and all its parents
exist" is very commo
Ray Allen wrote:
I think both os.mkdir() and
os.makedirs() should add a keyword argument to suppress the "OSError:
[Errno 17] File exists".
This could be seen as violating the "no constant arguments"
guideline. Maybe separate function would be better?
--
Greg
Scott McCarty wrote:
All, I have searched everywhere (mostly the code and a little google)
and I cannot understand where the SIGKILL signal gets checked when it is
set as a handler.
Possibly it's not being checked at all by Python, but
is being rejected by the system call. The Darwin man
page
岳帅杰 wrote:
Sorry, I don't know what is the "no constant arguments" guideline refers
to. Could you give me some more explanation?
It's a rule of thumb that Guido says he uses when
designing an API. If in the majority of use cases for
a proposed function, one of its arguments would always
be a co
Steven D'Aprano wrote:
Perhaps all we need is a recipe in the docs:
try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise
I don't like writing code that depends on particular
errno values, because I don't trust it to work cross-
platform.
Also it seems suboptimal t
Ray Allen wrote:
I think in this case, the errno is generate by c standard library, which
can be seen as cross-platform.
But I'm never sure how standard the actual error
numbers are, though. I tend to think of them as
coming from Unix-land, and thus fair game for
getting screwed around with on
On 21/07/10 23:43, "Martin v. Löwis" wrote:
IIUC, he wanted to know how Python
handles SIGKILL, when the hole point of SIGKILL is that you cannot
handle it.
No, I think he wanted to know how Python disallows
attempting to set a handler for SIGKILL, when he
couldn't find any code that special-ca
Glyph Lefkowitz wrote:
The selection of RuntimeError in this particular case seems somewhat random and
ad-hoc,
Indeed -- usually a RuntimeError indicates that something
concerning the internals of Python itself is screwed up,
e.g. attempting to execute invalid bytecode.
The fact that it turn
On 23/07/10 04:24, gregory.smi...@sympatico.ca wrote:
I've suggested :name, which doesn't break old code,
I'm not so sure about that. Consider
foo[a::b]
Do you parse that as a 3-element slice, or as a
2-element slice with :b as the second element?
--
Greg
901 - 1000 of 2443 matches
Mail list logo
