Re: [Python-Dev] More compact dictionaries with faster iteration

[Maciej Fijalkowski]

Hello everyone.

Thanks raymond for writing down a pure python version ;-)

I did an initial port to RPython for experiments. The results (on
large dicts only) are inconclusive - it's either a bit faster or a bit
slower, depending what exactly you do. There is a possibility I messed
something up too (there is a branch rdict-experiments in PyPy, in a
very sorry state though).

One effect we did not think about is that besides extra indirection,
there is an issue with data locality - having to look in two different
large lists seems to be a hit. Again, while I tried, the approach is
not scientific at all, but unless someone points a clear flaw in the
code (it's in pypy/rlib/dict.py in rdict-experiments branch), I'm
probably abandoning this for now.

Cheers,
fijal
___
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] PyTypeObject type names in Modules/

[Eli Bendersky]

>>
> >> 2013/1/1 Eli Bendersky :
> >> > Hello and happy 2013,
> >> >
> >> > Something I noticed earlier today is that some C versions of stdlib
> >> > modules
> >> > define their name similarly to the Python version in their
> PyTypeObject.
> >> > Some examples: Decimal, xml.etree's Element. Others prepend an
> >> > understore,
> >> > like _pickle.Pickler and many others.
> >> >
> >>
> >> I don't it's terribly important except if the object from the C module
> >> is directly exposed through the API it's nicer if it's __name__
> >> doesn't have a leading underscore.
> >
>

As a followup question: would it be considered a compatibility-breaking
change to rename PyTypeObject names? As a concrete example, in
Modules/_elementtree.c the name of Element_Type (essentially the
xml.etree.ElementTree.Element replacement in C) is "Element". For the
purpose of pickling/unpickling it should be named "_elementtree.Element" or
"xml.etree.ElementTree.Element" or some such thing. Can such a change be
made between 3.3 and 3.4? Between 3.3 and 3.3.1?

Eli
___
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] PyTypeObject type names in Modules/

[Benjamin Peterson]

2013/1/3 Eli Bendersky :
>
>
>> >>
>> >> 2013/1/1 Eli Bendersky :
>> >> > Hello and happy 2013,
>> >> >
>> >> > Something I noticed earlier today is that some C versions of stdlib
>> >> > modules
>> >> > define their name similarly to the Python version in their
>> >> > PyTypeObject.
>> >> > Some examples: Decimal, xml.etree's Element. Others prepend an
>> >> > understore,
>> >> > like _pickle.Pickler and many others.
>> >> >
>> >>
>> >> I don't it's terribly important except if the object from the C module
>> >> is directly exposed through the API it's nicer if it's __name__
>> >> doesn't have a leading underscore.
>> >
>
>
> As a followup question: would it be considered a compatibility-breaking
> change to rename PyTypeObject names? As a concrete example, in
> Modules/_elementtree.c the name of Element_Type (essentially the
> xml.etree.ElementTree.Element replacement in C) is "Element". For the
> purpose of pickling/unpickling it should be named "_elementtree.Element" or
> "xml.etree.ElementTree.Element" or some such thing. Can such a change be
> made between 3.3 and 3.4? Between 3.3 and 3.3.1?

I don't know much about etree. Can you pickle Element?



-- 
Regards,
Benjamin
___
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] PyTypeObject type names in Modules/

[Eli Bendersky]

On Thu, Jan 3, 2013 at 6:43 AM, Benjamin Peterson wrote:

> 2013/1/3 Eli Bendersky :
> >
> >
> >> >>
> >> >> 2013/1/1 Eli Bendersky :
> >> >> > Hello and happy 2013,
> >> >> >
> >> >> > Something I noticed earlier today is that some C versions of stdlib
> >> >> > modules
> >> >> > define their name similarly to the Python version in their
> >> >> > PyTypeObject.
> >> >> > Some examples: Decimal, xml.etree's Element. Others prepend an
> >> >> > understore,
> >> >> > like _pickle.Pickler and many others.
> >> >> >
> >> >>
> >> >> I don't it's terribly important except if the object from the C
> module
> >> >> is directly exposed through the API it's nicer if it's __name__
> >> >> doesn't have a leading underscore.
> >> >
> >
> >
> > As a followup question: would it be considered a compatibility-breaking
> > change to rename PyTypeObject names? As a concrete example, in
> > Modules/_elementtree.c the name of Element_Type (essentially the
> > xml.etree.ElementTree.Element replacement in C) is "Element". For the
> > purpose of pickling/unpickling it should be named "_elementtree.Element"
> or
> > "xml.etree.ElementTree.Element" or some such thing. Can such a change be
> > made between 3.3 and 3.4? Between 3.3 and 3.3.1?
>
> I don't know much about etree. Can you pickle Element?
>

