[EMAIL PROTECTED] wrote:
> Facundo> c) Write the function in socket.py, non public
Also this option has the problem that it would be
a strange usage of "non-public", since the function
would be designed for use by other modules and not
used at all in the module it's supposedly private
to.
Neil Hodgson wrote:
>I think one of the motivations for discontiguous segments was for
> split buffers which are commonly used in text editors.
Note that this is different from the case of an array
of pointers to arrays, which is a multi-dimensional
array structure, whereas a split buffer is
Travis Oliphant wrote:
> The question is should we eliminate the possibility of sharing memory
> for objects that store data basically as "arrays" of arrays (i.e. true
> C-style arrays).
Can you clarify what you mean by this? Are you talking
about an array of pointers to other arrays? (This is
doesn't know about
the rules, or follows a different set of rules, everything
falls apart.
Every time I've considered using super, I've eventually
decided against it for reasons like this. I've always
found a better way that doesn't introduce so may
strange interactions
ppend")
result = PyObject_CallFunctionObjArgs(meth, self, x, NULL)
plus appropriate error checking.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning
e to pass arbitrary args to object.__init__
and don't ever intend to, so this wouldn't bother
me.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
cient (as long as the loop is not in Python).
>
> It sure provides a nice abstraction that lets you deal with
> discontiguous arrays as if they were contiguous, though.
Something like that might be useful.
--
Greg Ewing, Computer Science Dept, +
Blake Ross wrote:
> C++ ensures that virtual bases
> are only constructed once,
As far as I remember, C++ ensures this by not calling
the base constructors automatically at all, leaving
you to explicitly call the constructors of all the
virtual bases that you inherit.
You could adopt the same sol
s instead of mixing metaclasses.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[E
Guido van Rossum wrote:
> It's unlikely to be granted. ... The Python call just wraps the
> system call which has a similar API.
What about letting it accept both?
Maintaining strict consistency with the C API here
at the cost of causing pain on almost all uses of
the function seems to be a cas
Titus Brown wrote:
> * second, I'd like to add a 'require_success' bool keyword, that is
>by default False (and does nothing in that case). However, when
>True, the functions would emulate check_call, i.e. they would raise
>CalledProcessError when the returncode was not zero.
By the
Guido van Rossum wrote:
> I wonder if we should even get rid of os.system(); then there should
> be a subprocess.system() instead.
That sounds okay, since system() isn't actually a system call,
despite its name.
> And do we even need os.fork(), os.exec*(), os.spawn*()?
Since fork() and exec()
Titus Brown wrote:
> I could add in a 'system'-alike call easily enough; that was suggested.
> But I think
>
> returncode = subprocess.call("program")
>
> is pretty simple, isn't it?
Something to keep in mind is that system() doesn't
directly launch a process running the command, it
uses
Pete Shinners wrote:
> Will your image objects be transferrable to PIL, Pygame, PyOpengl, Numpy,
> Pythonmagick, Pycairo, wxPython, etc? It would be best if this could avoid the
> "fromstring/tostring" mojo that always requires and extra copy of the data for
> each transfer.
This would be an exce
Carl Banks wrote:
> It's easy to see possible use cases for returning a different object. A
> hypothetical future incarnation of NumPy might shift the
> responsibility of managing buffers from NumPy array object to a hidden
> raw buffer object. In this scenario, the NumPy object is the expo
Travis Oliphant wrote:
> > Here is my updated PEP which incorporates several parts of the
> > discussions we have been having.
It looks pretty good.
However, I'm still having trouble seeing what use it is returning
a different object from getbuffer. There seems to be no rationale
set out for th
Here's another idea, to allow multiple views of the same
buffer with different shape/stride info to coexist, but
without extra provider objects or refcount weirdness.
Also it avoids using calls with a brazillion arguments.
struct bufferinfo {
void **buf;
Py_ssize_t *len;
int *wri
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>> struct bufferinfo {
>> ...
>> };
>>
>> int (*getbuffer)(PyObject *obj, struct bufferinfo *info);
>> int (*releasebuffer)(PyObject *obj, struct bufferinfo *info);
> This is not much differen
Travis Oliphant wrote:
> Perhaps, though we can stick with an
> object-less buffer interface but have this "view object" as an expanded
> buffer object.
I like this idea.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Carl Banks wrote:
> /* don't define releasebuffer or lockbuffer */
> /* only objects that manage buffers themselves would define these */
That's an advantage, but it's a pretty small one -- the
releasebuffer implementation would be very simple in
this case.
I'm bothered that the releaser field m
Carl Banks wrote:
> Now object B takes a view of A. If we don't have this field, then B
> will have to hold a reference to A, like this:
>
> B -> A -> R
>
> A would be responsible for keeping track of views,
A isn't keeping track of views, it's keeping track of the
single object R, which it h
Has anyone found a way of persuading distutils to
pass MacOSX -framework options properly when linking?
Using extra_link_args doesn't work, because they need
to be at the beginning of the command line to work
properly, but extra_link_args gets put at the end.
And extra_compile_args is only used wh
Ronald Oussoren wrote:
> What's wrong with adding -framework flags to the end? I do this all the
> time and have yet to run into problems.
I don't know what's wrong. Sometimes it works for me too,
but often it doesn't, and when it doesn't, putting them
at the front seems to fix it.
Apple's man
Guido van Rossum wrote:
> I think it's worthwhile.
(followed by a whole page of quoted text)
Folks, could you please try to remember to quote
minimally from messages that you are replying to?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
htt
Ronald Oussoren wrote:
> Could you create an example where adding -framework to the end of the
> command-line doesn't work?
I'll see what I can do.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
Steven Bethard wrote:
> Guido commented in the tracker that it would be worth discussing
> whether that last item (``item_counts['d']``) should return 0 (as a
> defaultdict would) or raise KeyError (as a dict would).
If you've asked for a count of 'd's, and there aren't
any 'd's, the most sensible
Adam Olsen wrote:
> The name doesn't make it obvious to me what's going on. Maybe
> countunique()?
That doesn't sound any more obvious to me.
counteach? countall?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
Raymond Hettinger wrote:
> Instead of a separate function in collections, it may be sensible to stick
> with
> the familiar and provide a dictionary contructor for the commonly encounter
> use
> case of counting things:
I don't think that's a good idea. The dict class
should restrict itself to b
Travis Oliphant wrote:
> Carl Banks wrote:
> > I'd like to see it accept a flags argument over what kind of buffer
> > it's allowed to return. I'd rather not burden the user to check all
> > the entries in bufferinfo to make sure it doesn't get something
> > unexpected.
> Yes, I agree. We had s
Steven Bethard wrote:
> * Greg Ewing - counteach(), countall()
> * Guido - counts() is fine
I'm happy with counts() too -- I only suggested the
others in case counts() wasn't acceptable for some
reason. If Guido likes it, that's good en
l the things
that were requested in the flags, so it's going to
have to keep its own track of what has been allocated.
> 11) Perhaps the 'PyObject_' prefix is wrong, as those functions does
> not operate with Python objects.
Yes, PyBuffer_ would be
bject is rather
unclear, e.g. "It exports a view using the base object."
I don't know what that is supposed to mean.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurc
Travis Oliphant wrote:
> Because slicing NumPy array's already does it by holding on to a view, I
> guess having an object that doesn't hold on to a view in Python but
> "re-gets" it every time it is needed, would be useful.
I guess this problem doesn't arise in NumPy, because the size
of the m
Travis Oliphant wrote:
> It is more convenient to store any slicing information (so a memory view
> object could store an arbitrary slice of another object) as offsets,
> lengths, and skips which can be used to adjust the memory buffer
> returned by base.
What happens if the base object change
Travis Oliphant wrote:
> Py_BUF_SIMPLE --- you are requesting the simplest possible (0x00)
>
> Py_BUF_WRITEABLE -- get a writeable buffer (0x01)
>
> Py_BUF_READONLY -- get a read-only buffer(0x02)
I don't see how these three form a progression.
From the other things you say, it appe
Carl Banks wrote:
> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
Is there a use case for this?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
Travis Oliphant wrote:
> you would like to make the original memory
> read-only until you are done with the algorithm and have copied the data
> back into memory.
Okay, I see what you mean now.
Maybe this should be called Py_BUF_LOCK_CONTENTS or
something to make the semantics clearer. Otherwis
[EMAIL PROTECTED] wrote:
> Just a little FYI, python-mode (the one Barry and I manage - dunno about the
> one distributed w/ GNU Emacs these days) is one of those tools that leaves
> trailing whitespace behind when advancing to the next line..
I get extremely annoyed with editors that *don't* leav
Gustavo Carneiro wrote:
> Erm. Excuse me, but are you saying this code is wrong?
>
> class Rectangle:
> def __init__(self, width, height):
> self.width = width
> self.height = height
>
> class Square:
> def __init__(self, side):
> Rectangle.__init__(self, side,
[EMAIL PROTECTED] wrote:
> Since the language doesn't require that a subclassed method take the same
> parameters as the base class method, you can't assume that it does.
The argument is that in the special case of a cooperative
super call, it doesn't make sense for the parameter list
to be differ
Guido van Rossum wrote:
> Nearly always wrong? You must be kidding. There are tons of reasons to
> call your super method with modified arguments. E.g. clipping,
> transforming, ...
That's a good point. Just because the *signature* is the
same doesn't mean the *values* of the parameters need
to b
JOSHUA ABRAHAM wrote:
> I was hoping you guys would consider creating function in os.path or
> otherwise that would find the full path of a file when given only it's base
> name and nothing else.I have been made to understand that this is not
> currently possible.
Does os.path.abspath() do wha
[EMAIL PROTECTED] wrote:
> when I hit LF in an open
> multiline string a newline is inserted and the cursor is lined up under the
> "r" of "rows", not under the opening quote of the multiline string, and not
> where you chose to indent your example.
Seems to me that Python actually benefits from a
Steven Bethard wrote:
> Does that mean you want list literals to be immutable too?
There are no "list literals" in Python, only expressions
that construct lists.
You might argue that b"abc" is not a literal either, but
an expression that constructs a bytes object. However, it
*looks* so much lik
Martin v. Löwis wrote:
> why should you be able to get a non-ASCII character
> into a raw Unicode string?
The analogous question would be why can't you get a
non-Unicode character into a raw Unicode string. That
wouldn't make sense, since Unicode strings can't even
hold non-Unicode characters (or
Terry Reedy wrote:
> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
> | While I question the sanity of the spec writers in this case, I do trust
> that
> | overall, they have provided an extremely well thought-out spec, have gone
> | through extensive discussion/feedback cycles, and h
M.-A. Lemburg wrote:
> * non-ASCII code points in text are not uncommon, they occur
> in most European scripts, all Asian scripts,
In an Asian script, almost every character is likely to
be non-ascii, which is going to be pretty hard to read
as a string of unicode escapes.
Maybe what we want is
Martin v. Löwis wrote:
> This question I could not answer, because I don't know what an orb is
An orb is a sphere.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
e other site that the spammer is trying to get
> access to.
The "python-related question" technique would probably be
somewhat resistant to this, as your average porn surfer
probably doesn't know anything about Python. (At least
until CP4E takes off and everyone knows
O.R.Senthil Kumaran wrote:
> Site: What is the futorh word of tihs scnnteee?
>
> Answer: fourth.
Are you sure it isn't "futorh"?-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
Martin v. Löwis wrote:
The hole C API would break if objects would move in memory.
Since they have to stay at fixed addresses, it's easy enough to use the
address as ID.
Yes. Some of the discussion here seems to be assuming that the
reason Python doesn't move objects is so that it can use the
a
Senthil Kumaran wrote:
Given these, any assumption that servers no longer support HTTP/0.9
becomes false.
But as long as httplib only sends requests with a version
number >= 1.0, it should be able to expect headers in the
response, shouldn't it?
--
Greg
___
Victor Stinner wrote:
Limit the number of suffixes is maybe not the right solution to limit
the number of system calls at startup. We can imagine alternatives:
* remember the last filename when loading a module and retry this
filename first
* specify that a module is a Python system module an
Nick Coghlan wrote:
Flawed API + popularity = years of fun*
So maybe it's time to design a new module with a better API
and deprecate the old one?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
Antoine Pitrou wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
So maybe it's time to design a new module with a better API
and deprecate the old one?
That's called Twisted.
I was thinking of something lighter-weight than that
exar...@twistedmatrix.com wrote:
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
I was thinking of something lighter-weight than that.
Twisted Core
I just had a look at the docs for Twisted Core, and it lists
10 sub-modules. The only
Giampaolo Rodolà wrote:
for me it should also fit one crucial requirement: it
should be *simple* and reflect the simplicity and "taste" of all other
stdlib modules, and to fulfill such a requirement I think Twisted
probably needs to be "adapted" a bit.
My thoughts exactly -- from a bird's eye
From: Guido van Rossum
> (OTOH I am not much enamored with cofunctions, PEP 3152.)
That's okay, I don't like it much myself in its current form.
I plan to revisit it at some point, but there's no hurry.
--
Greg
This email may be confidential and subject to legal privilege, it may
not reflect
From: Antoine Pitrou
> - a "branch" usually means a "named branch": a set of changesets
> bearing the same label (e.g. "default"); that label is freely chosen
> by the committer at any point, and enforces no topological
> characteristic
There are *some* topological restrictions, because hg w
From: Grigory Javadyan
> ... def f():
> ... a = 42
> ... def g():
> ... nonlocal a
> ... del a
> ...
> SyntaxError: can not delete variable 'a' referenced in nested scope
Is there a rational for this? It seems inconsistent -- if you can
assign to names in outer scop
Guido van Rossum wrote:
Ok. Will you hvae time to port your patches to 3.3?
I'm not sure -- I'll see what I can do.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
I'm wondering whether one major release is enough of a
deprecation period in the current situation. Many people
haven't started using 3.x in earnest yet, and by the
time they do, several major releases will have already
gone by.
--
Greg
___
Python-Dev
Mark Hammond wrote:
Yup - although I think a pythonw.exe launcher would be needed too
Couldn't the launcher look at the extension of the file being
launched to decide about this?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
Michael Foord wrote:
- I doubt calling it python.exe will fly, but I'm not sure. If so
what will you call what is currently 'python.exe'? - if not then "python
foo.py" on the command line will *still* not work...
However, if it's installed as the exe associated with the .py
and .pyw exten
Thomas Wouters wrote:
2. Make CFunctions turn into methods in CPython (after a period of
warning about the impending change, obviously.) The actual *usecase* for
this is hard to envision
While not necessary for the case being discussed here, this would
be a big help for Pyrex and Cython, whe
Guido van Rossum wrote:
IIUC Thomas found that this breaks some current use of staticmethod.
I*I*UC, it wasn't making it callable that was the problem,
it was changing the behaviour so that the staticmethod
wrapper returns itself instead of the underlying object
when accessed as a descriptor.
Nick Coghlan wrote:
I'm actually tempted to call the current CPython semantics flatout
*wrong*.
So am I. It seems to result from the hisorical mess
of distinguishing between numeric and sequence operations
at the C level but not the Python level. I think CPython
should be moving in the directi
Tim Lesher wrote:
Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:
IMO these should be called __asdict__, __replace__ and
__make__. Users are perfectly entitled to make up their
own sing
Nick Coghlan wrote:
True, but all those underscores are a PITA to type and read for
methods that are meant to be called directly.
Matter of taste, I suppose. I don't find them all that
bothersome, and a double underscore name stands out very
clearly as being part of the infrastructure rather t
Antoine Pitrou wrote:
But doesn't it also mean many setup.py scripts will have very tedious
import sequences, such as:
try:
from packaging.compiler import FooCompiler
from packaging.commands import BarCommand
except ImportError:
try:
from distutils2.compiler import FooCompil
Martin v. Löwis wrote:
"There must be at least a one-year transition period between the
release of the transitional version of Python and the release
of the backwards incompatible version.
I still think this is going to result in rude shocks to
people switching from 2 to 3 and jumping several
Tarek Ziadé wrote:
try:
from __future__ import or_importer
except ImportError:
XXX <-- previous proposal
else:
or based proposal
This could easily be fixed if we allowed run-time access
to the time machine:
from __future__ import temporal_mechanics, or_importer
import timemac
Nick Coghlan wrote:
The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually,
This is an instance of a pattern that I've encountered a
few times in things that I've done: you have a class
attribute containi
Tim Lesher wrote:
Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation. What *is* the worst case
for MRO complexity?
I don't think that's an issue -- the MRO gets flattened into
a list at class creation time, so code that walks it nev
Larry Hastings wrote:
The PyCapsule API is very much like the CObject API. In fact, in Python
3.1 CObject was actually implemented on top of PyCapsule. It should be
very easy to support both APIs.
Perhaps the code for the 3.1 implementation could be pulled
out and made available to people i
Tres Seaver wrote:
I'm not even sure why you would want __version__ in 99% of modules: in
the ordinary cases, a module's version should be either the Python
version (for a module shipped in the stdlib), or the release of the
distribution which shipped it.
It's useful to be able to find out th
Mark Hammond wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be?
I think it should be the actual Python executing at that
moment, not the launcher. This is the least change from
current behaviour and therefore least likely
Mark Hammond wrote:
In addition to Martin's point, this approach would mean the exit code of
the child process probably isn't available to whoever started the
launcher.
Maybe I've missed something in this discussion, but is there
any reason the launcher can't just exec the relevant python?
Th
Martin v. Löwis wrote:
Windows doesn't support exec.
Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
I'd say that sys.executable should point to whatever version of
python.exe corresponds to that dll.
Generally, things should be made to look as much as possible as
if that
Guido van Rossum wrote:
Cython feels much less
mature than CPython; but the latter should only have dependencies that
themselves change even slower than CPython.
You might be slightly more amenable to Pyrex, then, which
changes at a much more conservative pace!
They appear superficially simila
Ben Finney wrote:
That seems to me the ideal: preserve all revision history for those
cases when some user will care about it, but *present* history cleanly
by default.
Seems to me the basic problem here is the way Mercurial
presents you with a big pile of changesets and not much
way of imposi
Eugene Toder wrote:
Mercurial has named branches. When viewing history you can restrict it
to just one named branch, which, I think, will have an effect similar
to "mainline".
So with Hg, could you get the same effect by pushing your
local changes into a temporary named branch, and then
mergin
Steven D'Aprano wrote:
The main one that comes to my mind is that other than looping, any time
I want to process dict.items() etc I often need to call list() first.
I don't think that's such a bad thing. It makes it clear that
you're performing a more expensive operation than just looking
at t
Jameson Quinn wrote:
"class attrdict" is a perennial dead-end for intermediate pythonistas
who want to save 3 characters/5 keystrokes for item access. Other
languages such as javascript allow "somedict.foo" to mean the same as
"somedict['foo']", so why not python?
I think the main reason this
Jameson Quinn wrote:
def fun2(**kw):
print kw["argument"]
Since this function effectively has a compulsory argument
called 'argument', it would be better written
def fun2(argument, **kw):
print argument
or, if the recently-added keyword-only feature is available,
def fun2(*, arg
Santoso Wijaya wrote:
`somedict:foo` looks better than `somedict..foo`.
Parsing ambiguity:
if foo:bar:baz
Is that
if (foo:bar): baz
or
if foo: (bar:baz)
?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
Senthil Kumaran wrote:
http://bugs.python.org/issue11236
getpass.getpass does not respond to ctrl-c or ctrl-z
Could this have been deliberate so that people can
put control characters in their passwords?
--
Greg
___
Python-Dev mailing list
Python-De
Martin v. Löwis wrote:
Not if they use the stable ABI. There still might be issues if you
mix CRTs, but none related to the Python ABI - in particular, none
of those crashing conditions can arise from the stable ABI.
Won't there still be a problem of your extension module
being linked with a CR
Nick Coghlan wrote:
1. Making "docstring" an attribute of the Function node rather than
leaving it embedded as the first statement in the suite (this avoids
issues where AST-based constant folding could potentially corrupt the
docstring)
2. Collapsing Num, Str, Bytes, Ellipsis into a single Lite
Ricardo Kirkner wrote:
My question is,
shouldn't/wouldn't it be better,
if python took ownership of that part, and ensured all classes get
called, even if some class misbehaved?
I don't think so. If a class isn't designed to be part of
a super chain, there are likely to be other issues that
can
P.J. Eby wrote:
It's perfectly sensible and useful for there to be classes that
intentionally fail to call super(), and yet have a subclass that wants
to use super().
One such case is where someone is using super() in a
single-inheritance environment as a way of not having to
write the base c
Michael Foord wrote:
What I was suggesting is that a method not calling
super shouldn't stop a *sibling* method being called, but could still
prevent the *parent* method being called.
There isn't necessarily a clear distinction between parents
and siblings.
class A:
...
class B(A):
...
Raymond Hettinger wrote:
If an external non-cooperative class needs to be used, then
it should be wrapped in a class that makes an explicit
__init__ call to the external class and then calls super().__init__()
to continue the forwarding.
I don't think it's as simple as that. Isn't that super()
R. David Murray wrote:
Why not? It seems more useful than using it for chaining,
especially given the compiler hack in Python3.
Because it's prone to doing the wrong thing if the class
using it is ever involved in multiple inheritance. If
you're expecting the call to go to a particular class,
Michael Foord wrote:
consider the "recently" introduced problem caused by object.__init__
> not taking arguments. This makes it impossible to use super correctly
> in various circumstances.
>
> ...
>
It is impossible to inherit from both C and A and have all parent
__init__ methods called corr
Mark Shannon wrote:
class A: pass
class B(A): pass
class C(A,B):pass
Traceback (most recent call last):
File "", line 1, in
TypeError: Cannot create a consistent method resolution
order (MRO) for bases B, A
All right, but this is okay:
class C(B, A): pass
> Michael Foord wrote:
>
For a
Michael Foord wrote:
But you have to be aware that
because of the semantics of super, not calling up to your parents
basically prevents those methods being used in the presence of multiple
inheritance.
No, it prevents them being used in the presence of super().
Multiple inheritance is still p
Mark Janssen wrote:
I have to say it is quite strange to
me that there is no distinction made between IS-A relationship and
HAS-A relationships with regard to the issue of Inheritence.
I'm not sure what you mean by that. Inheritance is (or
should be) used only for is-a relationships. Misusing i
Guido van Rossum wrote:
Maybe we should just call off the odd NaN comparison behavior?
That's probably as good an idea as anything.
The weirdness of NaNs is supposed to ensure that they
propagate through a computation as a kind of exception
signal. But to make that work properly, comparing tw
Steven D'Aprano wrote:
You can compare NANs, and the result of the
comparisons are perfectly well defined by either True or False.
But it's *arbitrarily* defined, and it's far from clear that
the definition chosen is useful in any way.
If you perform a computation and get a NaN as the result,
1301 - 1400 of 2443 matches
Mail list logo
