Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

2009-03-07 Thread Martin v. Löwis
>> I still fail to see the rationale for removing these
>> two methods.
> 
> I believe there was a thread (in January 2008) with a decision to keep
> qsize() but to drop empty() and full().

That's something different: even if there was a decision, it doesn't
mean that there was a rationale, and that the rationale was correct.
I see that you proposed to remove the methods because they are
unreliable. I still think this classification is incorrect: they are
*not* unreliable. They do what they do correctly and reliably.

Looking at the discussion (on python-3000), I don't see that an
actual decision was made. You proposed it, there was a *lot* of
objections. Guido proposed a compromise (without indicating whether
he was in favor of the removal in the first place). There was then
still opposition both to leaving qsize, and to change anything at
all - and then you removed the methods.

At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
"not reliable!" is removed from the doc strings of the methods, as
it is factually incorrect.

Regards,
Martin
___
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] Regexp 2.7

2009-03-07 Thread Antoine Pitrou
Hello,

Matthew Barnett has been doing a lot of work on the regular expressions engine
(it seems he hasn't finished yet) under http://bugs.python.org/issue2636.
However, the patches are really huge and touch all of the sre internals. I
wonder what the review process can be for such patches? Is there someone
knowledgeable enough to be able to review them?

Regards

Antoine.


___
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] Regexp 2.7

2009-03-07 Thread Martin v. Löwis
> Matthew Barnett has been doing a lot of work on the regular expressions engine
> (it seems he hasn't finished yet) under http://bugs.python.org/issue2636.
> However, the patches are really huge and touch all of the sre internals. I
> wonder what the review process can be for such patches? Is there someone
> knowledgeable enough to be able to review them?

Traditionally, Fredrik Lundh has reviewed sre patches. Not sure whether
he is interested in that anymore, though.

Regards,
Martin
___
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] Pickler/Unpickler API clarification

2009-03-07 Thread Greg Ewing

Michael Haggerty wrote:


A similar effect could *almost* be obtained without accessing the memos
by saving the pickled primer itself in the database.  The unpickler
would be primed by using it to load the primer before loading the record
of interest.  But AFAIK there is no way to prime new picklers, because
there is no guarantee that pickling the same primer twice will result in
the same id->object mapping in the pickler's memo.


Would it help if, when creating a pickler or unpickler,
you could specify another pickler or unpickler whose
memo is used to initialise the memo of the new one?

Then you could keep the pickler that you used to pickle
the primer and "fork" new picklers off it, and similarly
with the unpicklers.

--
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] Pickler/Unpickler API clarification

2009-03-07 Thread Greg Ewing

Antoine Pitrou wrote:


If these strings are not interned, then perhaps they should be.


I think this is a different problem. Even if the strings are
interned, if you start with a fresh pickler each time, you
get a copy of the strings in each pickle. What he wants is
to share strings between different pickles.

--
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] Python wins Linux New Media Award for Best Open Source Programming Language

2009-03-07 Thread anatoly techtonik
On Sat, Mar 7, 2009 at 9:32 AM, Lie Ryan  wrote:

 The prize was Martin von Löwis of the Python Foundation on behalf of the
 Python community itself.
>>>
>>> This is a funny translation from German-to-English. :-)
>>>
>>> But yeah, a good one and the prize was presented by Klaus Knopper of
>>> Knoppix.
>>>
>>> Congratulations!
>>
>> Actually, the prize went to "Python", not to me, and not to the PSF. So
>> congratulations to you as well!
>
> The (translated) article says that YOU are the prize? WOW.
>
> Ummm... better not to use automatic translator for anything mission
> critical.
>

Congratulations! There is already a proper English version of press
release at 
http://www.linux-magazine.com/online/news/cebit_2009_openstreetmap_wins_two_linux_new_media_awards
so new link can probably be changed. The article still doesn't mention
competitors.

-- 
--anatoly t.
___
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] 3.1 performance

