Is there any provision for keeping the compiled
C code and distributing it along with an application?
Requiring a C compiler to be present at all times
could be a difficulty for Windows.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
PJ Eby wrote:
At the least, if they're
not going to be in decorator order, the member shouldn't be called
__decorators__. ;-)
Obviously it should be called __srotaroced__.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Alexander Belopolsky wrote:
The problem is again the DST ambiguity. One day a year, datetime(y,
m, d, 1, 30, tzinfo=Local) represents two different times and another
day it represents no valid time.
The documentation example (fixed in issue 9063) addresses the
ambiguity by defaulting to
Terry Reedy wrote:
A rich comparison method may return the singleton NotImplemented if it
does not implement the operation for a given pair of arguments. By
convention, False and True are returned for a successful comparison.
However, these methods can return any value,
That's to give the
Dag wrote:
I'm not asking you to consider the details of all that.
Just to allow some kind of high-performance extensibility of
PyTypeObject, so that we can *stop* bothering python-dev with
specific requirements from our parallel universe of
nearly-all-Cython-and-Fortran-and-C++ codebases
On 17/05/12 12:17, Robert Bradshaw wrote:
This is exactly what was proposed to start this thread (with minimal
collusion to avoid conflicts, specifically partitioning up a global ID
space).
Yes, but I think this part of the mechanism needs to be spelled out in
more detail, perhaps in the form
Nick Coghlan wrote:
On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
implement it differently. That's not the case with
build_class
Nick Coghlan wrote:
In that case, consider me convinced: static method it
is.
-0.93. Static methods are generally unpythonic, IMO.
Python is not Java -- we have modules. Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
Nick Coghlan wrote:
Instead, I'm now thinking we should add a _types C extension module
and expose the new function as types.build_class(). I don't want to
add an entire new module just for this feature, and the types module
seems like an appropriate home for it.
Dunno. Currently the only
Mark Dickinson wrote:
Is the gain from this kind of micro-optimization really worth the cost
of replacing obviously correct code with code whose correctness needs
several minutes of thought?
The original code isn't all that obviously correct to me either.
I would need convincing that the
Larry Hastings wrote:
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError.
TypeError is not just for values of the wrong type,
it's also used for passing
Alexandre Vassalotti wrote:
We have custom stack and
dictionary implementations just for the sake of speed. We also have fast
paths for I/O operations and function calls.
All of that could very likely be carried over almost
unchanged into a Cython version. I don't see why it
should take
Antoine Pitrou wrote:
(and here we see why reference-stealing APIs are a nuisance: because
you never know in advance whether a function will steal a reference or
not, and you have to read the docs for each and every C API call you
make)
Fortunately, they're very rare, so you don't encounter
On 19/04/12 11:22, Tres Seaver wrote:
Maybe we should mandate that their names end with '_rtfm'.
+1
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Mark Shannon wrote:
We have recently removed the f_yieldfrom field from the frame object.
(http://bugs.python.org/issue14230)
Hey, wait a minute. Did anyone consider the performance effect
of that change on deeply nested yield-froms?
The way it was, a yield-from chain was traversed by a very
Cameron Simpson wrote:
I maintain that
monotonic still means what I said, and that it is the combination of
the word with clock that brings in your other criteria.
I'm not trying to redefine the word monotonic in general.
All I'm saying is that *if* the PEP is going to talk about
a monotonic
Steven D'Aprano wrote:
Greg Ewing wrote:
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
Well, yes, but even that's not enough -- it needs to go forward
at a reasonably constant rate, otherwise it's
Cameron Simpson wrote:
A monotonic clock never returns t0 t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word monotonic,
but the way it's used in
Lennart Regebro wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
--
Cameron Simpson wrote:
People have been saying hires throughout the
threads I think, but I for one would be slightly happier with highres.
hirez?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Steven D'Aprano wrote:
While I sympathize with the ideal of making the docs readable,
particular for those of us who don't have 20-20 vision, must be
readable from halfway across the room is setting the bar too high.
The point is that reducing contrast never makes anything more
readable, and
Glyph Lefkowitz wrote:
do I have to resize my browser every time I visit a new site to get a
decent width for reading.
If all sites left the width to the browser, then I would
be able to make my browser window a width that is comfortable
for me with my chosen font size and leave it that way.
PJ Eby wrote:
Weird - I have the exact *opposite* problem, where I have to resize my
window because somebody *didn't* set their text max-width sanely (to a
reasonable value based on ems instead of pixels), and I have nearly 1920
pixels of raw text spanning my screen.
If you don't want
Can we please get rid of the sidebar, or at least provide
a way of turning it off? I don't think it's anywhere
near useful enough to be worth the space it takes up.
You can only use it when you're scrolled to the top of
the page, otherwise it's just a useless empty space.
Also, I often want to
Ned Batchelder wrote:
Any of the tweaks people are suggesting could be applied individually
using this technique. We could just as easily choose to make the site
left-justified, and let the full-justification fans use custom
stylesheets to get it.
Is it really necessary for the site to
Guido van Rossum wrote:
I personally like having 'iter' in the name (e.g. iterkeys() -- note
that we dropped this in Py3k because it's no longer an iterator, it's
a dict view now. But I don't want to promote that style for ipaddr.py.
+1 from me too on having all methods that return iterators
R. David Murray wrote:
My understanding, though, is that Python
does make a distinction between a system install of Python and
a per-user one, so I don't think your objection really applies.
Seems to me that for Python at least, the important distinction
is not so much where the files are
Armin Rigo wrote:
For example, let's assume we can decref
a object to 0 before its last usage, at address x. All you need is
the skills and luck to arrange that the memory at x becomes occupied
by a new bigger string object allocated at x - small_number.
That's a lot of assumptions. When you
Thomas Wouters wrote:
Why even have separate tp_as_sequence and tp_as_mapping anymore? That
particular distinction never existed for Python types, so why should it
exist for C types at all? I forget if there was ever a real point to it,
I imagine the original motivation was to provide a fast
Maciej Fijalkowski wrote:
Segfaults (most of them) can generally be made into arbitrary code
execution,
Can you give an example of how this can be done?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Mark Shannon wrote:
You can't solve the too much time, without solving the halting problem,
but you can make sure all code is interruptable (i.e. Cntrl-C works).
If you can arrange for Ctrl-C to interrupt the process cleanly,
then (at least on Unix) you can arrange to receive a signal
after a
Stefan Krah wrote:
Options 2) and 3) would ideally entail one backwards incompatible
bugfix: In 2.7 and 3.2 assignment to a memoryview with format 'B'
rejects integers but accepts byte objects, but according to the
struct syntax mandated by the PEP it should be the other way round.
Maybe a
Nick Coghlan wrote:
Armin's straw poll was actually about whether or not people used the
future import for division, rather than unicode literals. It is indeed
the same problem
There are differences, though. Personally I'm very glad of the
division import -- it's the only thing that keeps me
Guido van Rossum wrote:
if there is an *actual*
causal link between file A and B, the difference in timestamps should
always be much larger than 100 ns.
And if there isn't a causal link, simultaneity is relative
anyway. To Fred sitting at his computer, file A might have
been created before
On 16/02/12 06:43, Guido van Rossum wrote:
This does not explain why microseconds aren't good enough. It seems
none of the clocks involved can actually measure even relative time
intervals more accurate than 100ns, and I expect that kernels don't
actually keep their clock more accurate than
Glyph wrote:
Yes, but you /can/ look at a 'yield' and conclude that you /might/ need
a lock, and that you have to think about it.
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over
Matt Joiner wrote:
ಠ_ಠ
What's up with these ?_? messages?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Mark Shannon wrote:
I have a new dict implementation which allows sharing of keys between
objects of the same class.
We already have the __slots__ mechanism for memory savings.
Have you done any comparisons with that?
Seems to me that __slots__ ought to save even more memory,
since it
Nick Coghlan wrote:
In reviewing Zbyszek's doc updates and comparing them against the Grammar, I
discovered a gratuitous change in the implementation: it allows a bare (i.e. no
parentheses) 'yield from' as an argument to a function.
I'll add a new test to ensure yield from x requires
Guido van Rossum wrote:
I see this as inevitable. By the time the parser sees 'yield' it has
made its choices; the 'from' keyword cannot modify that. So whenever
yield expr must be parenthesized, yield from expr must too.
This is patently untrue, because by version of the grammar
allows
On 10/11/11 05:18, Amaury Forgeot d'Arc wrote:
Do we need to designate a release manager?
I nominate John Cleese. Although he's undoubtedly a busy
man, this shouldn't take up too much of his time.
--
Greg
___
Python-Dev mailing list
On 10/11/11 12:11, Guido van Rossum wrote:
Actually it is valid, meaning yield (expr, expr) in any context
where yield expr is valid
Hmmm, it seems you're right. I was testing it using my patched
yield-from version of Python, where it has apparently become a
syntax error. I didn't mean to
On 10/11/11 11:43, Tim Delaney wrote:
We have precedent for being more restrictive initially, and relaxing those
restrictions later.
I suggest that the more restrictive implementation go in now so that people
can start playing with it. If the discussion comes to a consensus on more
relaxed
On 10/11/11 14:50, Nick Coghlan wrote:
I'd actually be amenable to making it legal to omit
the extra parentheses for both yield yield from in the single
argument case where there's no ambiguity...
The way your patch tried to do it also allowed f(yield
from x, 1) which strikes me as being far
Martin v. Löwis wrote:
That wouldn't be instead, but in addition - you need the
variable name, anyway.
But the details of exactly how the name is constructed
could be kept as an implementation detail.
Not sure whether there is actually
a gain in readability - people not familiar with this
Martin v. Löwis wrote:
So I think it needs a prefix. If you don't like PyId_, let me know
what the prefix should be instead.
Instead of an explicit prefix, how about a macro, such as
Py_ID(__string__)?
--
Greg
___
Python-Dev mailing list
Lennart Regebro wrote:
+1 for env or sandbox or something else with box in it.
Eggbox? Eggcrate? Incubator?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Benjamin Peterson wrote:
Why not just have it return 0 on error? This would be more consistent with API
functions that return false values like NULL
But that would make it confusingly different from all the other
functions that return ints. The NULL convention is only used
when the function
Steven D'Aprano wrote:
Given that strings are immutable, would it not be an obvious
optimization for replace to return the source string unchanged if the
old and new substrings are equal,
Only if this situation occurs frequently enough to outweigh
the overhead of comparing the target and
Ethan Furman wrote:
Well, actually, I'd be using it with dates. ;)
Seems to me that one size isn't going to fit all.
Maybe we really want two functions:
interpolate(start, end, count)
Requires a type supporting addition and division,
designed to work predictably and
Fernando Perez wrote:
Now, I *suspect* (but don't remember for sure) that the option to have it
right-hand-open-ended was to match the mental model people have for range:
In [5]: linspace(0, 10, 10, endpoint=False)
Out[5]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
In [6]:
Guido van Rossum wrote:
Or, maybe what I'm trying to say is, if the
user has start/end/count but the API wants start/step/count, after
computing step = (end-start) / count, the value of start + count*step
might not quite equal to end; whereas if the user has start/step/count
but the API wants
Alexander Belopolsky wrote:
I don't think we'll gain anything by
copying numpy code because linspace(start, stop, num) is effectively
just
arange(0, num) * step + start
I don't think the intention was to literally copy the
code, but to investigate borrowing the algorithm, in case
it was using
Alexander Belopolsky wrote:
(Comb (noun) brings up the right image, but is probably too
informal and may be confused with a short for combination.)
And also with comb filter for those who are into
signal processing.
--
Greg
___
Python-Dev mailing
Ethan Furman wrote:
If it's generic, why should it live in math?
Generic? Maybe that's it: grange()
It's also an English word, unfortunately one with a
completely unrelated meaning. :-(
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Ethan Furman wrote:
The only reason I'm aware of at the moment is to prevent loss of
functionality from 2.x range to 3.x range.
Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't
see any loss of functionality there.
Comparing range objects directly in 3.x is like comparing
Victor Stinner wrote:
NUL is an abbreviation used in tables when you don't have enough space
to write the full name: null character.
It's also the official name of the character, for when you want
to be unambiguous about what you mean (e.g. null character as
opposed to empty string or null
Terry Reedy wrote:
While it has apparently been criticized as 'conservative' (which is well
ought to be), it has been rather progressive in promoting changes such
as 'ph' to 'f' (fisica, fone) and dropping silent 'p' in leading 'psi'
(sicologia) and silent 's' in leading 'sci' (ciencia).
I
Guido van Rossum wrote:
I recall long ago that when the french wrote words in all caps they
would drop the accents, e.g. ECOLE. I even recall (through the mists
of time) observing this in Paris on public signs. Is this still the
convention?
This page features a number of French street signs
Guido van Rossum wrote:
But in a word like coëxistentie (coexistence) the o
and e do not form the oe-sound, and to emphasize this to Dutch readers
(who believe their spelling is very logical :-), the official spelling
puts the umlaut on the e.
Sometimes this is done in English too --
Terry Reedy wrote:
Too bad, since people sometimes use '-' to serve the same purpose.
Which actually seems more logical to me -- a separating
symbol is better placed between the things being separated,
rather than over the top of one of them!
Maybe we could compromise by turning the diaeresis
Antoine Pitrou wrote:
I don't think some American souvenir shop is a good reference, though :)
(for example, there's no Paris street named château de Versailles)
Hmmm, I'd assumed they were reproductions of actual
street signs found in Paris, but maybe not. :-(
--
Greg
Nick Coghlan wrote:
Personally, I *like* CPython fitting into the simple-and-portable
niche in the Python interpreter space.
Me, too! I like that I can read the CPython source and
understand what it's doing most of the time. Please don't
screw that up by attempting to perform heroic
Guido van Rossum wrote:
(Just like Python's own .h files --
e.g. the extensive renaming of the Unicode APIs depending on
narrow/wide build) How does Cython deal with these?
Pyrex/Cython deal with it by generating C code that includes
the relevant headers, so the C compiler expands all the
Guido van Rossum wrote:
On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
All you
need to do when writing the .pyx file is follow the same
API that you would if you were writing C code to use the
library.
Interesting. Then how does Pyrex/Cython typecheck your
Guido van Rossum wrote:
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com wrote:
IMO, we really, really need some common way of accessing C libraries that
works for all major Python variants.
We have one. It's called writing an extension module.
I think Dan means some way
Nick Coghlan wrote:
The next step needed is for someone to volunteer to write and champion
a PEP that:
Would it be feasible and desirable to modify regex so
that it *is* backwards-compatible with re, with a view
to making it a drop-in replacement at some point?
If not, the PEP should discuss
Paul Moore wrote:
IronPython and Jython can retain UTF-16 as their native form if that
makes interop cleaner, but in doing so they need to ensure that basic
operations like indexing and len work in terms of code points, not
code units, if they are to conform. ... They lose the O(1)
guarantee,
M.-A. Lemburg wrote:
Simply going with UCS-4 does not solve the problem, since
even with UCS-4 storage, you can still have surrogates in your
Python Unicode string.
Yes, but in that case, you presumably *intend* them to
be treated as separate indexing units. If you didn't,
there would be no
On 25/08/11 14:29, Guido van Rossum wrote:
Let's get things
right so users won't have to worry about code points vs. code units
any more.
What about things like the surrogateescape codec that
deliberately use code units in non-standard ways? Will
tricks like that still be possible if the
Sturla Molden wrote:
With one interpreter per thread, and
a malloc that does not let threads share memory pages (one heap per
thread), Python could do the same.
Wouldn't that be more or less equivalent to running
each thread in a separate process?
--
Greg
Benjamin Peterson wrote:
why would you use Ellipsis outside of slices?
I could imagine someone wanting to use it as part of a
function API. For example,
print(a, b, c, ...)
would have been a nice way to tell print() not to put
a newline on the end.
--
Greg
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
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
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
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.
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. It
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
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
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
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,
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
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 arbitrary
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'
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
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
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 v+pyt...@g.nevcal.com wrote:
One place a double indent is extremely nice is for lines that initiate a new
indentation, but are
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
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:
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
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 that
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:
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
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
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
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
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
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
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
701 - 800 of 2277 matches
Mail list logo