etree has a C accelerator that was improved and extended in 3.3 and was
made the default when importing etree. But a regression (issue #16076)
occurs because _elementree.Element has no pickling support, while the
Python version does by default (being a plain Python class). In the
aforementioned issue we're trying to resolve the strategy for supporting
pickling for _elementtree.Element. I hope my understanding of unpickling is
correct - it does need a class name to find the module that can unpickle
the object, right? If this is correct, than such a change (name of the
type) may be required to solve the regression between 3.3 and 3.3.1

Eli
___
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] PyTypeObject type names in Modules/

[Benjamin Peterson]

2013/1/3 Eli Bendersky :
> etree has a C accelerator that was improved and extended in 3.3 and was made
> the default when importing etree. But a regression (issue #16076) occurs
> because _elementree.Element has no pickling support, while the Python
> version does by default (being a plain Python class). In the aforementioned
> issue we're trying to resolve the strategy for supporting pickling for
> _elementtree.Element. I hope my understanding of unpickling is correct - it
> does need a class name to find the module that can unpickle the object,
> right? If this is correct, than such a change (name of the type) may be
> required to solve the regression between 3.3 and 3.3.1

Yes, but you're probably going to have to do more than change the
class name in order for pickling to work for C types.



-- 
Regards,
Benjamin
___
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] PyTypeObject type names in Modules/

[Eli Bendersky]

On Thu, Jan 3, 2013 at 6:50 AM, Benjamin Peterson wrote:

> 2013/1/3 Eli Bendersky :
> > etree has a C accelerator that was improved and extended in 3.3 and was
> made
> > the default when importing etree. But a regression (issue #16076) occurs
> > because _elementree.Element has no pickling support, while the Python
> > version does by default (being a plain Python class). In the
> aforementioned
> > issue we're trying to resolve the strategy for supporting pickling for
> > _elementtree.Element. I hope my understanding of unpickling is correct -
> it
> > does need a class name to find the module that can unpickle the object,
> > right? If this is correct, than such a change (name of the type) may be
> > required to solve the regression between 3.3 and 3.3.1
>
> Yes, but you're probably going to have to do more than change the
> class name in order for pickling to work for C types.
>

Yes, of course. All of that is already implemented in patches Daniel Shahaf
has submitted to the issue. The "controversial" question here is whether
it's valid to change the __module__ of the type between 3.3 and 3.3.1 ?

Eli
___
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] PyTypeObject type names in Modules/

[Stefan Krah]

Eli Bendersky  wrote:
> Yes, of course. All of that is already implemented in patches Daniel Shahaf 
> has
> submitted to the issue. The "controversial" question here is whether it's 
> valid
> to change the __module__ of the type between 3.3 and 3.3.1 ?

In 3.2 and in the Python version of 3.3 we have this:

>>> Element.__module__
'xml.etree.ElementTree'


So IMHO changing the C version to do the same in 3.3.1 is a compatibility fix.


Stefan Krah


___
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] Posting frequent spurious changes in bugtracker

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This happens to me very frequently.

I get the notification about new issues open in the bugtracker. If I
see an interesting "bug", I usually open a Firefox tab with it, to
monitor it, decide if I will work on it in the future, whatever.

When I have time to decide, I proceed. If I find the issue interesting
but don't have the time to work on it, or somebody else is taking care
of it, I just add myself to the nosy list, and close the tab.

The problem with this is that even if I reload the tab, flags are
usually stale and when I add myself to the nosy list, I revert flags
to the old value.

This happens frequently. Last time:


