[EMAIL PROTECTED] wrote:
> I think there's room
> for debate on whether specific list methods that currently return None should
> instead return the list, although I would definitely consult the archives
> before entering that fray.
Indeed. It's been discussed many times before.
It was a delibera
Fabio Zadrozny wrote:
> frame = findFrame(thread_id, frame_id)
> exec '%s=%s' % (attr, expression) in frame.f_globals, frame.f_locals
The locals of a function are actually stored in an array.
When you access them as a dict using locals(), all you
get is a dict containing a copy of their current v
Fabio Zadrozny wrote:
> Would it be ok to add a feature request for that?
It seems a reasonable thing to suggest. Instead of
a copy, locals() could return a mapping object that
is a view of the underlying array. The only limitation
then would be that you couldn't add new keys.
> I initially thou
Martin v. Löwis wrote:
> It is the implementation of
>
> foo **= bar
>
> (and that's its only use), so it ought to be binary.
Maybe it's so that a type can plug the same implementation
into both nb_pow and nb_inplace_pow. Although the same
effect could be achieved by just leaving nb_inplace_pow
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
>> Might we want to add an in-place version of the 3-arg
>> pow() function one day?
>
> What could the syntax for that be?
It wouldn't be a syntax, just a function, e.g.
ipow(x, n, 10)
> Also, it would break e
by a dict?
In my experience, the amount of code which truly needs
to use getattr is extremely small.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand |
Georg Brandl wrote:
> For the speed argument -- there were quite a few proposals to take builtins as
> constants under certain conditions, in which case getattr() usage could be
> optimized just as well as new syntax.
Even more aggressively, the compiler could recognise it
and make a direct call
Ben North wrote:
> Generally gently positive, with the exception of Anthony Baxter's
> "-1", which I understand to be motivated by concerns about newcomers to
> the syntax
The more I think about it, the more I'm leaning
towards -1 as well. Adding syntax is a very big
step, and it needs a very sol
Richard Tew wrote:
> The ideal mechanism at the high level would be expanding asyncore into
> a "one-stop shop". Where all these things can be passed into it and
> it can do the work to notify of events on the objects in a standard way.
+1. This sounds like an excellent idea. It's downright
sill
Talin wrote:
> What I am getting at is that rather that doing heroic efforts to add
> stackless-ness to the current Python code base without changing it,
> instead define a migration path which allows Python to eventually
> acquire the characteristics of a stackless implementation.
I think you
Josiah Carlson wrote:
> def intern(st):
> ...
>
> If I remember the implementation of intern correctly, that's more or
> less what happens under the covers.
That doesn't quite give you everything that real interning
does, though. The string comparison method knows when both
strings are intern
Brett Cannon wrote:
> On 2/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > 2) {BinOp,AugAssign,BoolOp,etc}.op
>
> I can't think of a reason, off the top of my head, why they can't be
> singletons.
Why not just use interned strings?
--
Greg
___
Pyth
Martin v. Löwis wrote:
> Greg Ewing schrieb:
> > the end result would be too
> > convoluted for ordinary people to understand and maintain.
>
> That very much depends on what the end result would be.
True. What I should have said is that Guido *believes*
the outcome wo
Martin v. Löwis wrote:
> Apparently, people favor hasattr over catching
> AttributeError. I'm not sure why this is - I would probably
> rewrite them all to deal with AttributeError if I use the new
> syntax in the first place.
Actually, I prefer using getattr with a default value over
either of t
Martin v. Löwis wrote:
> BTW, which of these would be correct
My thoughts would be
(a).[b] Okay
(a.)[b] Not okay
a.[(b)] Okay
a.([b]) Not okay
a . [ b ]Okay
> and what is the semantics of
>
> a.[42]
The same as getattr(a,
Steve Holden wrote:
> I know that there's work in progress (and indeed
> almost complete) to put Stackless into 2.5
It might be less confusing to rename the current version of
Stackless to "microthreads" or something, since it's not
really stackless at all.
--
Greg
__
Martin v. Löwis wrote:
> OTOH, in an application that needs unique strings, you normally know
> what the scope is (i.e. where the strings come from, and when they
> aren't used anymore).
That's true -- if you know that all relevant strings have
been interned using the appropriate method, you can
Martin v. Löwis wrote:
> OTOH, you can't write
>
>x + = 2
>
> or
>
>a = 2 * * 4
Although oddly enough you *can* write
a[. . .]
I guess whoever added the ellipsis couldn't be bothered
defining a new token for it.
It's something of an arbitrary choice, but to me it just
seems that
Guido van Rossum wrote:
> it means we'll be catching AttributeError
> instead of using "look before you leap", which if fine with me.
A thought on this: to avoid masking bugs, when catching
AttributeError you really need to isolate the getattr
operation so that it's on a line by itself, with no
su
Ron Adam wrote:
> Would it be possible for attrview to be a property?
To avoid polluting the namespace, it would need to have
a double-underscore name, and then it would be ugly to
use.
Unless we had a function to call it for you... oh,
wait, we've already got one -- it's called getattr. :-)
--
Josiah Carlson wrote:
> In a recent
> source checkout of the trunk Lib, there are 100+ uses of setattr, 400+
> uses of getattr ... and a trivial number of delattr calls.
That's out of about 250,000 lines, or 0.2%.
Not a huge proportion, I would have thought.
--
Greg
__
Mike Klaas wrote:
> As a comparison, enumerate (that I would have believed was much more
> frequent a priori), is used 67 times, and zip/izip 165 times.
By that argument, we should be considering a special syntax
for zip and izip before getattr.
--
Greg
__
[EMAIL PROTECTED] wrote:
> Given that you have more uses of zip/izip maybe we should be discussion
> syntactic support for that instead. ;-)
I actually came up with an idea for that, slightly too
late to get considered in the original lockstep-iteration
debate:
for (x in seq1, y in seq2):
[EMAIL PROTECTED] wrote:
> I have no problem with other, competing event-driven mechanisms being
> developed;
The need for different event-driven mechanisms to compete
with each other is the very problem that needs to be
addressed.
If Twisted is designed so that it absolutely *has* to
use its ow
Brett Cannon wrote:
> Because the AST code at the C level represent the 'op' value as
> basically an enumeration value, not a string. So creating an object
> is somewhat easier then trying to do the conversion to an interned
> string.
It would seem even easier (and a lot faster) to use an
array
Guido van Rossum wrote:
> But if we ever turn it into a single token (which we just may for
> Py3k) don't complain if your code breaks.
I won't. I always treat it as a single token
anyway, unless I'm entering an obfuscated
python competition. :-)
--
Greg
_
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
> > The string comparison method knows when both
> > strings are interned
>
> No, it doesn't - see stringobject.c:string_richcompare.
Well, I'm surprised and confused.
It's certainly possible to tell v
Another thing I don't like about this default argument
proposal is that using it in any non-trivial way would
tend to put implementation details of the function
up in the header, which should be reserved for info
describing the calling signature.
The following example from the PEP is an extreme
in
Jean-Paul Calderone wrote:
> Greg, productive discussion is not furthered by the
> unsupported statement of one position or another.
Sorry, I'll expand on that a bit. The "problem" I
was referring to is the turf wars between all the
event-driven frameworks that all want to do things
their own way
[EMAIL PROTECTED] wrote:
> On 08:52 pm, [EMAIL PROTECTED] wrote:
>
> >When I last looked at twisted (that is several years ago), there were
> >several reactors - win32reactor, wxreactor, maybe even more.
>
> Only the very top-most level decides which reactor the application will use.
This is a
[EMAIL PROTECTED] wrote:
> sounded like
> monkeypatching the socket and asyncore modules to provide asynchronous
> file I/O based on the platform-specific IOCP API for Windows.
I don't think anyone's suggesting that any long-term
solution to all this would involve monkeypatching.
--
Greg
__
Martin v. Löwis wrote:
> switch(o) {
> case And:
> Py_INCREF(And_singleton);
> return And_singleton;
> case Or:
> Py_INCREF(Or_singleton);
> return Or_singleton;
Steve Holden wrote:
> A further data point is that modern machines seem to give timing
> variabilities due to CPU temperature variations even if you always eat
> exactly the same thing.
Oh, great. Now we're going to have to run our
benchmarks in a temperature-controlled oven...
--
Greg
___
Martin v. Löwis wrote:
> I think this would violate the policy that a mutating function shouldn't
> give the object being modified as the result
Well, it's a necessary violation, given the way the inplace
methods work. And it doesn't *necessarily* return the same
value, it might return a new obje
Josiah Carlson wrote:
> Assuming that dictionaries and the hash algorithm for strings is not
> hopelessly broken, I believe that one discovers quite quickly when two
> strings are not equal.
You're probably right, since if there's a hash collision,
the colliding strings probably differ in the fir
Larry Hastings wrote:
> If I understand your question correctly, you're saying "why doesn't
> string comparison take advantage of interned strings?"
No, I understand that it takes advantage of it when the
strings are equal. I was wondering about the case where
they're not equal. But as has been
Steve Holden wrote:
> If the borrowed code takes a reactor parameter then presumably the
> top-level code can pass the appropriate reactor type in.
Since there should only be one reactor at a time in
any given application, it shouldn't have to be passed
in -- it could be held in a global variabl
Thomas Wouters wrote:
> If the choice for
> reactor was made somewhere deep inside the library, how does it know to
> use the GTK reactor?
In my ideal world, there wouldn't actually be a gtk
reactor -- there would only be a Linux reactor, a
MacOSX reactor, a Windows reactor, etc. Things like
py
Phillip J. Eby wrote:
> peak.events, for example, lets you have multiple event loops
> running in the same or different threads.
Different threads is okay if you're willing to use threads,
but you might not. The reason you're using an event loop
may well be precisely so that you *don't* have to u
Thomas Wouters wrote:
> If all (or all-but-one) of them have a 'run one iteration' method, you
> can call that from the 'main' mainloop.
But without some way of blocking until an event arrives
for *either* loop, you have to resort to some kind of
busy polling, which is not elegant.
--
Greg
Thomas Wouters wrote:
> *I* don't like the idea of something in the Python installation
> deciding which reactor to use.
I wouldn't mind if some way were provided of changing
the reactor if you want. I'd just like to see a long
term goal of making it unnecessary as far as possible.
> In any ca
Martin v. Löwis wrote:
> That is insufficient. The gtk main loop has more input
> sources than just the connection to X:
> - timers
> - idle handlers
> - child handlers
> - additional file descriptors
> - a generalzed 'event source'
When gtk is not the central event mechanism, there's no
need to
Oleg Broytmann wrote:
> > Given that they say "a camel is a horse designed by a committee"
>
> BTW, camels are very suited for their environments...
The quote is actually "a camel is a *racehorse* designed by a committee".
Camels are very good at surviving in the desert, but not so good at
winni
Anthony Baxter wrote:
> Unless the fans are perfectly balanced, small changes in gravity are
> going to affect the rate at which they spin. So I guess the
> position of the moon will affect it :-)
A standard gravitational field could also be important
to eliminate relativistic effects.
So we n
Nick Maclaren wrote:
> Threading
> -
>
> An I/O operation passes a buffer, length, file and action and receives a
> token back.
You seem to be using the word "threading" in a completely
different way than usual here, which may be causing some
confusion.
--
Greg
_
Josiah Carlson wrote:
> Somewhere in the back of my mind something is telling me - if you can
> get a tuple with attributes based on __slots__, you just duplicate the
> references as both an attribute AND in the standard tuple PyObject*
> array,
It should be possible to start with a tuple subclas
Neal Becker wrote:
> The fact that other numeric
> types act this way leaves a reasonable expectation that bool will.
But bool isn't really a numeric type in the same way
that the others are. It's only a subtype of int for
historical reasons. If it had been a part of Python
from the beginning, it
Martin v. Löwis wrote:
> One idiom that people use a lot is foo[b], where
> b is a boolean.
Could that be addressed using the new __index__ mechanism?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Guido van Rossum wrote:
> How would this change be helpful? I'm utterly mystified by these
> suggestions that bool would be more useful if it didn't behave like an
> int in arithmetic.
I think there's a desire by some people to get rid of
unnecessary conceptual baggage left over for historical
re
Thomas Wouters wrote:
> One thing in particular I wonder about
> is the warning about mixing tabs and spaces. Should it be in category 2)
> (on by default) or 3) (still off by default, but part of -Wpy3k)?
For my part, it wouldn't bother me at all if you
turn it on by default any time you want.
Stephen J. Turnbull wrote:
> RKN = reverse Knuth numbering?
No, for RKN you'd have to start with 3141.5926... (an
infinite number of digits following) and drop one off
the end each time... although it would take rather a
long time to get to the final release then. :-(
--
Greg
___
Phillip J. Eby wrote:
> At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
>
> > NO_END_OF_RECORD = ParserError("Cannot find end of record")
>
> Then don't do that, as it's bad style for Python 3.x. ;-)
I don't like that answer. I can think of legitimate
reasons for wanting to pre-create exceptions
Is this intentional? I would have expected the
// operator to always give an integer result.
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 7.0 // 2
3.0
--
Greg
__
[EMAIL PROTECTED] wrote:
> Or modify __new__ on your particular heavily-optimized
> exception to have a free-list,
Doing that in Python is likely to have as much overhead as
creating an instance.
The simple and obvious optimisation is to pre-create the
instance, but we're proposing to make the o
Adam Olsen wrote:
> It sounds like we should always copy the exception given to raise,
I don't like that either, for all the reasons that
make it infeasible to copy an arbitrary object in a
general way.
--
Greg
___
Python-Dev mailing list
Python-Dev@p
believe calling copy.copy() would be sufficient.
I never use that, because I have no confidence that
it would DWIM. I'd be unhappy if the system started
relying on it anywhere fundamental.
--
Greg Ewing, Computer Science Dept, +--+
University of
l create a new exception instance
and then make a copy of it", unless this can be optimised
away somehow, and it's not necessarily obvious that the
refcount == 1 trick will work (it depends on the exact
details of how the references flow through the exception
raising machinery).
--
Greg Ewin
define classes, since creating one involves setting
up a dict, etc. And if you use __slots__ you end up with
objects of different sizes, which isn't free-list-friendly.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, |
James Y Knight wrote:
> It seems to me that a stack trace should always be attached to an
> exception object at creation time
Um. Yes. Well, that's certainly an innovative solution...
> The traceback won't necessarily be *useful*,
Almost completely use*less*, I would have thought.
The traceba
Michael Foord wrote:
> With the
> proposed changes, modules that do this would *continue* to work, surely
> ?
Probably, but it might mean they were no longer thread
safe. An exception caught and raised in one thread would
be vulnerable to having its traceback clobbered by
another thread raising
[EMAIL PROTECTED] wrote:
> Perhaps the use-cases for attaching the traceback object
> to the exception would be better satisfied by simply having
> sys.exc_info() return an object with methods like Failure?
> I can't think of a good name for the new object type,
Maybe we could call it a 'catch'
Guido van Rossum wrote:
> You start with a traceback object pointing to the current frame
> object (traceback objects are distinct from frame objects,
Just out of curiosity, is it really necessary to have
a distinct traceback object? Couldn't the traceback
just be made of dead frame objects linked
Brett Cannon wrote:
> except Exception as exc with tb:
> ...
I was thinking of that too, plus a matching
raise Exception with tb
The only use for a 'catch' object would then be for
returning from sys.exc_info(), and I'm not sure it's
worth creating one just for that rather than using
a
Nick Maclaren wrote:
> The instance contains all of the information about the details, such
> as the exact operation, the values and the context (including the
> traceback). It CAN'T be an object, because it is not 'assignable'
> (i.e. a value) - it is inherently bound to its context. You can
>
[EMAIL PROTECTED] wrote:
> Why not just allow both exception classes and exception instances to be
> raised, and only instantiate-at-catch in the case of a raise of a class
> and a catch with an "as" clause?
Because that doesn't solve the problem of pre-instantiated
exceptions. What I'm proposing
Collin Winter wrote:
> Do those who oppose __traceback__ also oppose __cause__ and
> __context__?
They would seem to have the same problems. Whatever
solution is adopted for the traceback should probably
be applied to them as well, perhaps by generalising
the traceback into an "exception context"
Michael Foord wrote:
> Greg Ewing wrote:
>
> > An exception caught and raised in one thread would
> > be vulnerable to having its traceback clobbered by
> > another thread raising the same instance.
>
> Right - but that would still be *no worse* than the current situ
Guido van Rossum wrote:
> I'm afraid we're back at square zero; perhaps we should keep the
> existing (type, value, traceback) API
Whatever happens, we should be able to get that down
to at most two things: (exception, context) where
exception is either a class or an instance, and
context include
Michael Foord wrote:
> Um... except that the new attributes *obviously* means that the
> traceback information is obviously not going to work where you reuse a
> single instance and to expect otherwise seems naive.
Yes, but this means that the __traceback__ attribute
couldn't be *the* way of ha
Guido van Rossum wrote:
> But what's the advantage of not instantiating the exception if we
> instantiate the context instead?
Probably not much. But most control-flow-exception
catching will just be 'except E:' in which case
you don't need to instantiate anything. (Assuming
we get rid of traceba
Guido van Rossum wrote:
> Perhaps we could allow reraising whenever the
> existing traceback chain contains a reference to a frame that is an
> ancestor of (or equal to) the newly raising frame?
This is starting to sound terribly hairy.
Would it help if a different syntax were used for
raising an
Andrew Dalke wrote:
> def __init__(self, prec=None, rounding=None,
> traps=None, flags=None,
> _rounding_decision=None,
> Emin=None, Emax=None,
> capitals=None, _clamp=0,
> _ignored_flags=None):
> ..
Tim Lesher wrote:
> FWIW, all of the "standard" Windows functions from the Microsoft CRT
> (_splitpath) to the Shell API (PathRemoveExtension) to the CLR
> (System.IO.Path.*) believe that ".cshrc" is the extension of the
> filename ".cshrc".
>
> I'm not sure if that's an argument for or against th
Nilton Volpato wrote:
> If you open many member files concurrently how does file cache will
> work? Or how many seeks you will have to do if you read from one
> member file and from other alternatingly?
If the OS file system cache is doing its job properly,
I don't think the seeking should be a p
Bill Janssen wrote:
> If you really need a name other than "timeout" (which seems fine to
> me), how about "waiting-with-mild-trepidation-timeout"?
Something like "response timeout" might be more descriptive.
--
Greg
___
Python-Dev mailing list
Python-
Martin v. Löwis wrote:
> splitext(path)
> Split the pathname path into a pair (root, ext) such that root + ext ==
> path, and ext is empty or begins with a period and contains at most one
> period.
Actually, that spec could be satisfied by a function
that *always* returned an empty string for e
Collin Winter wrote:
> Treat dates as if they have a time-part of midnight. This is my preferred
> solution, and it is already what the datetime module does, for example,
> when subtracting two dates.
Does it really? Seems to me you can pick any time of day
to be the representative time and get t
Jon Ribbens wrote:
> So you're deciding that a 'date' is 'the entire of that day', except
> when you subtract two of them, when it suddenly means something else? ;-)
No, you're considering dates to be discrete entities,
like integers. You wouldn't use the same reasoning to
argue that the differen
Jon Ribbens wrote:
> What do you feel "next Tuesday plus 12 hours" means? ;-)
I would say it's meaningless. My feeling is that subtracting
two dates should give an integer number of days, and that is
all you should be allowed to add to a date.
--
Greg
Jon Ribbens wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>>We know that:
>>date(2006, 1, 1) *Includes* datetime(2006, 1, 1, 0, 0, 1)
>
> Oh dear. You've fallen at the first hurdle. We do not know that.
Translated into English, this is saying "The 1st of January
2006 includes the t
Miguel Lobo wrote:
> In fact I'm probably the person the
> patch will benefit least, because I have already run into the problem
> and know how to solve it.
For me, the personal benefit of getting a patch applied
would be so that I didn't have to keep re-applying it
to new versions of Python, an
Martin v. Löwis wrote:
> I couldn't tell off-hand whether having
> extension modules in a package would even work
It's quite common for a third-party package to consist
of some Python code and some extension modules, with
the extension modules living inside the package
namespace. It works fine.
-
Michael Urman wrote:
> Who would rather see os.path.dropext(path)?
I'd like to see such a function, and also
maybe replaceext(path, new_ext). I often
end up coding things like these myself,
since indexing the result of splitext all
the time is rather ugly.
To round off the set, I suggest
pat
Facundo Batista wrote:
> are there processors that support "reentrant" interrupts?
The PDP11 had seven priority levels for interrupts.
When an interrupt was handled, interrupts with
priorities less than or equal to the current level
were blocked, but the handler could be interrupted
by a higher p
[EMAIL PROTECTED] wrote:
> Can you suggest any use-cases for thread termination which will *not*
> result in a completely broken and unpredictable heap after the thread
> has died?
Suppose you have a GUI and you want to launch a
long-running computation without blocking the
user interface. You
Mike Krell wrote:
> I want
> ".emacs" to be renamed to ".1.emacs", thus preserving the extensions.
> Under the new patch, the second file would be renamed to ".emacs.1",
> gratuitously breaking the extension preservation.
This argument presupposes that ".emacs" on its own
should be considered an e
Mike Krell wrote:
> copies of ".emacs" would be made as ".1.emacs",
> ".2.emacs", etc.
But that's not going to work for other extensionless
files that don't begin with a dot. The fact that it
happens to work for .emacs files and the like is
just a fluke due to Windows' ignorance of Unix
file namin
Anthony Baxter wrote:
> Python has major releases, and bugfix releases.
> At the moment, the major releases are of the form 2.x, and bugfix
> 2.x.y.
Yes, and from history so far there's no particular
semantics attached to first-digit transitions.
1.x -> 2.x was nothing to write home about, and
2
Mike Krell wrote:
> I said the name ".emacs" was used as an example. For that matter, the
> name "a.txt" was also used as an example. The use cases are real.
So does your application create any file names
that have a single dot at the beginning?
--
Greg
I've just discovered the hard way that NamedTemporaryFile
automatically deletes the file when you close it. That
doesn't seem very useful to me, since surely the reason
you're using NamedTemporaryFile instead of TemporaryFile
is that you want to do something else with it afterwards?
What's the rati
Damien Miller wrote:
> That annoyed me too, so I submitted a patch[1] that was recently
> committed.
That looks good. Seems to me it should really be the
default behaviour, but I suppose that would break
code that was relying on the automatic deletion.
--
Greg
___
Nick Maclaren wrote:
> Think of updating a complex object in a multi-file database, for
> example. Interrupting half-way through leaves the database in a
> mess, but blocking interrupts while (possibly remote) file updates
> complete is asking for a hang.
Currently, threads can't be interrupted
Nick Maclaren wrote:
> You don't always SEE the stuck process - sometimes
> the 'kill -9' causes the pid to become invisible to ps etc., and
> just occasionally it can continue to use CPU until the system is
> rebooted.
If that happens, there's a bug in the kernel. A process
killed with -9 shouldn
Michael Foord wrote:
> Are you going to try it ?
>
> Guido van Rossum wrote:
>
>>-- Forwarded message --
>>
>>may be there should be a virusAI that you set on the
>>internet.
Are you sure it hasn't already been tried? Maybe
all these viruses running around in the Windows
world a
Gregory P. Smith wrote:
> I prefer the default of "clean up after itself" as is to avoid leaving
> temporary file turds on systems caused by us lazy programmers.
Maybe instead of an option there should be a separate
function with a different name, such as NewUniqueFile.
For the use cases I have i
Alan Kennedy wrote:
> The standard mechanism in C for doing a non-blocking connect is to
> issue the connect call, and check the return value for a non-zero
> error code. If this error code is errno.EAGAIN (code 10035), then the
> call succeeded, but you should check back later for completion of t
Alan Kennedy wrote:
> def connect(address, **kwargs):
> [snip]
> if kwargs.has_key('timeout'):
> sock.settimeout(kwargs['timeout'])
> [snip]
A problem with interfaces like this is that it makes
it awkward to pass on a value that you received from
higher up.
An
Scott Dial wrote:
> Greg Ewing wrote:
>
>> Maybe instead of an option there should be a separate
>> function with a different name, such as NewUniqueFile.
>
> I'm in favor of adding such a function.
A tangential question -- why are TemporaryFile and
NamedTemporary
Georg Brandl wrote:
> The class/function distinction is not so clear in Python from the user's
> point of view since there is no different calling syntax.
There *is* a visible distinction, though --
you can subclass classes but not functions.
If these are uppercased because they wrap
classes, wh
Facundo Batista wrote:
> So, as a resume of the choices we still need to settle:
>
> a) Repeat the same functionality in 5 other libraries
> b) Write the function in socket.py, public
> c) Write the function in socket.py, non public
or
d) Put it in another module
Is it time for a so
1201 - 1300 of 2443 matches
Mail list logo