2009-03-07 Thread Antoine Pitrou
Hello,

Out of curiosity, I timed running the test suite ("./python -m test.regrtest")
in non-debug mode, in both the release30-maint and py3k branches:

* release30-maint got:
302 tests OK.
[...]
165.79user 26.03system 5:01.75elapsed 63%CPU

* py3k got:
304 tests OK.
[...]
113.33user 28.93system 4:06.79elapsed 57%CPU

So, 3.1 is 30% faster in user CPU time, even though it probably has more tests
(because of io-c, ordereddict and importlib). This is on a 64-bit Linux AMD
system, and I got similar results on a 64-bit Linux Core2 system.

Regards

Antoine.


___
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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

2009-03-07 Thread Raymond Hettinger


[MvL]

At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
"not reliable!" is removed from the doc strings of the methods, as
it is factually incorrect.


I would be happy to restore the documentation.  You want the methods
back and I think that's sufficient reason to bring it back.

The "not reliable" wording in the docstrings was put there by Guido 16 years ago. 
http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup

Speak to him about this.  I'm done with this thread.


Raymond
___
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] 3.1 performance

2009-03-07 Thread Hirokazu Yamamoto

Antoine Pitrou wrote:

Hello,

Out of curiosity, I timed running the test suite ("./python -m test.regrtest")
in non-debug mode, in both the release30-maint and py3k branches:

* release30-maint got:
302 tests OK.
[...]
165.79user 26.03system 5:01.75elapsed 63%CPU

* py3k got:
304 tests OK.
[...]
113.33user 28.93system 4:06.79elapsed 57%CPU

So, 3.1 is 30% faster in user CPU time, even though it probably has more tests
(because of io-c, ordereddict and importlib). This is on a 64-bit Linux AMD
system, and I got similar results on a 64-bit Linux Core2 system.

Regards

Antoine.


Yes, traceback in large file is also quite fast now. Good work, io-c 
guys. :-)

___
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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()

2009-03-07 Thread Raymond Hettinger



[MvL]

At this point, I do request that the patch is reverted completely
(i.e. that the documentation is restored), and that the qualification
"not reliable!" is removed from the doc strings of the methods, as
it is factually incorrect.


I would be happy to restore the documentation.  You want the methods
back and I think that's sufficient reason to bring it back.

The "not reliable" wording in the docstrings was put there by Guido 16 years ago. 
http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup

Speak to him about this.  I'm done with this thread.


Also, for years, the documentation also had a "not-reliable" notice:

   Return ``True`` if the queue is empty, ``False`` otherwise. 
   Because of multithreading semantics, this is not reliable.


Skip changed it to the present wording last year:
http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969


Raymond

___
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] More on Py3K urllib -- urlencode()

2009-03-07 Thread Dan Mahn
After a harder look, I concluded there was a bit more work to be done, 
but still very basic modifications.


Attached is a version of urlencode() which seems to make the most sense 
to me.


I wonder how I could officially propose at least some of these 
modifications.


- Dan



Bill Janssen wrote:

Bill Janssen  wrote:

  

Dan Mahn  wrote:



3) Regarding the following code fragment in urlencode():

   k = quote_plus(str(k))
  if isinstance(v, str):
   v = quote_plus(v)
   l.append(k + '=' + v)
   elif isinstance(v, str):
   # is there a reasonable way to convert to ASCII?
   # encode generates a string, but "replace" or "ignore"
   # lose information and "strict" can raise UnicodeError
   v = quote_plus(v.encode("ASCII","replace"))
   l.append(k + '=' + v)

I don't understand how the "elif" section is invoked, as it uses the
same condition as the "if" section.
  

This looks like a 2->3 bug; clearly only the second branch should be
used in Py3K.  And that "replace" is also a bug; it should signal an
error on encoding failures.  It should probably catch UnicodeError and
explain the problem, which is that only Latin-1 values can be passed in
the query string.  So the encode() to "ASCII" is also a mistake; it
should be "ISO-8859-1", and the "replace" should be a "strict", I think.