I think tracker should keep a "version" hidden field, and refuse to
act if the version on server is different that the just posted
changes. Or something.

Or am I doing something fundamentally wrong?. I reflesh 99% of the
time, but could forget sometimes, and some other times I need a
"shift+reload" to bypass browser cache.

PS: Tracker tells me about conflicts ocasionally, but most of the time
the stale flags are not noticed.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQCVAwUBUOXi2Zlgi5GaxT1NAQK6ewQAlCv0RKb3/y6tzdjggm4JqOjt0E9vYyZJ
o0FIC+KBTrVtWrACiBOKCHPVsvJ1KB+6RzQ4FJdIyeOzG8Kv/E0HUNDufLGjr41C
NCd4O8FN0tpHIfJkpC3PbkinyhZpviQL7YindAteb92sa+QFm8Rp+QCKBFRecMUX
A7WLf+Gk8pE=
=famI
-END PGP SIGNATURE-
___
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] Posting frequent spurious changes in bugtracker

[Brett Cannon]

On Thu, Jan 3, 2013 at 2:58 PM, Jesus Cea  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This happens to me very frequently.
>
> I get the notification about new issues open in the bugtracker. If I
> see an interesting "bug", I usually open a Firefox tab with it, to
> monitor it, decide if I will work on it in the future, whatever.
>
> When I have time to decide, I proceed. If I find the issue interesting
> but don't have the time to work on it, or somebody else is taking care
> of it, I just add myself to the nosy list, and close the tab.
>
> The problem with this is that even if I reload the tab, flags are
> usually stale and when I add myself to the nosy list, I revert flags
> to the old value.
>
> This happens frequently. Last time:
> 
>
> I think tracker should keep a "version" hidden field, and refuse to
> act if the version on server is different that the just posted
> changes. Or something.
>

I think this should probably go upstream to Roundup if you want to see it
implemented as it's a general thing and not specific to our instance.


>
> Or am I doing something fundamentally wrong?. I reflesh 99% of the
> time, but could forget sometimes, and some other times I need a
> "shift+reload" to bypass browser cache.
>
>
Well, I would argue you are doing something fundamentally wrong by
submitting anything without refreshing first. It is a form so technically
nothing is being done incorrectly in changing values based on what you
submit, whether you view them stale or not.

If you want to keep this workflow going I would write a greasemonkey script
which refreshes those tabs you leave open on occasion to avoid this issue.

-Brett



> PS: Tracker tells me about conflicts ocasionally, but most of the time
> the stale flags are not noticed.
>
> - --
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
> .  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQCVAwUBUOXi2Zlgi5GaxT1NAQK6ewQAlCv0RKb3/y6tzdjggm4JqOjt0E9vYyZJ
> o0FIC+KBTrVtWrACiBOKCHPVsvJ1KB+6RzQ4FJdIyeOzG8Kv/E0HUNDufLGjr41C
> NCd4O8FN0tpHIfJkpC3PbkinyhZpviQL7YindAteb92sa+QFm8Rp+QCKBFRecMUX
> A7WLf+Gk8pE=
> =famI
> -END PGP SIGNATURE-
> ___
> 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/brett%40python.org
>
___
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] Posting frequent spurious changes in bugtracker

[Glenn Linderman]

On 1/3/2013 12:13 PM, Brett Cannon wrote:
It is a form so technically nothing is being done incorrectly in 
changing values based on what you submit, whether you view them stale 
or not.


Well, it sounds like a pretty shaky technology foundation, if 
simultaneous updates of a shared data repository have race conditions.


Certainly leaving a tab open for long periods of time exacerbates the 
issue, as it severely extends the definition of "simultaneous". Without 
that, the likelihood of people doing simultaneous updates is seriously 
reduced, except maybe for bugs with "hot" discussions.


Jesus' suggestion of a hidden version field would help, but could be 
annoying for the case of someone writing a lengthy response, and having 
it discarded because the hidden version field is too old... so care 
would have to be taken to preserve such responses when doing the refresh...


Another possible implementation would be to track which fields in the 
form are actually updated by a submitter... and reject a submission only 
if there was a simultaneous update to that field.


