Ronald Oussoren wrote:
> Is that the system supplied version of Python?
No, it's my own installation of 2.3, but it's installed
as a framework in /Library/Frameworks.
> My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the
> environment by distutils.
I wondered about that -- I've noticed th
Ronald Oussoren wrote:
> The deployment target does have an influence on how the compiler
> functions, which can explain when setting the target to a different
> value causes problems.
I did some more experimenting, and it doesn't seem to be
related to MACOSX_DEPLOYMENT TARGET. I tried settin
Graham Horler wrote:
> I would be inclined to move gcc to gcc-real (for example), and create a script
> called gcc which dumps all environment variables, and command-line arguments
Well, I tried that -- and things got even weirder still.
With the wrapper in place between distutils and gcc, the
li
Oleg Broytmann wrote:
>Do you have a few different copies of gcc installed with setup.py called
> the wrong one and your shell script the right one?
As far as I can tell, it's using my PATH to find gcc,
and that leads to /usr/bin/gcc, which is the same one
my wrapper calls.
--
Greg
__
I wrote:
> As far as I can tell, it's using my PATH to find gcc,
> and that leads to /usr/bin/gcc, which is the same one
> my wrapper calls.
To make sure, I installed my wrapper in place of /usr/bin/gcc
and the same behaviour occurs.
--
Greg
___
Python
Shane Hathaway wrote:
> I was aware of Guido's earlier rejections, but I figured the rejection
> was due to the risky implicit optimization proposed by others. Perhaps
> the objection is deeper than that; I suspect Guido specifically objects
> to excessive use of recursion.
As I recall, one of t
Steve Holden wrote:
> Using a radix notation for literals would, IMHO, be acceptable if you
> can get the idea accepted
This would make decimal (or at least a part of it) a required
part of the Python core rather than an optional module. There
might be some resistance to that.
--
Greg
__
[EMAIL PROTECTED] wrote:
> This interface follows the completely stupid semantics of System V and
> IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks
> associated with a file for a given process are removed when any file
> descriptor for that file is closed by that proc
[EMAIL PROTECTED] wrote:
> Does fcntl.flock work over NFS and SMB and on Windows?
I don't think file locking will ever work over NFS, since
it's a stateless protocol by design, and locking would
require maintaining state on the server.
--
Greg
___
Pytho
Lauri Alanko wrote:
> In the end, for now, I made protocol 0 textual,
That could be a mistake. I believe there are some objects,
such as array.array, that use a binary format for pickling
even in protocol 0.
--
Greg
___
Python-Dev mailing list
Python-De
Guido van Rossum wrote:
> @property
> def encoding(self):
> return self._encoding
>
> @propset(encoding)
> def encoding(self, value=None):
> if value is not None:
> unicode("0", value) # Test it
> self._encoding = value
That's reasonably nice,
Guido van Rossum wrote:
> Isn't there? You can just use super() ISTR,
That may work, now that I come to think about it.
However, super() is not a complete solution, because
it doesn't let you choose which inherited method
to call in a multiple inheritance situation.
--
Greg
_
Guido van Rossum wrote:
> if you want more control, you can just get the property object out of
> the class you want
You're quite right. I was thinking that getting the
property would trigger the access machinery, but of
course you're getting it from the class rather than
the instance, so that doe
Fred Drake wrote:
>@property
>def attribute(self):
>return 42
>
>@property.set
>def attribute(self, value):
>self._ignored = value
Hmmm... if you were allowed general lvalues as the target of a
def, you could write that as
def attribute.
Raymond Hettinger wrote:
> Let's stick with "propset" which has precedent as an svn action and
> serves as a short, simple mnemonic to the functionality.
But if we're going to have "propset", it raises the question
of why there isn't a "propget".
--
Greg
Phillip J. Eby wrote:
> The lookup sequence should probably be something like:
>
>1. type(ob) is cls
>2. issubclass(type(ob), cls)
But can't issubclass be overridden as well?
--
Greg Ewing, Computer Science Dept, +--+
Univers
st not using them
> in this case)
Fine by me. I've always thought they were of dubious
value in the first place.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zeal
Guido van Rossum wrote:
> Not quite. You can evolve an API from an instancemethod into a
> staticmethod without changing the call sites.
But is there ever any need to do that, rather than leave
it as an instance method?
Personally it would never have occurred to me to do that.
If you want to be a
Phillip J. Eby wrote:
> If you are configuring it per-class and
> accessing it per-instance, and reusing an existing function, you have to
> make it a staticmethod.
I don't understand that. Can you provide an example?
> > some subclasser later finds that he wants access to
> > 'self'?
>
> Then
Christian Heimes wrote:
> Should the node structure gain an additional field to drag the filename
> around?
Why not?
Early on in the design of the Pyrex compiler, I made the decision
that every parse tree node would contain a source filename and
position, down to character resolution. It's paid o
Phillip J. Eby wrote:
> class MoneyField(Field):
> # does need staticmethod because two_decimal_places
> # doesn't take a self
> converter = staticmethod(two_decimal_places)
Okay, I see what you mean now. But you could just as well wrap
it in a function that takes self and discards it
André Malo wrote:
> * Greg Ewing wrote:
>
> > But you could just as well wrap
> > it in a function that takes self and discards it,
>
> I always thought, that this is exactly what staticmethod does.
Not quite -- staticmethod prevents a self from getting
passed in the fi
Steve Holden wrote:
> The namespace should really be called __global__. I doubt this will fly,
> because it's too radical, and unfortunately would undermine the "global"
> keyword
__uberglobal__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.or
Guido van Rossum wrote:
> You can do that but the special entry in globals is still required in
> order to pass it on to all scopes that need it.
Unless you use something other than a plain dict for
module namespaces.
--
Greg
___
Python-Dev mailing list
The next step up from global would be __galactic__.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Nick Coghlan wrote:
> why not call it __implicit__?
But isn't __explicit__ better than __implicit__? :-)
I tend to agree about __root__, though -- it just
doesn't seem quite right somehow.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
Another idea:
__ubiquitous__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> __the_dictionary_where_all_the_builtins_are_now__
__the_entry_formerly_known_as_builtins__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Terry Reedy wrote:
> The only problem would be if someone put
> the incantation into a non-main module named 'main.py', but the same is
> true today of '__main__.py'. And I would consider either a buggy practice.
I often put the "real" main code into a separate module, so
that it gets compiled
Bill Janssen wrote:
> What I'd like to do is just use the socket API,
> something like:
>
> blocking = self.getblocking()
> try:
> self.setblocking(1)
> self.do_handshake()
> finally:
> self.setblocking(blocking)
I'm not sure this is the right approach. If the c
Terry Reedy wrote:
> I would prefer plain 'yield' to 'yield break' as a synonym for 'raise
> StopIteration'.
Don't we already have a plain yield these days meaning
something else?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Manuel Alejandro Cerón Estrada wrote:
> The real problem is that
> raising StopIteration is not orthogonal.
This is a non-problem as far as I can see. In a generator,
the way to stop the iteration is simply to return. In a
non-generator iterator, you're still going to have to
raise StopIteration.
Guido van Rossum wrote:
> Does Unix even promise that a signal gets delivered twice if it gets
> sent quickly twice in a row?
No, it doesn't.
However, this doesn't necessarily mean that you can just
drop them when the pipe becomes full. If more than one
type of signal is sharing a pipe, you don'
Manuel Alejandro Cerón Estrada wrote:
> Acording to PEP 255:
>
> Note that return isn't always equivalent to raising StopIteration: the
> difference lies in how enclosing try/except constructs are treated.
All that means is that
def g():
try:
if 0:
yield
s claim?
Even if it doesn't save any power, using CPU unnecessarily
is a bad thing for any application to do on a multitasking
system.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem!
Guido van Rossum wrote:
> Hm, Apple and Microsoft don't seem to think so. They go out of their
> way to implement elaborate visual effects.
Well, that's a different issue -- assuming the visual
effect is something wanted, then the CPU required to
produce it isn't unnecessary.
But there's no excu
tomer filiba wrote:
> the idea i came up with is, using exceptions for functional
> continuations: after all, the exception's traceback holds the entire
> context...
The problem with this is that, if the call chain has passed
through a C-implemented function at some point, the traceback
*doesn't*
By the way, I wouldn't call this a "continuation", as that
word implies a bit more (reusability). It's more like a
coroutine or lightweight thread.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
> On Jan 25, 2008 11:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>... int() for making ints from the non-fractional
>>portion of a float.
To me, the concept of the "integer part of a float" isn't all that
well defined. It's really a property of a particular representation
rather than
Isaac Morland wrote:
> What about an option (maybe even a default) to send the prompt to stdin?
>
> The Postgres command line interface psql appears to do this:
>
> $ psql 2>&1 >/dev/null
> Password:
> $
No, it's probably using the C stdlib routine getpass(). From the man
page:
The getpa
Jeroen Ruigrok van der Werven wrote:
> I cannot find anything explicitly in favour of or against this in POSIX. The
> stuff quoted below is what I could find.
>
> "3.105 Command Language Interpreter
>
> STDERR
>
> This section does not describe error messages that refer to incorrect
> operation
Guido van Rossum wrote:
> On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>So it appears that the official Unix Way prefers using stderr
>>over stdout for prompting, if using the std files for it at all.
>
> That's a dangerous generalization from
Travis Oliphant wrote:
> You could
> argue that it would be more informative by showing the C-equivalent
> structure as a 2-d array. However, it would also create the possibility
> of confusion by implying an absolute relationship between the C-compiler
> and the type description.
Just to che
Lisandro Dalcin wrote:
> Travis, all this make me believe that (perhaps) the 'format'
> specification in the new buffer interface is missing the 'C' or 'F'
> ordering in the case of a countiguos block.
Not strictly necessary, since you can always reverse the
indices when dealing with Fortran if ne
Christian Heimes wrote:
> By the way objects are always aligned at 8 byte address boundaries. A 12
> or 4 bytes object occupies 16 bytes.
Maybe pymalloc should be enhanced so it can cope with
certain odd-sized objects, such as 12 bytes?
--
Greg
___
Pyt
Eric Smith wrote:
> Are you saying I should call _PyType_Lookup first?
No, I think he's saying that you don't need to call
_PyType_Lookup at all, because anything that it could
find will also be found by PyObject_GetAttr.
So just call PyObject_GetAttr and it should Just Work.
--
Greg
___
Eric Smith wrote:
> 1: exposing builtin_format(), probably giving it another name
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
PyObject_DefaultFormat would be bett
Martin v. Löwis wrote:
> when some caller of PyEval_EvalFrameEx still carries
> a pointer to some object that got deleted, and then still some code can
> get hold of the then-deleted object.
I seem to have missed the beginning of this discussion.
I don't see what the problem is here. If a caller n
Raymond Hettinger wrote:
> ISTM that we need two versions of oct() like
> we need a hole in the head.
I don't know about oct(), but I found hex() to be quite useful
the other day when I was using the interactive interpreter to
to some hex calculations. It would have been quite tedious
having to sa
Neal Becker wrote:
> (Or, help me understand, what is the difference between a type that I create
> using python C api and a python class?)
Classes that you create in Python have a __dict__ attribute
holding a dictionary for arbitrary attributes to go in.
Most types defined in C don't bother prov
M.-A. Lemburg wrote:
> Why not also make unicode() the default type constructor and only
> keep str() as alias to simplify porting (perhaps with a warning) ?
-1 on making us type 7 characters instead of
3 all over the place.
> The term "string" is just too overloaded with all kinds of
> misinterp
Christian Heimes wrote:
> The latest alphas of Python 2.6 and 3.0 are build with VS 2088.
Wow, that must be a very, very pre-alpha release...
Or has someone at Redmond stolen Guido's time machine?
--
Greg Ewing, Computer
ltins.
Maybe the solution is to rename the Library Reference
to the Class and Module Reference or something like
that.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
o compile extensions
against *that* library instead. If it were compiled with
gcc but using one of the Microsoft libraries, the same
situation would exist as before.
The entire mess is all Microsoft's fault for not picking
one version of libc and sticking to it.
--
Greg Ewi
Mike Meyer wrote:
> Trying to install it from the repository is a PITA, because
> it uses both the easyinstall and Pyrex
It shouldn't depend on Pyrex as long as it's distributed
with the generated C files. If it's not, that's an
oversight on the part of the distributor.
Adam Olsen wrote:
> The term "Displays" is pretty obscure as well,
Hmmm, I'd call them "constructor expressions" or some such.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
Georg Brandl wrote:
> Adam Olsen schrieb:
>
>>Another example is the use of BNF, which although dominant in its
>>field, it provides a steep learning curve for most programmers.
>
> We could of course accompany each BNF-described item with an example.
An alternative to BNF would be syntax diagram
Steven Bethard wrote:
> Is this mainly a request to use more open source tools? Because if
> the concern is just cost, Python 2.6 and 3.0 compile with the free
> Microsoft Visual Studio 2008 Express editions.
I don't think it's only about cost, it's about not
being reliant on tools that appear an
Alexey Borzenkov wrote:
> I think the best lesson here is Tcl. Because it uses stubs mechanism,
> you don't need to depend on tclXX.dll, you don't deal with really
> direct implementation details, you don't care about runtimes,
How does that solve the problem of an extension using
one stdio libra
Aahz wrote:
> * Other Python implementations (Jython, PyPy, IronPython) may not be
> able to provide the same type implementations
>
> * Algorithmic information does sometimes change between versions, and
> keeping the docs updated is not trivial
Still, I think there are some general expectations
Martin v. Löwis wrote:
> Yes - the assumption is that more del calls will follow, so that the
> dictionary eventually ends up empty. Only when new inserts are made,
> that assumption is proven wrong, and the shrinking can be done in
> one sweep.
Hmmm. So the most efficient way to copy a dict that
Martin v. Löwis wrote:
> I would still debate the complexity of dict lookup. What are you
> averaging over?
All the Python programs I've ever run. :-)
> I also disagree that the average complexity is "most important".
> I find the worst-case complexity most important.
While in theory the worst
Forrest Voight wrote:
> Slice objects that are produced in a list index area would be different,
> and optionally the syntax for slices in list indexes would be expanded
> to work everywhere.
Something like this was quite close to getting in a while
back, but it was eventually dropped. Anyone advo
Dimitrios Apostolou wrote:
> On the other hand notes could be added for various oddities according to
> experience. For example that for sets up to 10(?) elements, a list would
> probably be better because of the hashing overhead.
That's the sort of thing that tends to be *very*
implementation
Martin v. Löwis wrote:
> To implement such a system, you need to get all ABI dependencies out
> of the header files; this includes the structure layouts in particular.
That could hurt the performance of some things. Macros
like PyList_GET_ITEM etc. rely on knowing about struct
layouts to get at th
Martin v. Löwis wrote:
> I follow the advice Guido gave: I use the data
> structure that will make my code shortest and easiest
> to read,
But given a choice such as list vs. dict, the code
is almost identical either way. What do you do then?
Toss a coin? Or make a few educated guesses based on
w
I'm trying to send a proxy form, but all my mail to
[EMAIL PROTECTED] or [EMAIL PROTECTED] is getting bounced.
Is there another address I can send it to that goes
through a different mail server?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.or
Neal Norwitz wrote:
> Part of this is done, but very differently in that all strings used in
> code objects are interned (stored in a dictionary
And since two interned strings can be compared
by pointer identity, I don't see how this differs
significantly from the "unique integer" idea.
If the in
Jeff Rush wrote:
> Perhaps it is time for a parallel rewrite,
> so that those setup.py who import distutils get the old behavior, and those
> who import distutils2 get the new,
That sounds good to me. If anyone wants to have a go
at this, I have some ideas on how to structure it
that I'd be happ
At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:
> A lot of setuptools warts are driven by related design problems in the
> distutils, such as the choice to use imperative / procedural code for
> everything
If a distutils replacement is ever written, I'd like to
see it structured as a dependency g
Jim Jewett wrote:
> In 2.5, the print statement ignores any overrides of the str builtin,
> but I'm not sure whether a _function_ should -- and I do think it
> should be specified.
I expect there are plenty of other things that use
str()-like behaviour without going through str(), so
making print
ajaksu wrote:
> While Linux and OS X both view Python as essentially a first-class
> development platform-i.e., as something that shrink-wrap applications
> can be built on-Windows does not.
Even on MacOSX and Linux, you can't rely on the system
coming with the particular version of Python you wan
Nick Coghlan wrote:
> Since we have some strong use cases at least for the bytes->int case,
> consistency then suggests that the other numeric types should all accept
> bytes as well (interpreting them as ASCII encoded strings).
How far should this go? Is conversion to numbers really
so special,
Terry Reedy wrote:
> The purpose of type constructors is to construct instances from reasonable
> inputs. I think all number constructors should accept bytes
What should bytes as input to a number constructor
mean, though?
People seem to be assuming it should be interpreted
as ASCII-encoded cha
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nick Coghlan wrote:
> Greg Ewing wrote:
>
>> I thought Decimal was going to be replaced by a C
>> implementation soon anyway.
>
> I believe that was found to be more trouble than it was worth.
That's very disappointing. Was there any discussion of
the problems tha
Nick Coghlan wrote:
> Yeah, this thread has convinced me that it would be better to start
> rejecting bytes in int() and float() as well rather than implicitly
> assuming an ASCII encoding.
I had another thought -- would it be feasible to have
some kind of wrapper object that would make a byte
Nick Coghlan wrote:
> I believe the list of incompatibilities and kludges and the subsequent
> comments in the following file give the gist of the problems:
> http://svn.python.org/projects/sandbox/trunk/decimal-c/_decimal.c
It sounds like some aspects of the API weren't thought
through very well
Georg Brandl wrote:
> As Nick said, a drop-in replacement in C isn't feasible
Yes, but that appears to be so only because of some
unfortunate features of the Python version's API.
Seems to me it would be better to undergo a little
pain now and get a well-designed C-friendly API.
--
Greg
__
Nick Coghlan wrote:
> What features do you find particularly unfortunate?
Whichever ones are making people think that implementing
it in C is infeasible.
> Just because
> something isn't particularly amenable to implementation in C, doesn't
> make it a bad API for a Python library
No, but for
zooko wrote:
> 1. You can't conveniently install eggs into a non-system directory,
> such as ~/my-python-stuff.
>
> 2. If you allow even a single egg to be installed into your
> PYTHONPATH, it will change the semantics of your PYTHONPATH.
I discovered another annoyance with eggs the other
zooko wrote:
>
> We determined
> that if you install the egg (with easy_install or with a
> setuptools-powered ./setup.py install) in unzipped form then the source
> file names get rewritten so that your stack traces come with source lines.
That wouldn't have helped me with my problem, bec
Phillip J. Eby wrote:
> Are you using Python 2.5? As of 2.5, the linecache module should
> correctly read the source line from the present location of the source
> file the module was loaded from, regardless of the file name specified
> in the traceback.
I think it was doing that, but I was tr
Guido van Rossum wrote:
> I don't think of EOFError as an environmental error... This is quite
> a different level of error than what EnvironmentError typically means
I think it depends. Any "expected" EOFErrors are going to be
caught by the surrounding code before propagating very far.
An *uncau
Brad Miller wrote:
> It was suggested that a broader discussion might be in order around the
> issue of iterators and how they are displayed in the command line
> interpreter.
Whatever is done, I don't think it would be a good idea
to make the str() of these things look *too* much like
a list. I
Guido van Rossum wrote:
> No, that's some kind of parsing error. EnvironmentError doesn't
> concern itself with the contents of files.
Often I raise EnvironmentErrors of my own to signal
parsing errors. This makes it easy to wrap everything
in a try-except that catches anything that's the user's
Guido van Rossum wrote:
> That's why I proposed <0, 1, ..., 9> for repr(range(10)).
My worry is that this will lead a newcomer into thinking
this is some kind of valid expression syntax.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Guido van Rossum wrote:
>> Often I raise EnvironmentErrors of my own to signal
>> parsing errors.
>
> Well, that's your problem. That's not what EnvironmentErrors are for.
But it seems like it's what it *should* be for.
I'd be happy to use some other standard exception
type if one existed at
Guido van Rossum wrote:
> You are unique in demanding this.
Really? Nobody else wants a convenient way to
distinguish program bugs from exceptions caused
by external factors?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
Guido van Rossum wrote:
> You are unique in demanding this.
I'm not asking for anything to be changed (I've
already agreed that EOFError can stay the way it
is), just pointing out what I think is a legitimate
use for custom EnvironmentError subclasses.
--
Greg
__
Brad Miller wrote:
>
I wouldn't include the word "object" in any of these.
Everything in Python is an object, so it's just
space-wasting noise.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
Antoine Pitrou wrote:
> Why do you want to derive program bugs from EnvironmentError ? Usually I
> derive
> them from ValueError, RuntimeError or simply Exception.
I'm *not* talking about program bugs, I'm talking about
exceptions due to something the user did wrong.
I like to be able to do thi
Michael Foord wrote:
> It seems to be more common in the 'Python world' to refer to indexing
> than subscription
Especially since the subscript isn't actually written
as a subscript, unless you have a particulary fancy
code editor...
--
Greg
___
Pytho
Nick Coghlan wrote:
> Being indexable is subtly different from being subscriptable - the
> former has stronger connotations of numeric indices and sequence-like
> behaviour (particularly since the introduction of operator.index), while
> the latter merely states that the container provides some
Steven wrote:
It might help if you explain what sort of actual things that the user does
wrong that you are talking about.
Usually it's some kind of parsing error. Or it might be a
network connection getting closed unexpectedly.
Essentially it's anything due to factors outside the
program's co
Steven Bethard wrote:
I'm not a big fan of the sequence-or-callable argument. Why not just
make it a callable argument, and supply a utility function
Or have two different keyword arguments, one for a sequence
and one for a callable.
--
Greg
___
Pyth
Martin v. Löwis wrote:
Ok. Jesus, can you please send me your SSH key?
Nice to see that Heaven is security conscious and
accepting encrypted prayer nowadays. :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
[EMAIL PROTECTED] wrote:
Guido> Have we documented the alternatives well enough?
I suppose we could document explicitly how to use mkstemp() in place of
mktemp(), but the difference in return value is fairly modest:
I'd like to see a variation of mkstemp() that returns
a file object inste
Guido van Rossum wrote:
IMO mkstemp() is a major pain because you have to use raw file
descriptors on the return value. I'd much rather recommend
[Named]TemporaryFile which return streams.
The problem with NamedTemporaryFile is that it deletes
the file as soon as you close it, which makes the
n
[EMAIL PROTECTED] wrote:
I'm not disagreeing with you, but it seems odd that os.fdopen doesn't simply
obey the mode of the file descriptor it receives as its argument
I'm not even sure if it's possible to find out the mode
that a file descriptor was opened with -- is it?
Certainly there's no w
1501 - 1600 of 2443 matches
Mail list logo