Sorry!  In 3.0.1, this whole thing boils down to

   l.append(quote_plus(k) + '=' + quote_plus(v))

Bill
  
def urlencode(query, doseq=0, safe='', encoding=None, errors=None):
"""Encode a sequence of two-element tuples or dictionary into a URL query 
string.

If any values in the query arg are sequences and doseq is true, each
sequence element is converted to a separate parameter.

If the query arg is a sequence of two-element tuples, the order of the
parameters in the output will match the order of parameters in the
input.
"""

if hasattr(query,"items"):
# mapping objects
query = query.items()
else:
# it's a bother at times that strings and string-like objects are
# sequences...
try:
# non-sequence items should not work with len()
# non-empty strings will fail this
if len(query) and not isinstance(query[0], tuple):
raise TypeError
# zero-length sequences of all types will get here and succeed,
# but that's a minor nit - since the original implementation
# allowed empty dicts that type of behavior probably should be
# preserved for consistency
except TypeError:
ty,va,tb = sys.exc_info()
raise TypeError("not a valid non-string sequence or mapping 
object").with_traceback(tb)

l = []
if not doseq:
# preserve old behavior
for k, v in query:
k = quote_plus(k if isinstance(k, (str,bytes)) else str(k), safe, 
encoding, errors)
v = quote_plus(v if isinstance(v, (str,bytes)) else str(v), safe, 
encoding, errors)
l.append(k + '=' + v)
else:
for k, v in query:
k = quote_plus(k if isinstance(k, (str,bytes)) else str(k), safe, 
encoding, errors)
if isinstance(v, str):
v = quote_plus(v if isinstance(v, (str,bytes)) else str(v), 
safe, encoding, errors)
l.append(k + '=' + v)
else:
try:
# is this a sufficient test for sequence-ness?
x = len(v)
except TypeError:
# not a sequence
v = quote_plus(str(v))
l.append(k + '=' + v)
else:
# loop over the sequence
for elt in v:
elt = quote_plus(elt if isinstance(elt, (str,bytes)) 
else str(elt), safe, encoding, errors)
l.append(k + '=' + elt)
return '&'.join(l)
___
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] More on Py3K urllib -- urlencode()

2009-03-07 Thread Aahz
On Sat, Mar 07, 2009, Dan Mahn wrote:
>
> After a harder look, I concluded there was a bit more work to be done,  
> but still very basic modifications.
>
> Attached is a version of urlencode() which seems to make the most sense  
> to me.
>
> I wonder how I could officially propose at least some of these  
> modifications.

Submit a patch to bugs.python.org
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
___
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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()

2009-03-07 Thread Guido van Rossum
On Sat, Mar 7, 2009 at 6:54 AM, Raymond Hettinger  wrote:
>
>> [MvL]
>>>
>>> At this point, I do request that the patch is reverted completely
>>> (i.e. that the documentation is restored), and that the qualification
>>> "not reliable!" is removed from the doc strings of the methods, as
>>> it is factually incorrect.
>>
>> I would be happy to restore the documentation.  You want the methods
>> back and I think that's sufficient reason to bring it back.
>>
>> The "not reliable" wording in the docstrings was put there by Guido 16
>> years ago.
>> http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup
>> Speak to him about this.  I'm done with this thread.
>
> Also, for years, the documentation also had a "not-reliable" notice:
>
>   Return ``True`` if the queue is empty, ``False`` otherwise.   Because of
> multithreading semantics, this is not reliable.
>
> Skip changed it to the present wording last year:
> http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969

That was a long time ago, but I think I just meant the obvious warning
about multi-threaded use: if you are using full() and empty() and
other threads may also mutate the queue, then you cannot use them to
reliably prevent you from blocking. That's why eventually the
facilities for non-blocking get() and put() were added (I think by Tim
Peters).