Another possible implementation for fields like nosy, would be to 
display the current list, but provide boxes for additions and deletions, 
rather than allowing editing. Or maybe just a "remove me" button for 
deletions would suffice, with a box for additions.  Then the processing 
would avoid adding duplicates.


People shouldn't have to do heroic things with refreshing to maintain 
the consistency of the underlying data...  database transaction 
technology has been around for quite a few years by now, and is well 
understood.
___
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] Posting frequent spurious changes in bugtracker

[Chris Jerdonek]

On Thu, Jan 3, 2013 at 1:06 PM, Glenn Linderman  wrote:
> Jesus' suggestion of a hidden version field would help, but could be
> annoying for the case of someone writing a lengthy response, and having it
> discarded because the hidden version field is too old... so care would have
> to be taken to preserve such responses when doing the refresh...

I seem to recall that this already happens in certain circumstances.
If someone else posts a comment while you are composing a comment, the
user interface notifies you with a red box when you try to submit that
the thread has changed.  It prevents the post but does preserve the
text you are composing.

--Chris
___
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] PyTypeObject type names in Modules/

[Benjamin Peterson]

2013/1/3 Eli Bendersky :
>
>
>
> On Thu, Jan 3, 2013 at 6:50 AM, Benjamin Peterson 
> wrote:
>>
>> 2013/1/3 Eli Bendersky :
>> > etree has a C accelerator that was improved and extended in 3.3 and was
>> > made
>> > the default when importing etree. But a regression (issue #16076) occurs
>> > because _elementree.Element has no pickling support, while the Python
>> > version does by default (being a plain Python class). In the
>> > aforementioned
>> > issue we're trying to resolve the strategy for supporting pickling for
>> > _elementtree.Element. I hope my understanding of unpickling is correct -
>> > it
>> > does need a class name to find the module that can unpickle the object,
>> > right? If this is correct, than such a change (name of the type) may be
>> > required to solve the regression between 3.3 and 3.3.1
>>
>> Yes, but you're probably going to have to do more than change the
>> class name in order for pickling to work for C types.
>
>
> Yes, of course. All of that is already implemented in patches Daniel Shahaf
> has submitted to the issue. The "controversial" question here is whether
> it's valid to change the __module__ of the type between 3.3 and 3.3.1 ?

Failure to pickle suddenly is more of a compatibility issue IMO.


-- 
Regards,
Benjamin
___
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] Posting frequent spurious changes in bugtracker

[Brett Cannon]

On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman wrote:

>  On 1/3/2013 12:13 PM, Brett Cannon wrote:
>
> It is a form so technically nothing is being done incorrectly in changing
> values based on what you submit, whether you view them stale or not.
>
>
> Well, it sounds like a pretty shaky technology foundation, if simultaneous
> updates of a shared data repository have race conditions.
>
> Certainly leaving a tab open for long periods of time exacerbates the
> issue, as it severely extends the definition of "simultaneous".  Without
> that, the likelihood of people doing simultaneous updates is seriously
> reduced, except maybe for bugs with "hot" discussions.
>
>
I would argue it is no longer simultaneous and thus not a race condition.
You can't consider a POST transactional based on when the HTTP GET request
for the form completed to when the POST finally occurs.


> Jesus' suggestion of a hidden version field would help, but could be
> annoying for the case of someone writing a lengthy response, and having it
> discarded because the hidden version field is too old... so care would have
> to be taken to preserve such responses when doing the refresh...
>

As I said, this belongs upstream in Roundup and not directly in our roundup
instance for a proper fix. This is beyond schema and it heading into
low-level Roundup POST functionality.

-Brett


> Another possible implementation would be to track which fields in the form
> are actually updated by a submitter... and reject a submission only if
> there was a simultaneous update to that field.
>
> Another possible implementation for fields like nosy, would be to display
> the current list, but provide boxes for additions and deletions, rather
> than allowing editing. Or maybe just a "remove me" button for deletions
> would suffice, with a box for additions.  Then the processing would avoid
> adding duplicates.
>
> People shouldn't have to do heroic things with refreshing to maintain the
> consistency of the underlying data...  database transaction technology has
> been around for quite a few years by now, and is well understood.
>
___
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] Posting frequent spurious changes in bugtracker

