[Python-Dev] Scour.com invite from Raja Rokkam

[Raja Rokkam]

Hey,

Did you hear about Scour? It is the next gen search engine with
Google/Yahoo/MSN results and user comments all on one page. Best of all we
get paid for using it by earning points with every search, comment and vote.
The points are redeemable for Visa gift cards! It's like earning credit card
or airline points just for searching! Hit the link below to join for free
and we will both get points! 

http://scour.com/invite/rajar/

I know you'll like it!

- Raja Rokkam

___
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

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Matt Giuca]

Has anyone had time to look at the patch for this issue? It got a lot of
support about a week ago, but nobody has replied since then, and the patch
still hasn't been assigned to anybody or given a priority.

I hope I've complied with all the patch submission procedures. Please let me
know if there is anything I can do to speed this along.

Also I'd be interested in hearing anyone's opinion on the "quote_from_bytes"
issue as raised in the previous email. I posted a suggested implementation
of a more restrictive quote_from_bytes in that email, but I haven't included
it in the patch yet.

Matt Giuca
___
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

[Python-Dev] [OT] Commit number

[Facundo Batista]

Congratulations to Andrew Kuchling for doing the commit # 2**16

Lover-of-round-numbers--ly yours,

-- 
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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

[Python-Dev] New to python, let me know if i should be posting somewhere else

[jamesz]

Hi,

I am new to Python, so this question that is probably blindingly obvious to
you all.
If I have 2 classes that references each other (a circular reference of some
sort) 
and both class are defined in the single file in the order shown. 

class Resume(db.Model):
file_data = db.BlobProperty()
candidate = db.ReferenceProperty(Candidate)

class Candidate(db.Model):
first_name = db.StringProperty()
last_name = db.StringProperty()
latest_resume = db.ReferenceProperty(Resume)

the Resume class does not know about the Candidate class as this 
module is imported, so it throws a error. Is there any way to get around
this problem?
 
-- 
View this message in context: 
http://www.nabble.com/New-to-python%2C-let-me-know-if-i-should-be-posting-somewhere-else-tp18830344p18830344.html
Sent from the Python - python-dev mailing list archive at Nabble.com.

___
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

Re: [Python-Dev] New to python, let me know if i should be posting somewhere else

[Steve Holden]

jamesz wrote:

Hi,

I am new to Python, so this question that is probably blindingly obvious to
you all.
If I have 2 classes that references each other (a circular reference of some
sort) 
and both class are defined in the single file in the order shown. 


class Resume(db.Model):
file_data = db.BlobProperty()
candidate = db.ReferenceProperty(Candidate)

class Candidate(db.Model):
first_name = db.StringProperty()
last_name = db.StringProperty()
latest_resume = db.ReferenceProperty(Resume)

the Resume class does not know about the Candidate class as this 
module is imported, so it throws a error. Is there any way to get around

this problem?
 

Jamesz:

This list (python-dev) is for the development *of* Python, not 
development *with* Python. If you ask your question on comp.lang.python 
([EMAIL PROTECTED]) you will almost certainly receive an answer.


regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
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

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

After the most recent flurry of discussion I've lost track of what's
the right thing to do. I also believe it was said it should wait until
2.7/3.0, so there's no hurry (in fact there's no way to check it -- we
don't have branches for those versions yet).

On Tue, Aug 5, 2008 at 5:47 AM, Matt Giuca <[EMAIL PROTECTED]> wrote:
> Has anyone had time to look at the patch for this issue? It got a lot of
> support about a week ago, but nobody has replied since then, and the patch
> still hasn't been assigned to anybody or given a priority.
>
> I hope I've complied with all the patch submission procedures. Please let me
> know if there is anything I can do to speed this along.
>
> Also I'd be interested in hearing anyone's opinion on the "quote_from_bytes"
> issue as raised in the previous email. I posted a suggested implementation
> of a more restrictive quote_from_bytes in that email, but I haven't included
> it in the patch yet.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] Py_CLEAR and assigning values

[Paul Pogonyshev]

Hi,

Sorry if this topic was discussed before, but I couldn't find.

Py_CLEAR documentation explains why it is better than Py_DECREF and
NULL assignment.  However, I don't understand why there is no similar
macro for the case you want to replace one object with another?

I.e. 'naive' way:

Py_DECREF (self->x);
/* This is prone to the same bug Py_CLEAR prevents. */
self->x = y;
Py_INCREF (self->x);

Py_CLEAR way:

Py_CLEAR (self->x);
/* But __del__ can now in principle trigger access to NULL. */
self->x = y;
Py_INCREF (self->x);

Way I'd think would be possible:

Py_ASSIGN (self->x, y)

where Py_ASSIGN is defined this way:

#define Py_ASSIGN(op, val)  \
do {\
PyObject *_py_tmp = (PyObject *)(op);   \
(op) = val; \
Py_XINCREF(op); \
Py_XDECREF(_py_tmp);\
} while (0)

Do I miss something obvious?  Or is there already a standard way to
do that which I overlooked?

Paul
___
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

[Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Leo Soto M.]

Hi Python developers!

First, a quick introduction: My name is Leonardo Soto, I'm a  GSoC
2008 student working under PSF and the Jython project, and a Jython
commiter since one month ago.

As part of what I did on this GSoC, I've improved Jython's __cmp__ a
bit. That made me go to look at CPython sources (v2.5.2) to read the
implementation of cmp(a,b).

Aside from what I've already fixed on Jython, I've found four
differences between Jython and CPython cmp(a, b):

(1). CPython's cmp() uses a.__cmp__(b) before rich-cmp methods if the
types of the two arguments are the same.

(2). When using rich-cmp methods, CPython first check if the second
type is a subtype of the first, and starts trying with the second
method instead of the first. [i.e, the process starts by b.__gt__(a)
instead of a.__lt__(b) if type(b) != type(a) and issubclass(b, a)]

(3). Similar to above, if the second argument to cmp(a, b) is a
old-style instance, and the first isn't, b.__cmp__(a) is used instead
of a.__cmp__(b).

(4). CPython tries coercion as part of the three way comparison. But
doesn't do it exactly as advertised on
: it does coercion
*after* trying a.__cmp__(b), while the docs says *before*. And it only
uses the coerced values if both values have the same tp_compare
function. I fail to see why, and this is not mentioned on the docs
either.

[The examples that show this behaviors are at the end of this mail.]

Now, my questions:

- Are (1), (2) and (3) intentional features?  Frankly, Jython being
different on (1) and (3) isn't a big deal, but I'd like to match
CPython as much as possible (and reasonable). Point (2) is a more
interesting, because it seems to follow what
 says for binary ops:

"Exception to the previous item: if the left operand is an instance of
a built-in type or a new-style class, and the right operand is an
instance of a proper subclass of that type or class and overrides the
base's __rop__() method, the right operand's __rop__() method is tried
before the left operand's __op__() method."

But I haven't found any documentation telling that it applies to
rich-cmp methods too. Interestingly, it *doesn't* apply to __cmp__ on
CPython 2.5.2.

BTW, PyPy also fails to follow CPython on points (2) and (3), so it is
not just me failing to found the appropriate docs ;-)

- What's the idea behind the current implemention of __cmp__ and
coercion, as described on (4)? I've to implement this feauture on
Jython, but checking that two Java instances have the same __cmp__
method is not that easy as in C. And more important: it could be
wrong, depending on what is the idea behind the current CPython
implementation.

Finally, here are the examples of the behaviors outlined at the start
of this mail.

(1):

>>> class A(object):
...   def __eq__(self, other): return True
...   def __cmp__(self, other): return 1
...
>>> cmp(A(), A())
1

(2):

>>> class A(object):
...  def __lt__(self, other): return True
...  def __gt__(self, other): return False
...  def __eq__(self, other): return False
...
>>> class B(A): pass
...
>>> cmp(A(), B())
1

(3):

>>> class A(object):
...def __cmp__(self, other): return 1
...
>>> class B:
...def __cmp__(self, other): return 1
...
>>> cmp(A(), B())
-1

(4):

>>> class A(object):
... def __coerce__(self, other): return 0, 0
... def __cmp__(self, other): return -1
...
>>> cmp(A(), A())
-1

Regards,
-- 
Leo Soto M.
http://blog.leosoto.com
___
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

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Guido van Rossum]

Given that in Python 3.0 __cmp__ is going away, I'm not sure how much
it all matters -- but if you care, as long as it's supported at all,
you might as well strive for the most compatibility with 2.5...