-- 
--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] Pickler/Unpickler API clarification

2009-03-07 Thread Michael Haggerty
Greg Ewing wrote:
> Michael Haggerty wrote:
>> A similar effect could *almost* be obtained without accessing the memos
>> by saving the pickled primer itself in the database.  The unpickler
>> would be primed by using it to load the primer before loading the record
>> of interest.  But AFAIK there is no way to prime new picklers, because
>> there is no guarantee that pickling the same primer twice will result in
>> the same id->object mapping in the pickler's memo.
> 
> Would it help if, when creating a pickler or unpickler,
> you could specify another pickler or unpickler whose
> memo is used to initialise the memo of the new one?
> 
> Then you could keep the pickler that you used to pickle
> the primer and "fork" new picklers off it, and similarly
> with the unpicklers.

Typically, the purpose of a database is to persist data across program
runs.  So typically, your suggestion would only help if there were a way
to persist the primed Pickler across runs.

(The primed Unpickler is not quite so important because it can be primed
by reading a pickle of the primer, which in turn can be stored somewhere
in the DB.)

In the particular case of cvs2svn, each of our databases is in fact
written in a single pass, and then in later passes only read, not
written.  So I suppose we could do entirely without pickleable Picklers,
if they were copyable within a single program run.  But that constraint
would make the feature even less general.

Michael
___
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] Pickler/Unpickler API clarification

2009-03-07 Thread Guido van Rossum
On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty  wrote:
> Typically, the purpose of a database is to persist data across program
> runs.  So typically, your suggestion would only help if there were a way
> to persist the primed Pickler across runs.

I haven't followed all this, but isn't is at least possible to
conceive of the primed pickler as being recreated from scratch from
constant data each run?

> (The primed Unpickler is not quite so important because it can be primed
> by reading a pickle of the primer, which in turn can be stored somewhere
> in the DB.)
>
> In the particular case of cvs2svn, each of our databases is in fact
> written in a single pass, and then in later passes only read, not
> written.  So I suppose we could do entirely without pickleable Picklers,
> if they were copyable within a single program run.  But that constraint
> would make the feature even less general.

Being copyable is mostly equivalent to being picklable, but it's
probably somewhat weaker because it's easier to define it as a pointer
copy for some types that aren't easily picklable.

-- 
--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] Belated introduction

2009-03-07 Thread rdmurray

I've been watching the threads about tracker maintenance and patch
review with interest.  I'm afraid that I did not follow the list
recommendation to introduce myself when I first started posting, partly
because I initially jumped in on something that was a bit of a hot
button issue for me :)

So, a little belatedly, here is my intro.  I've been coding in and
loving Python since 1993 or thereabouts.  I am currently an independent
IT consultant, with specialization in IP networking (especially Cisco),
Lunix and Unix system administration, and systems integration.  It is in
my systems integration work that I make heavy use of Python, writing
scripts and programs to tie systems together and/or add needed
functionality.

In my previous life I was Director of Technology for an ISP, and at one
stage we were heavy into web site development.  At that time I worked
with the Zope community quite a bit, and made some contributions to the
beginnings of Zope3.  So for at least a few people this might be more of
a re-introduction.

I've decided that this year I would like to get more involved in the
Python community.  As another poster said, I'm looking forward to the
opportunity to work with and learn from some very smart people.  And
then there's the satisfaction of giving back to a community that has
given me so much over the years, by producing such a delightful language
in which to do my coding.

So, I've been reading the developer docs, setting up a bzr checkout,
learning how to compile a debug python and run tests, wandering around
in the source code, etc, etc.

My thought about how I could best contribute at the present time is to
help out with reviewing tracker issues.  I actually updated the open
tracker issue with the oldest last activity date this morning, as a sort
of trial run.  Unless someone wants to suggest a different way for me to
contribute (I'm open to any suggestions), I'll probably continue through
the list in reverse order of last update date and cherry pick things
that interest me and that I think I can make some sort of contribution to.

Don't hesitate to let me know if I miss etiquette points (gently, please
:).

