On Thu, 07 Feb 2008 11:48:08 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]>
wrote:
> Mike Meyer writes:
> > On the other hand, if setup.py made setting up the symlinks easy,
> > maybe I'd change my mind.
> I think this should be a separate tool, but either way I'd not object
> to making it easy
Facundo Batista wrote:
> When the process is issued as a Service, it don't even HAS
> stdin/stdout (not that is redirected to NUL). It don't even exist.
GUI apps don't have standard streams stdin, stdout and stderr, too. The
variables are defined when the code is compiled but during runtime the
st
2008/2/8, Daniel Stutzbach <[EMAIL PROTECTED]>:
> Picture command-line usage of python. You're sitting at your prompt, and
> you run a python script. It pops up a *new* window and you have to interact
> with that. Not a great user experience. Also, piping data to or from the
> script is imposs
On Wed, 06 Feb 2008 21:09:11 +1000 Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Meyer wrote:
> > On Wed, 06 Feb 2008 01:01:05 +1000 Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> While I'm +1 on the idea of making altinstall the default for setup.py
> >> and the Windows installer (forcing the admi
Daniel Stutzbach wrote:
> Hmmm. So maybe what's needed is a *third* kind of exe that
> gets launched when you double-click a .py file, that keeps
> its console open after the script finishes?
>
> Picture command-line usage of python. You're sitting at your prompt,
> and you run a pyt
Phillip J. Eby wrote:
> Hell, I'm not sure Windows even
> has a way to *tell* whether your app was launched from the command line
> or otherwise.
It wouldn't have to, if the .py extension were bound to
a different executable from the standard command line
interpreter, in the same way that .pyw i
I recommend dropping the dict.copy() method from Py3.0.
* We can already write: newd = copy.copy(d).
* We can also write: newd = dict(d)
* Both of those approaches also work for most other containers.
* The collections.Mapping ABC does not support copy().
* copy() is not a universal feature o
Mike Meyer writes:
> On Thu, 07 Feb 2008 11:48:08 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]>
> wrote:
> > I think this should be a separate tool, but either way I'd not object
> > to making it easy to do, as long as it was not default.
>
> And this is the real issue with your approach
On Feb 8, 2008 4:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I recommend dropping the dict.copy() method from Py3.0.
>
> * We can already write: newd = copy.copy(d).
> * We can also write: newd = dict(d)
> * Both of those approaches also work for most other containers.
> * The collec
Greg Ewing wrote:
> Daniel Stutzbach wrote:
>> Hmmm. So maybe what's needed is a *third* kind of exe that
>> gets launched when you double-click a .py file, that keeps
>> its console open after the script finishes?
>>
>> Picture command-line usage of python. You're sitting at your prom
I would need to think more about this. I'm tempted not to do this, and
let these ABCs denote the *explicit* presence of __contains__ and
__iter__, respectively. Something that's iterable but doesn't
implement __contains__ supports the 'in' operator very inefficiently
(through linear search) which w
I'm wondering if collections.Iterable should inherit from
collections.Container"?
In Python, anything that supports __iter__ automatically supports tests using
the "in" operator:
class A:
def __iter__(self):
for i in (1,2,3):
yield i
>>> 2 in A()
True
Guido van Rossum wrote:
> I would need to think more about this. I'm tempted not to do this, and
> let these ABCs denote the *explicit* presence of __contains__ and
> __iter__, respectively. Something that's iterable but doesn't
> implement __contains__ supports the 'in' operator very inefficiently
On Feb 8, 2008, at 7:51 PM, Raymond Hettinger wrote:
> I recommend dropping the dict.copy() method from Py3.0.
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
U
On Feb 5, 2008 10:24 PM, Mike Meyer <[EMAIL PROTECTED]> wrote:
> Sure, there are *lots* of ways the user can screw up the system as
> root. Doing a default python install from source is *not* one of them,
> no matter what it does with those symlinks. If you know of a system
> where things are other
[Nick]
> does anyone else think a 'key' parameter on any() and all()
> would be useful?
Not really. The key= function is useful whenever you need to
keep the original value around for some reason (i.e. sorting
it or getting the min/max value). But with any() and all()
you don't keep anything.
Guido van Rossum wrote:
> I would need to think more about this. I'm tempted not to do this, and
> let these ABCs denote the *explicit* presence of __contains__ and
> __iter__, respectively. Something that's iterable but doesn't
> implement __contains__ supports the 'in' operator very inefficiently
Neil Toronto wrote:
> Guido van Rossum wrote:
>> I would need to think more about this. I'm tempted not to do this, and
>> let these ABCs denote the *explicit* presence of __contains__ and
>> __iter__, respectively. Something that's iterable but doesn't
>> implement __contains__ supports the 'in' o
18 matches
Mail list logo