On Tue, Aug 5, 2008 at 1:43 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> Hi Python developers!
>
> First, a quick introduction: My name is Leonardo Soto, I'm a  GSoC
> 2008 student working under PSF and the Jython project, and a Jython
> commiter since one month ago.
>
> As part of what I did on this GSoC, I've improved Jython's __cmp__ a
> bit. That made me go to look at CPython sources (v2.5.2) to read the
> implementation of cmp(a,b).
>
> Aside from what I've already fixed on Jython, I've found four
> differences between Jython and CPython cmp(a, b):
>
> (1). CPython's cmp() uses a.__cmp__(b) before rich-cmp methods if the
> types of the two arguments are the same.
>
> (2). When using rich-cmp methods, CPython first check if the second
> type is a subtype of the first, and starts trying with the second
> method instead of the first. [i.e, the process starts by b.__gt__(a)
> instead of a.__lt__(b) if type(b) != type(a) and issubclass(b, a)]
>
> (3). Similar to above, if the second argument to cmp(a, b) is a
> old-style instance, and the first isn't, b.__cmp__(a) is used instead
> of a.__cmp__(b).
>
> (4). CPython tries coercion as part of the three way comparison. But
> doesn't do it exactly as advertised on
> : it does coercion
> *after* trying a.__cmp__(b), while the docs says *before*. And it only
> uses the coerced values if both values have the same tp_compare
> function. I fail to see why, and this is not mentioned on the docs
> either.
>
> [The examples that show this behaviors are at the end of this mail.]
>
> Now, my questions:
>
> - Are (1), (2) and (3) intentional features?  Frankly, Jython being
> different on (1) and (3) isn't a big deal, but I'd like to match
> CPython as much as possible (and reasonable). Point (2) is a more
> interesting, because it seems to follow what
>  says for binary ops:
>
> "Exception to the previous item: if the left operand is an instance of
> a built-in type or a new-style class, and the right operand is an
> instance of a proper subclass of that type or class and overrides the
> base's __rop__() method, the right operand's __rop__() method is tried
> before the left operand's __op__() method."
>
> But I haven't found any documentation telling that it applies to
> rich-cmp methods too. Interestingly, it *doesn't* apply to __cmp__ on
> CPython 2.5.2.
>
> BTW, PyPy also fails to follow CPython on points (2) and (3), so it is
> not just me failing to found the appropriate docs ;-)
>
> - What's the idea behind the current implemention of __cmp__ and
> coercion, as described on (4)? I've to implement this feauture on
> Jython, but checking that two Java instances have the same __cmp__
> method is not that easy as in C. And more important: it could be
> wrong, depending on what is the idea behind the current CPython
> implementation.
>
> Finally, here are the examples of the behaviors outlined at the start
> of this mail.
>
> (1):
>
 class A(object):
> ...   def __eq__(self, other): return True
> ...   def __cmp__(self, other): return 1
> ...
 cmp(A(), A())
> 1
>
> (2):
>
 class A(object):
> ...  def __lt__(self, other): return True
> ...  def __gt__(self, other): return False
> ...  def __eq__(self, other): return False
> ...
 class B(A): pass
> ...
 cmp(A(), B())
> 1
>
> (3):
>
 class A(object):
> ...def __cmp__(self, other): return 1
> ...
 class B:
> ...def __cmp__(self, other): return 1
> ...
 cmp(A(), B())
> -1
>
> (4):
>
 class A(object):
> ... def __coerce__(self, other): return 0, 0
> ... def __cmp__(self, other): return -1
> ...
 cmp(A(), A())
> -1
>
> Regards,
> --
> Leo Soto M.
> http://blog.leosoto.com
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Guido van Rossum]

I don't see a way that __del__ could be invoked and access the NULL
between the Py_CLEAR() call and the Py_INCREF() call in the second
version.