Oh, and I'll be at pycon this year (my second pycon, the first was
several years back), and look forward to hanging out with a cool bunch
of people :)

--RDM
___
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] Belated introduction

2009-03-07 Thread Aahz
On Sat, Mar 07, 2009, rdmur...@bitdance.com wrote:
>
> So, a little belatedly, here is my intro.  [...]
>
> --RDM

Welcome!  You apparently haven't set your $NAME nor listed a name in your
.sig, so how do you prefer to be addressed?  Or do you just prefer your
initials, like RMS?  ;-)
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
___
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] IMAP/POP3 servers on python.org?

2009-03-07 Thread Aahz
[moving discussion to python-dev from pydotorg]

On Fri, Mar 06, 2009, Bill Janssen wrote:
> Michael Foord  wrote:
>> Bill Janssen wrote:
>>> Steve Holden  wrote:
   
 Seems to me it might be better to have a test start a local server then
 kill it, but I am presuming you have some good reason why this is not
 practical?
>>> 
>>> It seems a steep learning curve just to run the Python test suite, to
>>> have to know how to install an IMAP server on your machine.  But perhaps
>>> you're right.
>>   
>> Does it need to test against a real server - can't some of the lower
>> calls be mocked out?
> 
> Not really.  These *are* the lower-level calls.

One thing I haven't seen addressed in this discussion is why it's
undesirable to ship Twisted as part of the testing source tree.  Yes, I
realize that it could create an "attractive nuisance", but I think the
gains in simplifying testing outweigh that.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
___
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] IMAP/POP3 servers on python.org?

2009-03-07 Thread Antoine Pitrou
Aahz  pythoncraft.com> writes:
> 
> One thing I haven't seen addressed in this discussion is why it's
> undesirable to ship Twisted as part of the testing source tree.

Because Twisted is huge and it's not reasonable to include it just for testing
purposes?
(besides, launching a twisted server implies running a reactor and I'm not sure
the reactors support being started and stopped several times yet)


___
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] Belated introduction

2009-03-07 Thread rdmurray

On Sat, 7 Mar 2009 at 08:42, Aahz wrote:

On Sat, Mar 07, 2009, rdmur...@bitdance.com wrote:


So, a little belatedly, here is my intro.  [...]

--RDM


Welcome!  You apparently haven't set your $NAME nor listed a name in your
.sig, so how do you prefer to be addressed?  Or do you just prefer your
initials, like RMS?  ;-)


Thanks.

Initials is fine, but I'm more used to 'David' as form of address.  I
have been using my initials in my sig because there are just too many
Davids around.

I suppose changing my sig to my name and my website wouldn't be
be a bad thing, so...

--
R. David Murray   http://www.bitdance.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] Pickler/Unpickler API clarification

2009-03-07 Thread Michael Haggerty
Guido van Rossum wrote:
> On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty  wrote:
>> Typically, the purpose of a database is to persist data across program
>> runs.  So typically, your suggestion would only help if there were a way
>> to persist the primed Pickler across runs.
> 
> I haven't followed all this, but isn't is at least possible to
> conceive of the primed pickler as being recreated from scratch from
> constant data each run?

If there were a guarantee that pickling the same data would result in
the same memo ID -> object mapping, that would also work.  But that
doesn't seem to be a realistic guarantee to make.  AFAIK the memo IDs
are integers chosen consecutively in the order that objects are pickled,
which doesn't seem so bad.  But compound objects are a problem.  For
example, when pickling a map, the map entries would have to be pickled
in an order that remains consistent across runs (and even across Python
versions).  Even worse, all user-written __getstate__() methods would
have to return exactly the same result, even across program runs.