[Glenn Linderman]

On 1/3/2013 2:43 PM, Brett Cannon wrote:




On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman > wrote:


On 1/3/2013 12:13 PM, Brett Cannon wrote:

It is a form so technically nothing is being done incorrectly in
changing values based on what you submit, whether you view them
stale or not.


Well, it sounds like a pretty shaky technology foundation, if
simultaneous updates of a shared data repository have race conditions.

Certainly leaving a tab open for long periods of time exacerbates
the issue, as it severely extends the definition of
"simultaneous".  Without that, the likelihood of people doing
simultaneous updates is seriously reduced, except maybe for bugs
with "hot" discussions.


I would argue it is no longer simultaneous and thus not a race 
condition. You can't consider a POST transactional based on when the 
HTTP GET request for the form completed to when the POST finally occurs.


Argue away. it still is a race condition, just a slow race. HTTP is 
stateless, not transactional, agreed, but when a  transaction system is 
implemented on top of HTTP, it needs to implement transactional 
semantics itself... or else it is a pretty shaky foundation for a 
database. The POST is an update, the prior GET started the transaction. 
This is just the definition of a transaction, so any arguments you have 
can only claim that Roundup doesn't implement transactions, and the bug 
tracker is not a database... and if you are right, then it is a pretty 
shaky foundation for a bug tracker database. I think that is what I said 
in the first place :)



Jesus' suggestion of a hidden version field would help, but could
be annoying for the case of someone writing a lengthy response,
and having it discarded because the hidden version field is too
old... so care would have to be taken to preserve such responses
when doing the refresh...


As I said, this belongs upstream in Roundup and not directly in our 
roundup instance for a proper fix. This is beyond schema and it 
heading into low-level Roundup POST functionality.


Agreed, the fix, if to be done correctly, belongs in Roundup, from what 
I understand of how things are implemented.



-Brett


Another possible implementation would be to track which fields in
the form are actually updated by a submitter... and reject a
submission only if there was a simultaneous update to that field.

Another possible implementation for fields like nosy, would be to
display the current list, but provide boxes for additions and
deletions, rather than allowing editing. Or maybe just a "remove
me" button for deletions would suffice, with a box for additions. 
Then the processing would avoid adding duplicates.


People shouldn't have to do heroic things with refreshing to
maintain the consistency of the underlying data...  database
transaction technology has been around for quite a few years by
now, and is well understood.




___
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] Posting frequent spurious changes in bugtracker

[Stephen J. Turnbull]

Now that Jesus has provided a heads-up, detailed discussion belongs on
the metatracker IMO.  Warning: Reply-To set to tracker-disc...@python.org.

metatracker workers: Created issue500.  More info: see this thread:
http://mail.python.org/pipermail/python-dev/2013-January/123437.html

Brett Cannon writes:

 > > Or am I doing something fundamentally wrong?. I reflesh 99% of the
 > > time, but could forget sometimes, and some other times I need a
 > > "shift+reload" to bypass browser cache.
 > >
 > Well, I would argue you are doing something fundamentally wrong by
 > submitting anything without refreshing first. It is a form so technically
 > nothing is being done incorrectly in changing values based on what you
 > submit, whether you view them stale or not.

That's beside the point, Brett.  First, his intent is to refresh, so
he's doing his best - he merely admits he's human, and would like help
from the machine.  But the nub of his report is the fact that nothing
he *can* do seems to do the whole job of refreshing.

Nor is he complaining about the form processing at the HTML/HTTP
level.  The limits of the HTTP transport don't justify the defects of
the database backend, although they are likely to cause inconvenience
to users (ie, the easy patch is to block the whole update, rather than
update only the fields the user has explicitly changed).

I need to update XEmacs's tracker anyway, I'll investigate whether
upstream has a fix for this, and if not, see if I can come up with a
patch for this while I'm updating.  Technically it shouldn't be hard
to implement Jesus's suggestion, and at least reject potential
spurious updates (the tracker db has a timestamp on every change).

metatracker workers: no ETA on this, feel free to ping me for updates
or prod me to get to work.
___
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