On Tue, Aug 5, 2008 at 1:38 PM, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Sorry if this topic was discussed before, but I couldn't find.
>
> Py_CLEAR documentation explains why it is better than Py_DECREF and
> NULL assignment.  However, I don't understand why there is no similar
> macro for the case you want to replace one object with another?
>
> I.e. 'naive' way:
>
>Py_DECREF (self->x);
>/* This is prone to the same bug Py_CLEAR prevents. */
>self->x = y;
>Py_INCREF (self->x);
>
> Py_CLEAR way:
>
>Py_CLEAR (self->x);
>/* But __del__ can now in principle trigger access to NULL. */
>self->x = y;
>Py_INCREF (self->x);
>
> Way I'd think would be possible:
>
>Py_ASSIGN (self->x, y)
>
> where Py_ASSIGN is defined this way:
>
> #define Py_ASSIGN(op, val)  \
>do {\
>PyObject *_py_tmp = (PyObject *)(op);   \
>(op) = val; \
>Py_XINCREF(op); \
>Py_XDECREF(_py_tmp);\
>} while (0)
>
> Do I miss something obvious?  Or is there already a standard way to
> do that which I overlooked?
>
> Paul
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Leo Soto M.]

On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much
> it all matters -- but if you care, as long as it's supported at all,
> you might as well strive for the most compatibility with 2.5...

Sure, it won't be a problem on Jython 3.0. But I'm doing this for the
upcoming Jython 2.5, where we still have to live with __cmp__

-- 
Leo Soto M.
http://blog.leosoto.com
___
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

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Guido van Rossum]

On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much
>> it all matters -- but if you care, as long as it's supported at all,
>> you might as well strive for the most compatibility with 2.5...
>
> Sure, it won't be a problem on Jython 3.0. But I'm doing this for the
> upcoming Jython 2.5, where we still have to live with __cmp__

Which is why I recommend the closest possible compatibility. :-)

> --
> Leo Soto M.
> http://blog.leosoto.com
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Daniel Stutzbach]

On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:

> Py_CLEAR way:
>
>Py_CLEAR (self->x);
>/* But __del__ can now in principle trigger access to NULL. */
>self->x = y;
>Py_INCREF (self->x);


The Py_DECREF inside the Py_CLEAR may call arbitrary code while self->x
points to NULL.  This is OK if you write your code to recognize that self->x
may be NULL.

Without Py_CLEAR, a Py_DECREF may call arbitrary code while self->x points
to a deallocated object.  This is never OK since it's impossible to detect
that self->x is bogus.

Generally, I end up storing all the objects to be Py_DECREF'd in temporary
variables and doing the Py_DECREF's just before returning.  That way, "self"
is never in an inconsistent state.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Paul Pogonyshev]

Daniel Stutzbach wrote:
> On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> 
> > Py_CLEAR way:
> >
> >Py_CLEAR (self->x);
> >/* But __del__ can now in principle trigger access to NULL. */
> >self->x = y;
> >Py_INCREF (self->x);
> 
> The Py_DECREF inside the Py_CLEAR may call arbitrary code while self->x
> points to NULL.  This is OK if you write your code to recognize that self->x
> may be NULL.

Yes, this is quite similar to Python code

del obj.x
obj.x = y

though I'm not sure if for Python code x.__del__ will see obj.x as
non-set attribute (I guess so, but I'm not sure).

However, I'm trying to emulate

obj.x = y

in C.

> Without Py_CLEAR, a Py_DECREF may call arbitrary code while self->x points
> to a deallocated object.  This is never OK since it's impossible to detect
> that self->x is bogus.

Yes, this I don't argue.

> Generally, I end up storing all the objects to be Py_DECREF'd in temporary
> variables and doing the Py_DECREF's just before returning.  That way, "self"
> is never in an inconsistent state.

Right.  But wouldn't it be easier if there was a standard Python macro
for this, sort of like proposed Py_ASSIGN?

Paul
___
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

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Matt Giuca]

> After the most recent flurry of discussion I've lost track of what's
> the right thing to do. I also believe it was said it should wait until
> 2.7/3.0, so there's no hurry (in fact there's no way to check it -- we
> don't have branches for those versions yet).
>

I assume you mean 2.7/3.1.

I've always been concerned with the suggestion that this wait till 3.1. I
figure this patch is going to change the documented behaviour of these
functions, so it might be unacceptable to change it after 3.0 is released.
It seems logical that this patch be part of the
"incompatible-for-the-sake-of-fixing-things" set of changes in 3.0.

