On 5/18/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> > Operators) by Greg Ewing.
> >
> > It is time to reject it due to lack of interest, or revive it!
>
> Didn't you post something about this a short
Chris Monson wrote:
> So / 4 2 = 2 4 / ?
It would be unusual, but there's nothing to prevent /
from being defined that way in the postfix version of
the language.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman
Guido van Rossum wrote:
> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> Operators) by Greg Ewing.
>
> It is time to reject it due to lack of interest, or revive it!
Didn't you post something about this a short time ago,
suggesting you were in favour of it?
If you need an
So / 4 2 = 2 4 / ? I beg to differ :-). At any rate,
- C
On 5/18/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Chris Monson wrote:
> > Ignoring for a moment that prefix != reverse(postfix), that is
>
> It is if you don't insist on putting silly
> parentheses all over the place. (IOW, "prefix
Chris Monson wrote:
> Ignoring for a moment that prefix != reverse(postfix), that is
It is if you don't insist on putting silly
parentheses all over the place. (IOW, "prefix"
is not synonymous with "Lisp".)
--
Greg
___
Python-3000 mailing list
Pytho
Guido van Rossum wrote:
> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> Operators) by Greg Ewing. I am of two minds of this -- on the one
> hand, it's been a long time without any working code or anything. OTOH
> it might be quite useful to e.g. numpy folks.
This kind of f
> I wasn't thinking of this from a security POV -- more from the
> perspective of trying to understand roughly what a module does.
> Looking at the imports is often a good place to start.
In the case of open(), this may be a false benefit. Too many other calls
(logging, shelve, etc) can open file
Baptiste Carvello schrieb:
> Guido van Rossum a écrit :
>> Do people think it would be too radical if the built-in open()
>> function was removed altogether, requiring all code that opens files
>> to import the io module first? This would make it easier to identify
>> modules that engage in I/O.
>>
On 5/18/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Guido van Rossum a écrit :
> > Do people think it would be too radical if the built-in open()
> > function was removed altogether, requiring all code that opens files
> > to import the io module first? This would make it easier to identify
Guido van Rossum a écrit :
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
>
-1
Will someone think of the i
While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
Operators) by Greg Ewing. I am of two minds of this -- on the one
hand, it's been a long time without any working code or anything. OTOH
it might be quite useful to e.g. numpy folks.
It is time to reject it due to lack of interes
On 5/17/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
+1
T
Guido van Rossum wrote:
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
[and later]
> I guess a refinement of
On 5/18/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Do people think it would be too radical if the built-in open()
> > function was removed altogether, requiring all code that opens files
> > to import the io module first? This would make it easier to identify
> > mod
Guido van Rossum wrote:
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
I must be dense, because I don't see
Georg Brandl wrote:
> Ron Adam schrieb:
>> Guido van Rossum wrote:
>>> That would be great! This will automatically turn \u1234 into 6
>>> characters, right?
>> I'm not exactly clear when the '\u' characters get converted. There
>> isn't any conversion done in tokanize.c that I can see. It's
> Do people think it would be too radical if the built-in open()
> function was removed altogether, requiring all code that opens files
> to import the io module first? This would make it easier to identify
> modules that engage in I/O.
+1.
Presumably you can still write to the standard input, ou
On 5/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > is it generally agreed that the
> > Unicode character classes listed in the PEP are the ones we want to
> > include in identifiers? My preference is to be conservative in terms of
> > what's allowed.
> John Nagle suggested to consider UT
18 matches
Mail list logo