>> (The primed Unpickler is not quite so important because it can be primed
>> by reading a pickle of the primer, which in turn can be stored somewhere
>> in the DB.)
>>
>> In the particular case of cvs2svn, each of our databases is in fact
>> written in a single pass, and then in later passes only read, not
>> written.  So I suppose we could do entirely without pickleable Picklers,
>> if they were copyable within a single program run.  But that constraint
>> would make the feature even less general.
> 
> Being copyable is mostly equivalent to being picklable, but it's
> probably somewhat weaker because it's easier to define it as a pointer
> copy for some types that aren't easily picklable.

Indeed.  And pickling the memo should not present any fundamental
problems, since by construction it can only contain pickleable objects.

Michael
___
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] More on Py3K urllib -- urlencode()

2009-03-07 Thread Bill Janssen
Aahz  wrote:

> On Sat, Mar 07, 2009, Dan Mahn wrote:
> >
> > After a harder look, I concluded there was a bit more work to be done,  
> > but still very basic modifications.
> >
> > Attached is a version of urlencode() which seems to make the most sense  
> > to me.
> >
> > I wonder how I could officially propose at least some of these  
> > modifications.
> 
> Submit a patch to bugs.python.org

And it would help if it included a lot of test cases.

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


[Python-Dev] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Benjamin Peterson
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.

Python 3.1 focuses on the stabilization and optimization of features and changes
Python 3.0 introduced.  The new I/O system has been rewritten in C for speed.
Other features include a ordered dictionary implementation and support for ttk
Tile in Tkinter.

Please note that these are alpha releases, and as such are not suitable for
production environments.  We continue to strive for a high degree of quality,
but there are still some known problems and the feature sets have not been
finalized.  These alphas are being released to solicit feedback and hopefully
discover bugs, as well as allowing you to determine how changes in 3.1 might
impact you.  If you find things broken or incorrect, please submit a bug report
at

 http://bugs.python.org

For more information and downloads, see the Python 3.1 website:

 http://www.python.org/download/releases/3.1/

See PEP 375 for release schedule details:

 http://www.python.org/dev/peps/pep-0361/


Enjoy,
-- Benjamin

Benjamin Peterson
benjamin at python.org
Release Manager
(on behalf of the entire python-dev team)
___
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] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Gerard Flanagan

Benjamin Peterson wrote:

On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.


[...]

Looks good, thanks to all involved. Two minor things:



For more information and downloads, see the Python 3.1 website:

 http://www.python.org/download/releases/3.1/



On the release page, the bzip link says '3.0' not '3.1'.


See PEP 375 for release schedule details:

 http://www.python.org/dev/peps/pep-0361/



On the PEP page, the Google calendar link is borken.

Regards

G.


___
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] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Aahz
On Sat, Mar 07, 2009, Benjamin Peterson wrote:
>
> On behalf of the Python development team and the Python community, I'm
> happy to announce the first alpha release of Python 3.1.

Congratulations on your first baby!  Here's to hoping you release many
more of these!
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
___
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] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Benjamin Peterson
2009/3/7 Gerard Flanagan :
> Benjamin Peterson wrote:
> On the release page, the bzip link says '3.0' not '3.1'.

That should be fixed now.

>
>> See PEP 375 for release schedule details:
>>
>>     http://www.python.org/dev/peps/pep-0361/

That URL is actually supposed to be http://www.python.org/dev/peps/pep-0375/.



-- 
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] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Raymond Hettinger


[Benjamin Peterson]

On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.


Thanks for the good work.


Raymond
___
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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

2009-03-07 Thread Martin v. Löwis
> I would be happy to restore the documentation.  You want the methods
> back and I think that's sufficient reason to bring it back.

Thanks! I'll look into the docstrings.

Martin
___
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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()

2009-03-07 Thread Martin v. Löwis
> Skip changed it to the present wording last year:
> http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969

I see. I agree that the change was for the better.

Martin
___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

