> >>> import pdb
> >>> pdb.x = "Darn writeable module dictionaries"
> >>> from pdb import x
> >>> x
> >>>'Darn writeable module dictionaries'
> If Python really does behave that way, that bug should be fixed
> immediately.
The fact that the attributes of Python modules, like those of classes (a
Paul Rubin wrote:
Nick Coghlan <[EMAIL PROTECTED]> writes:
Until this code:
.>>> import pdb
.>>> pdb.True = 0
.>>> pdb.x = "Darn writeable module dictionaries"
.>>> from pdb import True
.>>> True
0
.>>> from pdb import x
.>>> x
'Darn writeable module dictionaries'
If Python really does behave that
Paul Rubin wrote:
Nick Coghlan <[EMAIL PROTECTED]> writes:
Until this code:
.>>> import pdb
.>>> pdb.True = 0
.>>> pdb.x = "Darn writeable module dictionaries"
.>>> from pdb import True
.>>> True
0
.>>> from pdb import x
.>>> x
'Darn writeable module dictionaries'
If Python really does behave that
Steve Holden wrote:
# Pre 2.2.1 compat.
try: True, False
except NameError: True = 1==1; False = 1==0
I believe this should work for all versions up to 2.4, and would also
work with a 2.5 that made True and False constants. But if anyone can
prove me wrong it would be you ... :-)
Seems like it mig
Steve Holden wrote:
Interestingly the same error occurs even when attempting sideways access:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import __builtin__
>>> __builtin__.None = "Rhubarb
Peter Otten wrote:
Fredrik Lundh wrote:
Steve Holden wrote:
It was unfortunate that so many people chose to use that for
compatibility, when if they'd used the same code that the win32all
extensions did they could have retained backward compatibility even
across a change to constants:
try:
Tru
Fredrik Lundh wrote:
Steve Holden wrote:
It was unfortunate that so many people chose to use that for compatibility, when if they'd used
the same code that the win32all extensions did they could have retained backward compatibility
even across a change to constants:
try:
True
except Attribut
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Until this code:
>
> .>>> import pdb
> .>>> pdb.True = 0
> .>>> pdb.x = "Darn writeable module dictionaries"
> .>>> from pdb import True
> .>>> True
> 0
> .>>> from pdb import x
> .>>> x
> 'Darn writeable module dictionaries'
If Python really does behave
Raymond Hettinger wrote:
Dan Bishop wrote:
Out of pure curiousity,
Why wasn't 'While True' optimized also?
Probably has something to do with "True" and "False" not being
constants.
[Nick Coghlan]
Yup. Even 'None' only just became a constant in 2.4.
I don't know if 'True' and 'False' are in line f
Fredrik Lundh wrote:
> Steve Holden wrote:
>
>> It was unfortunate that so many people chose to use that for
>> compatibility, when if they'd used the same code that the win32all
>> extensions did they could have retained backward compatibility even
>> across a change to constants:
>>
>> try:
>>
Steve Holden wrote:
> It was unfortunate that so many people chose to use that for compatibility,
> when if they'd used
> the same code that the win32all extensions did they could have retained
> backward compatibility
> even across a change to constants:
>
> try:
> True
> except Attribute
Paul Rubin wrote:
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
It is unlike to before Py3.0. Making them constants would break the
reams of compatability code: True, False = (1==1), (1!=1).
I don't see why that particular statement needs to fail. The
interpreter could permit assigning True=Tr
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> It is unlike to before Py3.0. Making them constants would break the
> reams of compatability code: True, False = (1==1), (1!=1).
I don't see why that particular statement needs to fail. The
interpreter could permit assigning True=True or False=Fa
> Dan Bishop wrote:
> >>Out of pure curiousity,
> >>Why wasn't 'While True' optimized also?
> >
> >
> > Probably has something to do with "True" and "False" not being
> > constants.
[Nick Coghlan]
> Yup. Even 'None' only just became a constant in 2.4.
>
> I don't know if 'True' and 'False' are in
Dan Bishop wrote:
Out of pure curiousity,
Why wasn't 'While True' optimized also?
Probably has something to do with "True" and "False" not being
constants.
Yup. Even 'None' only just became a constant in 2.4.
I don't know if 'True' and 'False' are in line for similar treatment (there are
obvious
Timothy Fitz wrote:
> [ http://www.python.org/moin/PythonSpeed ]
> "Starting with Py2.3, the interpreter optimizes 'while 1' to just a
> single jump. In contrast "while True" takes several more steps. While
> the latter is preferred for clarity, time-critical code should use
the
> first form."
>
>
[ http://www.python.org/moin/PythonSpeed ]
"Starting with Py2.3, the interpreter optimizes 'while 1' to just a
single jump. In contrast "while True" takes several more steps. While
the latter is preferred for clarity, time-critical code should use the
first form."
Out of pure curiousity,
Why wasn'
17 matches
Mail list logo