The current behaviour is broken. Any code which uses quote to produce a URL,
then unquotes the same URL later will simply break for characters outside
the Latin-1 range. This is evident in the SimpleHTTPServer class as I said
above (which presents users with URLs for the files in a directory using
quote, then gives 404 when they click on them, because unquote can't handle
it). And it will break any user's code which also assumes unquote is the
inverse of quote.

We could hack a fix into SimpleHTTPServer and expect other users to do the
same (along the lines of .encode('utf-8').decode('latin-1')), but then those
hacks will break when we apply the patch in 3.1 because they abuse Unicode
strings, and we'll have to have another debate about how to be backwards
compatible with them. (The patched version is largely compatible with the
2.x version, but the unpatched version isn't compatible with either the 2.x
version or the patched version).

Surely the sane option is to get this UTF-8 patch into version 3.0 so we
don't have to support this bug into the future? I'm far less concerned about
the decision with regards to unquote_to_bytes/quote_from_bytes, as those are
new features which can wait.

Matt Giuca
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Antoine Pitrou]

Paul Pogonyshev  gmx.net> writes:
> 
> Right.  But wouldn't it be easier if there was a standard Python macro
> for this, sort of like proposed Py_ASSIGN?

I proposed something similar in http://bugs.python.org/issue3081.



___
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

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Leo Soto M.]

On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much
>>> it all matters -- but if you care, as long as it's supported at all,
>>> you might as well strive for the most compatibility with 2.5...
>>
>> Sure, it won't be a problem on Jython 3.0. But I'm doing this for the
>> upcoming Jython 2.5, where we still have to live with __cmp__
>
> Which is why I recommend the closest possible compatibility. :-)

Oh, right :)

But that's going to be easier if I understand the "why" and not only
the "how". I can live with a "no idea why" answer, though.

-- 
Leo Soto M.
http://blog.leosoto.com
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Greg Ewing]

Paul Pogonyshev wrote:


del obj.x
obj.x = y

though I'm not sure if for Python code x.__del__ will see obj.x as
non-set attribute (I guess so, but I'm not sure).


A quick experiment suggests that it does:

Python 2.5 (r25:51908, Apr  8 2007, 22:22:18)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(object):
...  def __del__(self):
...   print "__del__"
...   print x.a
...
>>> x = Foo()
>>> x.a = Foo()
>>> del x.a
__del__
Exception exceptions.AttributeError: "'Foo' object has no attribute 'a'" in 
> ignored


--
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

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Guido van Rossum]

On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
 Given that in Python 3.0 __cmp__ is going away, I'm not sure how much
 it all matters -- but if you care, as long as it's supported at all,
 you might as well strive for the most compatibility with 2.5...
>>>
>>> Sure, it won't be a problem on Jython 3.0. But I'm doing this for the
>>> upcoming Jython 2.5, where we still have to live with __cmp__
>>
>> Which is why I recommend the closest possible compatibility. :-)
>
> Oh, right :)
>
> But that's going to be easier if I understand the "why" and not only
> the "how". I can live with a "no idea why" answer, though.

Close -- I would have to do a lot of thinking, swapping in parts of my
memory that have been gone for years. I say, follow CPython blindly
and you can't go too wrong: even if the rules are arbitrary, they are
what everyone expects.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Py_CLEAR and assigning values

[Daniel Stutzbach]

On Tue, Aug 5, 2008 at 4:30 PM, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:

> > Generally, I end up storing all the objects to be Py_DECREF'd in
> temporary
> > variables and doing the Py_DECREF's just before returning.  That way,
> "self"
> > is never in an inconsistent state.
>
> Right.  But wouldn't it be easier if there was a standard Python macro
> for this, sort of like proposed Py_ASSIGN?
>

If you're modifying exactly one property in the C function, yes.

In my C code, when I modifying an object I usually need to modifying many of
the properties which means that I need to delay all of the Py_DECREF's until
just before returning.  The Py_ASSIGN macro that you propose would not
achieve this.  If I used Py_ASSIGN, all the pointers would point to valid
objects, true, but the object might not be in a consistent state.

If in your code you frequently need to modifying just one property, you are
certainly free to create your own macro. :-)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Bill Janssen]

> I'm far less concerned about
> the decision with regards to unquote_to_bytes/quote_from_bytes, as those are
> new features which can wait.

Forgive me, but those are the *old* features, which must be there.

Bill
___
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