2009-03-07 Thread Neil Schemenauer
gl...@divmod.com  wrote:
> ... which is exactly why I have volunteered to explain to someone how to 
> separate the core event-loop bits (suitable for inclusion in the 
> standard library) from the huge pile of protocol implementations which 
> are not necessarily useful.
>
> Despite the FUD to the contrary, Twisted's internal factoring is quite 
> good; it's not a single, undifferentiated pile of code.  Plus, at this 
> point, we're not even talking about actually putting any Twisted code 
> into the standard library, just standardizing the "protocol" API, which 
> basically boils down to:
[...]

This sounds great.  I'm interested on working on this since it
scratches an itch of mine but I don't know if I will have time.  Do
you think if this part of Twisted became part of the standard
library that it would be used by Twisted or would it continue to
have its own version?

  Neil

___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

2009-03-07 Thread skip
Glyph> ... which is exactly why I have volunteered to explain to someone
Glyph> how to separate the core event-loop bits (suitable for inclusion
Glyph> in the standard library) from the huge pile of protocol
Glyph> implementations which are not necessarily useful.

Neil> This sounds great.  I'm interested on working on this since it
Neil> scratches an itch of mine but I don't know if I will have time.
Neil> Do you think if this part of Twisted became part of the standard
Neil> library that it would be used by Twisted or would it continue to
Neil> have its own version?

Anybody interested in working on this at a PyCon Sprint?  I won't be
attending the conference proper, but plan to spend a couple days sprinting,
one on Mailman/SpamBayes integration and one on Python core stuff.  This
might fit well into my Python core "slot".  I will probably have little time
before the sprint to do much, but any brain dumps or Twisted pointers people
could give me in the interim would be appreciated.

Skip
___
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] RELEASED Python 3.1 alpha 1

2009-03-07 Thread Guido van Rossum
On Sat, Mar 7, 2009 at 1:21 PM, Raymond Hettinger  wrote:
>
> [Benjamin Peterson]
>>
>> On behalf of the Python development team and the Python community, I'm
>> happy to announce the first alpha release of Python 3.1.
>
> Thanks for the good work.

Sorry to be late to the party. Indeed, thanks for all your efforts. I
really appreciate it!!

-- 
--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] Pickler/Unpickler API clarification

2009-03-07 Thread Greg Ewing

Michael Haggerty wrote:


Typically, the purpose of a database is to persist data across program
runs.  So typically, your suggestion would only help if there were a way
to persist the primed Pickler across runs.


I don't think you need to be able to pickle picklers.

In the case in question, the master pickler would be primed
by pickling all the shared classes, and the resulting pickle
would be stored in the database.

When unpickling, the master unpickler would be primed by
unpickling the shared pickle.

--
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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()

2009-03-07 Thread Guido van Rossum
On Sat, Mar 7, 2009 at 2:56 PM, "Martin v. Löwis"  wrote:
>> Skip changed it to the present wording last year:
>> http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969
>
> I see. I agree that the change was for the better.

Agreed too, though it would seem that *if* there is a single reader,
empty()==False would guarantee that one subsequent get() won't block,
and similar *if* there is a single writer, full()==False would
guarantee that the next put() won't block. My point being that the
lack of guarantee has to do with the necessary consequences of the
non-atomicity of making two calls, not with anything inherently buggy
in the implementation. Because Queue is designed for multi-threaded
use, it's important to emphasize the lacking guarantees; but I think
it's even more important to explain *why* these guarantees cannot
hold. After all we don't go around documenting e.g. that for a
dictionary, after "x in d" returns True, "x[d]" may still raise a
KeyError exception (in case another thread deleted it). I'm not sure
how I would modify the Queue documentation to clarify all this;
perhaps it would be helpful to add an introductory section explaining
the general issues with multiple readers and writers, and refer to
this section in the descriptions of qsize() (and empty() and full() if
they remain documented)?

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