Stephen J. Turnbull wrote:
So what does the 1/0 that
occurs in [1/x for x in range(-5, 6)] mean? In what sense is it
"equal to itself"? How can something which is not a number be
compared for numerical equality?
I would say it *can't* be compared for *numerical* equality.
It might make sense
Guido van Rossum wrote:
Currently NaN is not violating
any language rules -- it is just violating users' intuition, in a much
worse way than Inf does.
If it's to be an official language non-rule (by which I mean
that types are officially allowed to compare non-reflexively)
then any code assumin
Nick Coghlan wrote:
Because this assertion is an assertion about the behaviour of
comparisons that violates IEEE754, while the assertions I list are all
assertions about the behaviour of containers that can be made true
*regardless* of IEEE754 by checking identity explicitly.
Aren't you making
Mark Shannon wrote:
NaN does not have to be a float or a Decimal.
Perhaps it should have its own class.
Perhaps, but that wouldn't solve anything on its own. If
this new class compares reflexively, then it still violates
IEE754. Conversely, existing NaNs could be made to compare
reflexively wi
Nick Coghlan wrote:
I hadn't really thought about it that way before this discussion - it
is the identity checking behaviour of the builtin containers that lets
us sensibly handle cases like sets of NumPy arrays.
Except that it doesn't:
>>> from numpy import array
>>> a1 = array([1,2])
>>> a2
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
+Inf and -Inf are arguably useful elements of the algebra,
yet Python insists on raising an exception for 1.0./0.0
instead of returning an infinity.
Why do this but not raise an exception for any op
Steven D'Aprano wrote:
If I do x = 0.0/0 I get an exception instead of a NAN.
But the exception you get is ZeroDivisionError, so I think
Python is catching this before you get to the stage of
producing a NaN.
--
Greg
___
Python-Dev mailing list
Pyth
Mark Shannon wrote:
The online documentation specifies which API function borrow and/or
steal references (as opposed to the default behaviour).
Yet, I cannot find this information anywhere in the source.
There are comments in some places, e.g. in listobject.h:
*** WARNING *** PyList_SetIte
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom format.
However, it doesn't seem to quite convey the same information.
It lists the "refcount effect" on each parameter, but translating
that into the notion of borrowed or stolen references seems
to require kno
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's not important to know what the function does to the object,
Only the action on the reference is relevant.
Yes, that's the whole point
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
There, Linus says
For example, if you have an _explicit_ refcounting system, then it is
quite natural to have operations like ...
note_t *node = *np;
if (node->count > 1)
Antoine> http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is undefined. And going-out-of-scope destructors are extremely
useful. Python is already a rather broken in thi
Mark Shannon wrote:
For example, a file object will close itself during finalization,
but its still a valid object, just a closed file rather than an open one.
It might be valid in the sense that you won't get a segfault.
But the point is that the destructors of some objects may be
relying on
Mark Shannon wrote:
With a tracing GC:
While the Elements are finalized, the Document is still alive.
While the Document is finalized, the Elements are still alive.
Then, and only then, is the whole lot reclaimed.
One problem is that, at the C level in CPython, you can't separate
finalisation
Stefan Behnel wrote:
After all, the described crash case indicates that
the Document destructor was called before all of the Element destructors
had been called, although all Elements reference their Document, but the
Document does not refer to any of the Elements,
In that case, why was the G
Stefan Behnel wrote:
It's a dead-end that is referenced by a cycle, that's all.
But shouldn't it be breaking the cycle by clearing one
of the objects that's actually part of the cycle, rather
than part of the dead-end?
I can't see how the Document could get picked for clearing
unless it was a
Nick Coghlan wrote:
One interesting aspect is that from the caller's point of view, a
*new* reference to the relevant behaves like a borrowed reference for
input parameters, but like a stolen reference for output parameters
and return values.
I think it's less confusing to use the term "new" o
Marvin Humphrey wrote:
incremented: The caller has to account for an additional refcount.
decremented: The caller has to account for a lost refcount.
I'm not sure that really clarifies anything. These terms
sound like they're talking about the reference count of the
object, but if they cor
Ethan Furman wrote:
On the one hand we have the 'bytes are ascii data' type interface, and
on the other we have the 'bytes are a list of integers between 0 - 256'
interface.
I think the weird part is that there exists a literal for
writing a byte array as an ascii string, and furthermore
that
Robert Collins wrote:
urlparse converting bytes to 'str' to operate on them is
at best a kludge - you're forcing 5 times the storage (the original
bytes + 4 bytes-per-byte when its decoded into unicode)
That is itself an implementation detail of current Python,
though, due to it only having one
Georg Brandl wrote:
We do have
bytes.fromhex('deadbeef')
But again, there is a run-time overhead to this.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
Eric Smith wrote:
And of course it's too late to make any change to this.
It's too late to change the meaning of b'...', but is it
really too late to introduce an x'...' literal and change
the repr() to produce it?
--
Greg
___
Python-Dev mailing lis
Ethan Furman wrote:
some_var[3] == b'd'
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the other object is an int, and
2) 0 <= other_obj < 256
3) if 1 and 2, make the comparison instead of returning NotImplemented?
It might seem convenient, but I'd worry tha
Victor Stinner wrote:
squares = (x*x for x in range(1))
What bytecode would you optimise that into?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
Victor Stinner wrote:
I suppose that you have the current value of range(1) on the stack:
DUP_TOP; BINARY_MULTIPLY; gives you the square. You don't need the x
variable (LOAD_FAST/STORE_FAST).
That seems far too special-purpose to be worth it to me.
--
Greg
Guido van Rossum wrote:
Bingo. That's why. (Though you are missing some colons in your examples. :-)
--Guido
On Thu, Jun 2, 2011 at 11:50 AM, Glenn Linderman wrote:
One place a double indent is extremely nice is for lines that initiate a new
indentation, but are themselves continued:
if som
Ben Wolfson wrote:
You can't have an internal replacement
field in this part of the replacement field, so '{' can always safely
be assumed to be Just a Brace and not the start of a replacement
field, regardless of whether it's doubled,
I'm worried that the rules in this area are getting too
com
Guido van Rossum wrote:
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
Proposals to address this include:
- introduce a "character" literal to allow c'a' as an alternative to
ord('a')
-1; the result is not a *character* but an integer.
Would you be happier if it were spelled i'a' in
Raymond Hettinger wrote:
The problem you're trying to solve isn't unique to structs.
That's why we get periodic requests for ropes-like behaviors
I don't think he's asking for rope-like behaviour here.
Rather, he's asking for iterator-like or view-like
behaviour -- for the same reasons we have
Raymond Hettinger wrote:
How would you describe the creation of a lazy result
that keeps a reference to the underlying buffer?
I'd call it a view. There is plenty of precedence for this
kind of object in Python -- I gave a few examples before.
The distinguishing feature of ropes, as I underst
Ben Wolfson wrote:
If by "item selector" you mean (using the names from the grammar in
the docs) the element_index, I don't see why this should be the case;
dictionaries can contain non-identified keys, after all.
Of course they can, but that's not the point. The point is
that putting arbitrar
Nick Coghlan wrote:
Indeed, PEP 380 is *really* hard to do properly without language
support. The language moratorium and lack of a Python 3 compatible
patch
Pardon? My original patch was for 3.1.2.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyt
P.J. Eby wrote:
At 10:46 AM 6/25/2011 +1000, Nick Coghlan wrote:
Indeed, PEP 380 is *really* hard to do properly without language
support.
No, it isn't. You add a decorator, a 'from_' class, and a 'return_'
function, and there you go. (See my previous code sketches here in
early PEP 380 d
Vlad Riscutia wrote:
Longer term though, I think it
would be better to add a property on the Structure class for
configurable allocation strategy, for example Native (default), GCC,
MSVC
It could also be good to have a mode which lets you specify
*exactly* how the bits are laid out, independe
Tom Whittock wrote:
Currently every time one of these objects is accessed from Python, a
new "myproxy" instance is created. So if I were to access the same
field of an object twice, I would receive two python objects proxying
the same underlying C++ object.
Perhaps you could use a WeakValueDic
Mark Hammond wrote:
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
perhaps we could remember the last non-launcher association when
we install the launcher,
It might be better to look in the registry for other Python
installations and ask the user which one to restore if there
is more than one. T
Vinay Sajip wrote:
the installation of a pre-3.3 version of Python after Python 3.3 is
installed with the launcher will, if the user selects "Register Extensions",
hijack the laumcher's associations to that earlier Python. Then bye bye launcher
I don't see how anything can be done about that. I
Antoine Pitrou wrote:
The additional confusion lies in the fact that a module can be shadowed
by something which is not a module (a mere global variable). I find it
rather baffling.
I think we're stuck with that as long as we use the same
syntax for importing a submodule and importing a non-mo
P.J. Eby wrote:
"from x import y" means "import x; y = x.y".
It actually means slightly more that that if y is a submodule,
in which case it means "import x.y; y = x.y".
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
I recently encountered a very mysterious bug in which
a background thread would inexplicably hang while attempting
to make a connection using httplib.
Debugging as far as I could at the Python level led to
the surprising conclusion that it was hanging while
using the ascii codec to encode the hos
Armin Rigo wrote:
> if we consider a
> CPython in which the cycle GC has been disabled by the user, then many
> __del__'s would not be called any more at interpreter shutdown.
That can happen now anyway. Module clearing only cleans up
cycles that go through the module dict.
+1 from me on getting
select() could be taught to recognise
socket objects natively.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a m
Georg Brandl wrote:
> Ahh, now the dime has fallen ;) (sorry, German phrase)
In English it's "the penny has dropped", so it's
not much different. :-)
Although I thought dimes were an American thing,
and Germans would be more likely to use a different
coin.
--
Greg Ewing
Talin wrote:
> As in the
> above example, the use of backticks can be signal to the document
> processor that the enclosed text should be examined for identifiers and
> other Python syntax.
Does this mean it's time for "pyST" -- Python-structured
text?-)
--
Greg E
aforementioned iterable can yield *anything*,
then it might yield this 'nodef' value as well.
For this reason, there *can't* exist any *standard*
guaranteed-unambiguous sentinel value. Each use
case needs its own, to ensure it's truly unambiguous
in the context of
Guido van Rossum wrote:
> Last call for discussion! I'm tempted to reject this -- the ability to
> generate optimized code based on the shortcut semantics of and/or is
> pretty important to me.
Please don't be hasty. I've had to think about this issue
a bit.
The conclusion I've come to is that t
Aahz wrote:
> Guido has previously given himself explicit permission to violate
> netiquette (including the rule about top-posting).
Only in the Python mailing lists, I hope -- unless
he's declared himself BDFL of the whole Internet
as well. :-)
I suppose he could be considered to have a right to
I've had a report from a user that Plex runs about half
as fast in 2.5 as it did in 2.4. In particular, the
NFA-to-DFA conversion phase, which does a lot of
messing about with dicts representing mappings between
sets of states.
Does anyone in the Ministry for Making Python Blazingly
fast happen t
Phillip J. Eby wrote:
> ...at the cost of slowing down access to properties and __slots__, by
> adding an *extra* dictionary lookup there.
Rather than spend time tinkering with the lookup order,
it might be more productive to look into implementing
a cache for attribute lookups. That would help w
ocean wrote:
> So, probably hash, comparation mechanizm of old/new style class has changed.
> # improved for new style class, worse for old style class. Maybe optimized
> for new style class?
Thanks -- it looks like there's a simple solution that
will make Plex even faster! I'll pass this on to t
Andy C wrote:
> What does "if __name__ == '__main__" mean in
> __main__.py? : ) If someone tries does import __main__ from another
> module in the program, won't that result in an infinite loop?
Is there a reason not to use __init__.py for this?
--
Greg
_
Anders J. Munch wrote:
> How about .pyzip instead? To make it more obvious, and not mistakable for
> .py.z.
Indeed. Is there any need to restrict extensions to
3 characters these days? Last time I experimented
with this on Windows, it seemed to handle longer
extensions okay.
--
Greg
__
Bill Janssen wrote:
> Someone wrote:
> >Emacs will probably go the way of the vinyl record (though the latter
> > is seeing a resurgence lately :).
>
> Doubt it. Even as we speak, there's probably a student planning to
> implement Python 3 in ELisp as a SOC project...
And run it on a computer
ges wrt source code representation. We should
be able to write our comments in HTML with
embedded SVG diagrams. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
, but in my
Think Pascal days I wrote most of my Pascal in Geneva.
I thought it actually looked quite nice that way,
especially with TP's auto-formatting.
It depends a lot on the font, though -- I don't think
I'd like to program in Times, for instance.
--
G
ces, indentation still
works since it's all at the beginning of a line.
Certain *conventions* sometimes used by programmers
might require it, but that's a different thing.
[1] Brainf**k is an obvious exception.
--
Greg Ewing, Computer Science Dept, +--
Raymond Hettinger wrote:
> In the case of iter(collection), I prefer the current wording because the
> target object need not support __iter__, it is sufficient
> to supply a sequential __getitem__ method.
Seems to me that should be included in the definition of
an iterable -- i.e. anything for
Georg Brandl wrote:
> Greg Ewing schrieb:
>
>>This just goes to show we're living in the dark ages wrt source code
>>representation. We should be able to write our comments in HTML with
>>embedded SVG diagrams. :-)
>
> PowerPoint, coding edition?
It
l_meaning
mapping.
Perhaps this will be fixed in English 3.0...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning
James Y Knight wrote:
> On Aug 8, 2007, at 3:47 PM, Nick Maclaren wrote:
> > Firstly, things like backreferences are an absolute no-no. They
> > are not regular, and REs with them in cannot be converted to DFAs.
>
> People keep saying things like this as if GNU grep and tcl's regular
> expressio
Nick Maclaren wrote:
> You can convert them to things that are sort of NFA/DFA
> hybrids,
If you could express it as an NFA, then you could
(in principle) convert it to a DFA. So whatever it's
using can't be an NFA either.
--
Greg
___
Python-Dev mailing
Paul Moore wrote:
> What the sentence you quote
> is trying to say is that if there's a need to compile source, the
> get_code method must do this on behalf of the caller - it can't return
> None and expect the caller to try get_source and compile it manually.
Why not simply say that it must retur
Jason Orendorff wrote:
> I think the weirdness comes from parsing -a/b as (-a)/b rather than
> -(a/b).
This will sort of be fixed in 3.0, at least for /, because
it will always mean float division, for which -(a/b) == (-a)/b.
You'll have to use // to get weirdness, then. :-)
--
Ryan Freckleton wrote:
> At one time Guido mentioned adding a built-in product() function to
> cover some of the remaining use cases of the built-in reduce().
Speaking of such things, I was thinking the other day
that it might be useful to have somewhere in the stdlib
a full set of functions for d
Guido van Rossum wrote:
> But what's the point, given that numpy already exists? Wouldn't you
> just be redoing the work that numpy has already done?
Sometimes I just want to do something simple like
adding two vectors together, and it seems unreasonable
to add the whole of numpy as a dependency j
Martin v. Löwis wrote:
> I think this requires a PEP, and explicit support from the
> NumPy people.
Someone who knows more about numpy's internals would
be needed to figure out what the details should be
like in order to be usable by numpy. But I could write
a PEP about how what I have in mind wou
Guido van Rossum wrote:
> I still don't see why the standard library needs to be weighed down
> with a competitor to numpy.
The way to get things done efficiently with an interpreted
language is for the language or its libraries to provide
primitives that work on large chunks of data at once, and
Nick Coghlan wrote:
> Travis has actually been working on this off-and-on for the last couple
> of years,
Well, yes, but that's concentrating on a different aspect
of things -- the data storage.
My proposal concerns what you can *do* with the data,
independent of the way it's stored. My idea and
Guido van Rossum wrote:
> By all means do write up a PEP -- it's hard to generalize from that one
> example.
I'll write a PEP as soon as I get a chance. But the
generalisation is pretty straightforward -- just replicate
that signature for each of the binary operations.
--
Greg
__
Phillip J. Eby wrote:
> It's also every built-in type
> structure, builtin module, builtin function... any Python object
> that's a built-in, period.
Where "built-in" in this context means anything implemented
in C (i.e. it includes extension modules).
--
Greg
_
Martin v. Löwis wrote:
> Sure - but those things don't get modified that often, except for their
> reference count.
The reference count is the killer, though -- you have
to lock the object even to do that. And it happens
a LOT, to all objects, including immutable ones.
--
Greg
___
Martin v. Löwis wrote:
> Now we are getting into details: you do NOT have to lock
> an object to modify its reference count. An atomic
> increment/decrement operation is enough.
I stand corrected. But if it were as simple as that,
I think it would have been done by now. I got the
impression that
ing that would be distastrous, which is the
case where the refcount becomes zero prematurely.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
ate (thread state, interpreter
> state, etc)?
Could be worth a try. A first step might be to just implement
the atomic refcounting, and run that single-threaded to see
if it has terribly bad effects on performance.
--
Greg Ewing, Computer Science Dept, +--+
Univ
on
non-global objects. Putting in a test would slow
all of them down, but only speed a few of them
up.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I&#
).
What you don't seem to see is that this would have
no less overhead, and probably a lot *more*, than
a mutex or other standard synchronisation mechanism.
Certainly a lot more than an atomic instruction for
the incref/decref.
--
Greg Ewing, Comp
eads? That sounds like the really clever bit to me.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.)
Justin Tulloss wrote:
>
> What do you think of a model where there is a global
> "thread count" that keeps track of how many threads reference an object?
I've thought about that sort of thing before. The problem
is how you keep track of how many threads reference an
object, without introducing
or
emptiness is clearly expecting x to be a sequence, *not*
an iterator, and you've violated the contract by passing
it one. This is what you may be running into with the libraries
you mention.
Generally I think it's a bad idea to try to pr
Although I suspect that a string containing "\r\n" is going
to cause more problems for Python applications than this.
E.g. consider what happens when you try to split a string
on newlines.
--
Greg Ewing, Computer Science Dept, +--+
University of
convenient to be able to catch EnvironmentError and
get anything that is caused by circumstances outside the
program's control.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurc
ary between Python
code and .NET code.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a mo
or codes
might belong to different domains. Although I suppose
you could have another attribute to distinguish them
if necessary.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurc
unds like it has something to do
with the unix environment variables.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm
Nick Maclaren wrote:
> Grrk. That's the problem. You don't get back what you have written
You do as long as you *don't* use universal newlines mode
for reading. This is the best that can be done, because
universal newlines are inherently ambiguous.
If you want universal newlines, you just have
On 9/29/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Now, BCPL was an ancestor of C, but always was a more portable
> language (i.e. it didn't start with a specific operating system in
> mind), and used/uses a rather better model. In this, line separators
> are atomic - e.g. '\f' is newline-wit
Michael Foord wrote:
> One of the great things about IronPython is that you don't *need* any
> wrappers - you access .NET objects natively
But it seems that you really *do* need wrappers to
deal with the line endings problem, whether they're
provided automatically or you it yourself manually.
Th
r of the above models cause the confusion being shown by
> the postings in this thread.
There's no confusion about how newlines are represented
*inside* a Python program. The convention is quite clear -
a newline is "\n" and only "\n"
an that you "don't get
back what you wrote". If you write "\f\n" to a file using
Python and read it back, you get "\f\n". If you write just
"\f", you get back "\f". What the \f *means* is a separate
issue.
--
Greg Ewing, Computer Sc
blem should really be
addressed at the source, which is the Python/.NET boundary.
Anything else would just lead to ambiguity.
So I'm voting -1 on my own proposal here.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
ould say IronPython is getting it wrong by using inconsistent
internal representations of line endings.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'
t need any wrappers. To make
that really true would require IronPython to become
a different language that has a different canonical
representation of newlines.
It's fine with me to keep things as they are.
--
Greg Ewing, Computer Science Dept, +--+
rge
chunks of memory like mark-and-sweep, it happens far less
frequently than would happen if mark-and-sweep were used
for all memory management. Also, the programmer can
minimise the need for it by manually breaking cycles
where they are known to occur.
--
Greg Ewing, Computer Science Dept, +---
Nick Maclaren wrote:
> if Python's own
> interpretation is ambiguous, it is a sure recipe for different
> translators being incompatible,
Python's own interpretation is not ambiguous. The
problem at hand is people wanting to use some random
mixture of Python and .NET conventio
appers, especially cross-platform ones like wxPython.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.
and only
mallocs more if that fails.
I think it also counts the number of allocations
made since the last GC and does a GC when it gets
up to some threshold, so that things get cleaned
out periodically and the processing is spread
out somewhat.
--
Greg Ewing, Computer Scie
Adam Olsen wrote:
> This isn't true at all. It's triggered by heuristics based on the
> total number of allocated objects.
Hmmm, all right, it seems I don't know what I'm
talking about. I'll shut up now before I spread
any more misinformation. Sorry.
--
Gr
Hrvoje Nikšić wrote:
> That sounds like a case for the Pixbuf object to have a "close" method
> (not necessarily called that) that releases the resources. The point of
> GC is that you normally don't care if memory is released sooner or
> later;
I think the problem here is that the GC's lack of k
Martin v. Löwis wrote:
> For stack frames,
> such a registration is difficult to make efficient.
Also very error-prone if you happen to miss one. Although
maybe no more error-prone than getting the reference
counting right.
--
Greg
___
Python-Dev mailin
A while back I wrote about a problem I was having with
the ordering of -framework options in distutils compilation
commands. Well, now I've discovered something even stranger.
When distutils executes the following link command, I get
a bunch of undefined OpenGL-related symbols. But if I
copy and p
1401 - 1500 of 2443 matches
Mail list logo
