Re: [Python-Dev] Attention Bazaar mirror users

[David Cournapeau]

On Sat, Feb 21, 2009 at 3:52 PM, Stephen J. Turnbull  wrote:
> David Cournapeau writes:
>  > On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw  wrote:
>
>  > > In both those cases, you can use the PPA:
>
>  > Please note that for many people in a corporate/university
>  > environment, this is not an option. Granted, you can install it by
>  > yourself at this point,
>
> Er, what are people without access to PPAs doing building Python from
> a VCS checkout?

I don't see the link between access to PPA and building Python from
sources. I don't have administration privileges on any of my machine
at work. Adding PPA is simply not allowed at some places (PPA or
anything else which is not considered 'safe'), or too much of a
(bureaucratic) burden.

cheers,

David
___
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] Attention Bazaar mirror users

[Stephen J. Turnbull]

David Cournapeau writes:
 > On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw  wrote:

 > > In both those cases, you can use the PPA:

 > Please note that for many people in a corporate/university
 > environment, this is not an option. Granted, you can install it by
 > yourself at this point,

Er, what are people without access to PPAs doing building Python from
a VCS checkout?

Surely this is not a problem.

___
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] A suggestion: Do proto-PEPs in Google Docs

[Jeff Hall]

> Not that I'm expecting to be working on PEPs any time soon, but just as a
> different perspective, I would find the effort to open up Google docs to
> be a much higher barrier to doing some editing tweaks than the dvcs case.
> For the DVCS, I'd just write a little script that would (1) update (2)
> open the editor on the file (3) do the commit/push dance when the file
> was closed.  So for me it would be as easy as editing the file locally.
>
> So for my work style, a DVCS would be the biggest win.
>
> --RDM


That's funny because I would expect that for most people it's the exact
opposite... just create a gmail account... boom, done... I'm not necessarily
advocating that but just saying that IMO, most people will find google docs
to be the "fastest" and "easiest" solution.

-- 
Haikus are easy
Most make very little sense
Refrigerator
___
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] A suggestion: Do proto-PEPs in Google Docs

[rdmurray]

On Sat, 21 Feb 2009 at 12:56, Stephen J. Turnbull wrote:

(4) automatic saves of intermediate work
   -- at the tweak stage, the effort to save, commit, and push to a
  DVCS outweighs the effort to tweak, costing a lot of polish IME
   -- wikis don't do this, and I wonder whether people would be
  willing to save unpolished work, or leave it sitting in the
  browser "until later"


Not that I'm expecting to be working on PEPs any time soon, but just as a
different perspective, I would find the effort to open up Google docs to
be a much higher barrier to doing some editing tweaks than the dvcs case.
For the DVCS, I'd just write a little script that would (1) update (2)
open the editor on the file (3) do the commit/push dance when the file
was closed.  So for me it would be as easy as editing the file locally.

So for my work style, a DVCS would be the biggest win.

--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] Choosing a best practice solution for Python/extension modules

[Greg Ewing]

Daniel Stutzbach wrote:

No, I'm afraid Brett is quite right.  Globals are looked up when the 
function is executed, true, but they are looked up within the module 
that defined the function.


I was thinking you could fix that by going over the
imported functions and stuffing the current globals
into their func_globals, but unfortunately it's
read-only. :-(

>>> f.func_globals = g
Traceback (most recent call last):
  File "", line 1, in 
TypeError: readonly attribute

Is there a reason it couldn't be made writeable?

--
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] A suggestion: Do proto-PEPs in Google Docs

[Stephen J. Turnbull]

Summary:

Google Docs is easy to use, featureful, and here now.  Since AIUI the
PEPs eventually need to be hosted at python.org, I see Google Docs as
an immediate replacement for email transmission of early drafts of
PEPs, not as a permanent solution to PEP storage.

William Dode writes:

 > Isn't it the good oportunity to try a DVCS ?

I thought about that (and if I agreed I wouldn't have posted), but
there are reasons why Guido is "looking forward to" rather than
"calling for volunteers".  ISTM that a DVCS is just a wiki where you
can't find stuff unless you're told where it is.  It will take time.

What Google Docs provided for me was an infrastructure that
accomplished several useful services automatically, and stayed out of
my face (except for the lack of pruning of uninteresting revisions).

IMO the features we want are

(1) a permanent, easily computed URN for the draft document repo
-- DVCS can do this, with straightforward support from python.org
-- wiki can do this as a convention such as reserving PEP_0374 for
   final doc with PEP_0374_draft for development
(2) editor control over access to individual documents
-- AFAIK there's no mechanism for this at python.org, so to use a
   DVCS would require developing one
-- no mechanism for this in most wikis AFAIK (but ZWiki can do it)
-- it could be argued that the current convention of people
   staying out of each others' space would work, but what about
   non-committers (like me)?
(3) automatic merging of concurrent work
-- DVCS does this, but needs to be pushed afterward
-- most wikis can't do this in the framework of a single document,
   but you could organize the doc by sections for drafting
(4) automatic saves of intermediate work
-- at the tweak stage, the effort to save, commit, and push to a
   DVCS outweighs the effort to tweak, costing a lot of polish IME
-- wikis don't do this, and I wonder whether people would be
   willing to save unpolished work, or leave it sitting in the
   browser "until later"
(5) a recorded out of band channel for the editors (when plural) to
comment
-- "XXX" can work but when it's scutwork (eg, researching URLs or
   reworking sections to have parallel organization) it's ugly and
   distracting for non-editors to read; DVCS by itself provides no
   such medium, one would need to be developed
-- ditto wikis (although Wikipedia has its linked discussion
   channels, and this could be emulated on any wiki by a
   convention such as PEP_0374_talk, which would have the
   advantage that interested non-editors could look at the
   comments and contribute URLs and ideas, etc)
-- for non-trivial work, mail/IRC doesn't really cut it; you're
   more likely to make the indicated tweak if you're working on
   the document anyway, mail/IRC is likely to be focused elsewhere
   and the cost of changing focus too high to do it *now*

(1) and (2) are obvious, I think, and I don't know how much (3) really
matters when the editors are a small group.  But I was surprised by
how much (4), and (5) contributed to my experience working on PEP
0374.  Maybe Brett, Barry, or Alexandre would like to comment?

I note that the FSF had a rather complex system for its collaborative
development of 3d generation licenses.  I don't think that's necessary
for most PEPs.
___
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] Attention Bazaar mirror users

[David Cournapeau]

On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw  wrote:

> Adam Olsen reminds me that bzr 1.9 won't be supported by default in Ubuntu
> until Jaunty in April and Thomas reminds me that Debian still just has 1.5.
>
> In both those cases, you can use the PPA:
>
> https://launchpad.net/~bzr/+archive/ppa

Please note that for many people in a corporate/university
environment, this is not an option. Granted, you can install it by
yourself at this point,

David
___
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] Seeming unintended difference between list comprehensions and generator expressions...

[Nick Coghlan]

Josiah Carlson wrote:
>> Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
>> translated as:
>>
>>  def _lc(arg):
>>result = []
>>for i in arg:
>>  result.append(i*i)
>>return result
>>
>>   = _lc(x)
> 
> I was under the impression that in 3.x, it was equivalent to
> list() .  Which would explain the difference between 2.6 and
> 3.0.

Semantically, the two translations end up being the same. Actually
*implementing* it that way turned out to be unnecessarily slow: the
comprehensions instead create a normal function that builds the desired
type of object (list/set/dict) incrementally rather than building a
generator function and invoking it. The speed increase comes from being
able to skip the generator resume/yield overhead on each iteration.

>> Like any function scope inside a class namespace, the body of a genexp
>> (and, in 3.x, comprehension) doesn't have direct access to the class
>> namespace because classes don't play any part in the lexical scoping rules.
> 
> Indeed, though I had thought (if only briefly ;) ) that when executing
> non-definitions in the class body, it would behave similar to the a
> more or less equivalent function-based class factory

I think there may be a section of the language reference that describes
it in those terms. If there is, it should probably be changed, since it
gives misleading ideas about how the scoping works. Execution of a class
body is actually a bit more like using an exec statement than it is like
an implicit function definition.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] IO implementation: in C and Python?

[Steven D'Aprano]

Greg Ewing wrote:


Instead of defining things directly in foo.py, maybe it
should do

  try:
from cFoo import *
  except ImportError:
from pyFoo import *

Then the fast path will be taken if cFoo is available,
and you can directly import cFoo or pyFoo if you want.


For what it's worth, I like that naming convention better than the 
current conventions Foo/cFoo, Foo/_Foo.



--
Steven






___
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] Seeming unintended difference between list comprehensions and generator expressions...

[Josiah Carlson]

On Fri, Feb 20, 2009 at 3:14 PM, Nick Coghlan  wrote:
> Josiah Carlson wrote:
>> The behavior of 3.0 WRT list comprehensions behaving the same way as
>> generator expressions is expected, but why generator expressions
>> (generally) don't keep a reference to the class scope during execution
>> seems to be unintended.
>
> It's intended. While arguably not ideal, it would require some pretty
> major changes to the lexical scoping rules to make them behave any
> differently.
>
> The translation of (i*i for i in x) is conceptually along the lines of:
>
>  def _ge(arg):
>for i in arg:
>  yield i*i
>
>   = _ge(x)
>
> Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
> translated as:
>
>  def _lc(arg):
>result = []
>for i in arg:
>  result.append(i*i)
>return result
>
>   = _lc(x)

I was under the impression that in 3.x, it was equivalent to
list() .  Which would explain the difference between 2.6 and
3.0.

> Like any function scope inside a class namespace, the body of a genexp
> (and, in 3.x, comprehension) doesn't have direct access to the class
> namespace because classes don't play any part in the lexical scoping rules.

Indeed, though I had thought (if only briefly ;) ) that when executing
non-definitions in the class body, it would behave similar to the a
more or less equivalent function-based class factory

>>> def make_class(*bases):
... def make_class(fcn):
... dict = fcn()
... return type(object)(fcn.__name__, bases, dict)
... return make_class
...
>>> @make_class(object)
... def foo():
... x = {}
... x.update((i, x.get(i, None)) for i in xrange(10))
... return locals()
...
>>> foo

>>> foo.x
{0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7:
None, 8: None, 9: None}
>>>

But I was wrong ;)

Thank you for the help :)
 - Josiah

> Basically, if a generator or 3.x comprehension needs access to a value
> from a containing class scope anywhere other than the outermost
> iterator, then it needs to be put into a temporary function and given
> the extra value as an argument:
>
> .>> class C:
> ...   x = {}
> ...   def _init_constants(d, itr):
> ... d.update((i, d.get(i, None)) for i in itr)
> ...   _init_constants(x, range(10))
> ...   del _init_constants
> ...
> .>> C.x
> {0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7: None,
> 8: None, 9: None}
>
> (in this toy case, of course, it would be simpler to make the temporary
> function create and return the constants dictionary, but the above
> approach with multiple arguments being passed in applies more generally
> when you need to access multiple existing values from the class scope)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
>
___
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] Choosing a best practice solution for Python/extension modules

[Nick Coghlan]

Daniel Stutzbach wrote:
> On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan  > wrote:
> 
> Brett Cannon wrote:
> > If you import pickle and call pickle.A() you will get -13 which is not
> > what you are after.
> 
> Ah, you may want to think about that a bit more. There's a reason
> globals are looked up when they're used rather than when their function
> is defined. Even in your own example, _B isn't defined at all when you
> define A.
> 
> 
> No, I'm afraid Brett is quite right.  Globals are looked up when the
> function is executed, true, but they are looked up within the module
> that defined the function.  Functions defined in _pypickle would only
> call the _pypickle version of functions.

Oh, I see what you mean now. Looks like Brett's tracked substitution may
be the way to go then.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Choosing a best practice solution for Python/extension modules

[Daniel Stutzbach]

On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan  wrote:

> Brett Cannon wrote:
> > If you import pickle and call pickle.A() you will get -13 which is not
> > what you are after.
>
> Ah, you may want to think about that a bit more. There's a reason
> globals are looked up when they're used rather than when their function
> is defined. Even in your own example, _B isn't defined at all when you
> define A.
>

No, I'm afraid Brett is quite right.  Globals are looked up when the
function is executed, true, but they are looked up within the module that
defined the function.  Functions defined in _pypickle would only call the
_pypickle version of functions.

--
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] Choosing a best practice solution for Python/extension modules

[Nick Coghlan]

Brett Cannon wrote:
> But there is another issue with this: the pure Python code will never
> call the extension code because the globals will be bound to _pypickle
> and not _pickle. So if you have something like::
> 
>   # _pypickle
>   def A(): return _B()
>   def _B(): return -13
> 
>   # _pickle
>   def _B(): return 42
> 
>   # pickle
>   from _pypickle import *
>   try: from _pickle import *
>   except ImportError: pass
> 
> If you import pickle and call pickle.A() you will get -13 which is not
> what you are after.

Ah, you may want to think about that a bit more. There's a reason
globals are looked up when they're used rather than when their function
is defined. Even in your own example, _B isn't defined at all when you
define A.

There is a (real) related problem whereby the Python version will *use*
it's own globals if it actually tries to call any functions during the
import, but that's a problem shared by any "overwrite at the end of
import" approach to swapping in extension module versions of functions.

With appropriate __all__ definitions in the C extension modules, I don't
see anything wrong with Daniel's suggested approach. Note also that with
this approach _io.__all__ will give the details of what has been
overridden by the extension module, so it even still provides a decent
level of introspection support.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Seeming unintended difference between list comprehensions and generator expressions...

[Nick Coghlan]

Josiah Carlson wrote:
> The behavior of 3.0 WRT list comprehensions behaving the same way as
> generator expressions is expected, but why generator expressions
> (generally) don't keep a reference to the class scope during execution
> seems to be unintended.

It's intended. While arguably not ideal, it would require some pretty
major changes to the lexical scoping rules to make them behave any
differently.

The translation of (i*i for i in x) is conceptually along the lines of:

  def _ge(arg):
for i in arg:
  yield i*i

   = _ge(x)

Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
translated as:

  def _lc(arg):
result = []
for i in arg:
  result.append(i*i)
return result

   = _lc(x)

Like any function scope inside a class namespace, the body of a genexp
(and, in 3.x, comprehension) doesn't have direct access to the class
namespace because classes don't play any part in the lexical scoping rules.

Basically, if a generator or 3.x comprehension needs access to a value
from a containing class scope anywhere other than the outermost
iterator, then it needs to be put into a temporary function and given
the extra value as an argument:

.>> class C:
...   x = {}
...   def _init_constants(d, itr):
... d.update((i, d.get(i, None)) for i in itr)
...   _init_constants(x, range(10))
...   del _init_constants
...
.>> C.x
{0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7: None,
8: None, 9: None}

(in this toy case, of course, it would be simpler to make the temporary
function create and return the constants dictionary, but the above
approach with multiple arguments being passed in applies more generally
when you need to access multiple existing values from the class scope)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Seeming unintended difference between list comprehensions and generator expressions...

[Josiah Carlson]

Recently I found the need to generate some constants inside a class
body.  What I discovered was a bit unintuitive, and may not be
intended...

In 2.5 and 2.6:
>>> class foo:
... x = {}
... x.update((i, x.get(i, None)) for i in xrange(10))
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in foo
  File "", line 3, in 
NameError: global name 'x' is not defined
>>> class foo:
... x = {}
... x.update([(i, x.get(i, None)) for i in xrange(10)])
...
>>>

In 3.0:
>>> class foo():
... x = {}
... x.update((i, x.get(i, None)) for i in range(10))
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in foo
  File "", line 3, in 
NameError: global name 'x' is not defined
>>> class foo():
... x = {}
... x.update([(i, x.get(i, None)) for i in range(10)])
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in foo
  File "", line 3, in 
NameError: global name 'x' is not defined
>>>


The behavior of 3.0 WRT list comprehensions behaving the same way as
generator expressions is expected, but why generator expressions
(generally) don't keep a reference to the class scope during execution
seems to be unintended.

 - Josiah
___
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] IO implementation: in C and Python?

[Brett Cannon]

On Fri, Feb 20, 2009 at 13:15, Greg Ewing wrote:

> Steven D'Aprano wrote:
>
>  Currently, if I want to verify that (say) cFoo and Foo do the same thing,
>> or compare their speed, it's easy because I can import the modules
>> separately.
>>
>
> Also, won't foo.py be wasting time in most cases by
> defining python versions that get overwritten?
>

But that's only at import time and that is rather minor compared to other
execution costs.


>
> Instead of defining things directly in foo.py, maybe it
> should do
>
>  try:
>from cFoo import *
>  except ImportError:
>from pyFoo import *
>
> Then the fast path will be taken if cFoo is available,
> and you can directly import cFoo or pyFoo if you want.
>

See the other thread I started on discussing best practices for this, but
this won't work for modules where only part of the implementation has an
optimized version in an extension module (e.g. pickle).

-Brett
___
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] Choosing a best practice solution for Python/extension modules

[Greg Ewing]

Brett Cannon wrote:
So while this alleviates the worry 
above, it does mean that anything that gets rewritten needs to have a 
name that does not lead with an underscore for this to work.


You can use an __all__ list to explicitly say what
is to be exported.

--
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Fri, Feb 20, 2009 at 12:53, Aahz  wrote:

> On Fri, Feb 20, 2009, Brett Cannon wrote:
> > On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:
> >> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
> >> dan...@stutzbachenterprises.com> wrote:
> >>>
> >>> A slight change would make it work for modules where only key functions
> >>> have been rewritten.  For example, pickle.py could read:
> >>>
> >>> from _pypickle import *
> >>> try: from _pickle import *
> >>> except ImportError: pass
> >>
> >> True, although that still suffers from the problem of overwriting things
> >> like __name__, __file__, etc.
> >
> > Actually, I take that back; the IMPORT_STAR opcode doesn't pull in
> anything
> > starting with an underscore. So while this alleviates the worry above, it
> > does mean that anything that gets rewritten needs to have a name that
> does
> > not lead with an underscore for this to work. Is that really an
> acceptable
> > compromise for a simple solution like this?
>
> Doesn't __all__ control this?


If you define it, yes.

But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::

  # _pypickle
  def A(): return _B()
  def _B(): return -13

  # _pickle
  def _B(): return 42

  # pickle
  from _pypickle import *
  try: from _pickle import *
  except ImportError: pass

If you import pickle and call pickle.A() you will get -13 which is not what
you are after.

-Brett
___
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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 20, 2009, at 10:09 AM, Barry Warsaw wrote:

I've just upgraded the Bazaar mirrors on code.python.org to use bzr  
1.12.  We now have the opportunity to upgrade the repository format  
for better performance.  Because of the bzr-svn requirement, we need  
a "rich root" format.  Upgrading to 1.9-rich-root could buy us some  
significant performance improvements, but it will require all  
clients to upgrade to at least bzr 1.9, which was released on  
November 7, 2008.


I would like to do this upgrade.  If you are currently using the  
Bazaar mirrors at code.python.org and upgrading your client to at  
least bzr 1.9 would be a hardship, please contact me.  If I don't  
hear any objections by say Tuesday, I'll go ahead and do the repo  
upgrades.


Adam Olsen reminds me that bzr 1.9 won't be supported by default in  
Ubuntu until Jaunty in April and Thomas reminds me that Debian still  
just has 1.5.


In both those cases, you can use the PPA:

https://launchpad.net/~bzr/+archive/ppa

For Ubuntu machines, pick the distro version that's most appropriate.   
For Debian lenny, I use the Hardy PPA which seems to work fine.


Gentoo gives me 1.12 and MacPorts gives me 1.11.  I can't check any  
other distros.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZ8ewnEjvBPtnXfVAQLTEgP+IF8j1UJNqOt1uZ8L5QO+63tcwFdJ3z0X
k5ZJg3mJgMVdXMnYSgnO6fBC7R7/zVHFo++cNoitVk1++N+PqdPjGaZkD/4/Yu/I
gnUuEnS6aTU9at9rhrLXc310Qs8N9JmKOn9LWie2gCMOyiW/E95mMpH95Ze2jNrR
97p+uBzxtlQ=
=wdPZ
-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] IO implementation: in C and Python?

[Greg Ewing]

Steven D'Aprano wrote:

Currently, if I want to verify that (say) cFoo and Foo do the same 
thing, or compare their speed, it's easy because I can import the 
modules separately.


Also, won't foo.py be wasting time in most cases by
defining python versions that get overwritten?

Instead of defining things directly in foo.py, maybe it
should do

  try:
from cFoo import *
  except ImportError:
from pyFoo import *

Then the fast path will be taken if cFoo is available,
and you can directly import cFoo or pyFoo if you want.

--
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] Choosing a best practice solution for Python/extensionmodules

[Raymond Hettinger]

I don't have a particular solution mind.  Just wanted to reframe the question
to be a more general one about the controlling the selection between near
equivalent modules and extensions.  Some variant of the problem seems to
come-up in many different contexts.  No one best practice has emerged as
dominant. 
  - Original Message - 
  From: Brett Cannon 
  To: Raymond Hettinger 
  Cc: Python Dev 
  Sent: Friday, February 20, 2009 12:41 PM
  Subject: Re: [Python-Dev] Choosing a best practice solution for 
Python/extensionmodules





  On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger  wrote:

[Brett]


  With io getting rewritten as an extension module, I think it's time to 
try to come up with a good best practice scenario for how to be able to control 
when  a module uses a pure Python implementation and when it uses extension 
module optimizations. This is really only important for testing as if the 
extension is missing then the pure Python version is just flat-out used.



There is also need in some modules where the two are not exactly equivalent
or where there are multiple C extensions to choose from.  In PyYAML, there 
needs to be an easier way to switch parsers and emitters (i.e. LibYAML).
There are similar issues with xmlrpclib with the choice of parsers, 
marshallers,
and unmarshallers.  Possibly, the same mechanism can offer the user more
control over which dbm is used when there are several choices.

  So are you saying you want something that takes multiple arguments like 
``use_extension(py_name, *ext_names)``? Or are you wanting to go down the road 
of modules needing to define their own functions to use or unwind changes?

  -Brett


___
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] Choosing a best practice solution for Python/extension modules

[Aahz]

On Fri, Feb 20, 2009, Brett Cannon wrote:
> On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:
>> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
>> dan...@stutzbachenterprises.com> wrote:
>>>
>>> A slight change would make it work for modules where only key functions
>>> have been rewritten.  For example, pickle.py could read:
>>>
>>> from _pypickle import *
>>> try: from _pickle import *
>>> except ImportError: pass
>>
>> True, although that still suffers from the problem of overwriting things
>> like __name__, __file__, etc.
> 
> Actually, I take that back; the IMPORT_STAR opcode doesn't pull in anything
> starting with an underscore. So while this alleviates the worry above, it
> does mean that anything that gets rewritten needs to have a name that does
> not lead with an underscore for this to work. Is that really an acceptable
> compromise for a simple solution like this?

Doesn't __all__ control this?
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] Choosing a best practice solution for Python/extension modules

[Michael Foord]

Brett Cannon wrote:



On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach 
> wrote:


On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon mailto:br...@python.org>> wrote:

Now, from what I can tell, Antoine is suggesting having _pyio
and a _io and then io is simply:

try: from _io import *
except ImportError: from _pyio import *

That works for testing as you can then have test classes have
an attribute for the module to use and then create two
subclasses which set what module to use (kind of like how
test_warnings currently does it). But this only really works
for complete module replacements, not modules like pickle
where only key portions have been rewritten (which happens
more often than the complete rewrite).


A slight change would make it work for modules where only key
functions have been rewritten.  For example, pickle.py could read:

from _pypickle import *
try: from _pickle import *
except ImportError: pass


True, although that still suffers from the problem of overwriting 
things like __name__, __file__, etc.


What do you mean overwriting __name__ and __file__? Doing import * in a 
pure Python file doesn't override these.


Michael


-Brett



___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:

>
>
> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
> dan...@stutzbachenterprises.com> wrote:
>
>> On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon  wrote:
>>
>>> Now, from what I can tell, Antoine is suggesting having _pyio and a _io
>>> and then io is simply:
>>>
>>> try: from _io import *
>>> except ImportError: from _pyio import *
>>>
>>> That works for testing as you can then have test classes have an
>>> attribute for the module to use and then create two subclasses which set
>>> what module to use (kind of like how test_warnings currently does it). But
>>> this only really works for complete module replacements, not modules like
>>> pickle where only key portions have been rewritten (which happens more often
>>> than the complete rewrite).
>>>
>>
>> A slight change would make it work for modules where only key functions
>> have been rewritten.  For example, pickle.py could read:
>>
>> from _pypickle import *
>> try: from _pickle import *
>> except ImportError: pass
>>
>
> True, although that still suffers from the problem of overwriting things
> like __name__, __file__, etc.
>

Actually, I take that back; the IMPORT_STAR opcode doesn't pull in anything
starting with an underscore. So while this alleviates the worry above, it
does mean that anything that gets rewritten needs to have a name that does
not lead with an underscore for this to work. Is that really an acceptable
compromise for a simple solution like this?

-Brett
___
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] Choosing a best practice solution for Python/extensionmodules

[Brett Cannon]

On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger  wrote:

> [Brett]
>
>> With io getting rewritten as an extension module, I think it's time to try
>> to come up with a good best practice scenario for how to be able to control
>> when  a module uses a pure Python implementation and when it uses extension
>> module optimizations. This is really only important for testing as if the
>> extension is missing then the pure Python version is just flat-out used.
>>
>
> There is also need in some modules where the two are not exactly equivalent
> or where there are multiple C extensions to choose from.  In PyYAML, there
> needs to be an easier way to switch parsers and emitters (i.e. LibYAML).
> There are similar issues with xmlrpclib with the choice of parsers,
> marshallers,
> and unmarshallers.  Possibly, the same mechanism can offer the user more
> control over which dbm is used when there are several choices.


So are you saying you want something that takes multiple arguments like
``use_extension(py_name, *ext_names)``? Or are you wanting to go down the
road of modules needing to define their own functions to use or unwind
changes?

-Brett
___
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
dan...@stutzbachenterprises.com> wrote:

> On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon  wrote:
>
>> Now, from what I can tell, Antoine is suggesting having _pyio and a _io
>> and then io is simply:
>>
>> try: from _io import *
>> except ImportError: from _pyio import *
>>
>> That works for testing as you can then have test classes have an attribute
>> for the module to use and then create two subclasses which set what module
>> to use (kind of like how test_warnings currently does it). But this only
>> really works for complete module replacements, not modules like pickle where
>> only key portions have been rewritten (which happens more often than the
>> complete rewrite).
>>
>
> A slight change would make it work for modules where only key functions
> have been rewritten.  For example, pickle.py could read:
>
> from _pypickle import *
> try: from _pickle import *
> except ImportError: pass
>

True, although that still suffers from the problem of overwriting things
like __name__, __file__, etc.

-Brett
___
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] Choosing a best practice solution for Python/extensionmodules

[Raymond Hettinger]

[Brett]
With io getting rewritten as an extension module, I think it's time to try to 
come up with a good best practice scenario for how to be able to control 
when  a module uses a pure Python implementation and when it uses 
extension module optimizations. This is really only important for testing as 
if the extension is missing then the pure Python version is just flat-out used.


There is also need in some modules where the two are not exactly equivalent
or where there are multiple C extensions to choose from.  In PyYAML, there 
needs to be an easier way to switch parsers and emitters (i.e. LibYAML).

There are similar issues with xmlrpclib with the choice of parsers, marshallers,
and unmarshallers.  Possibly, the same mechanism can offer the user more
control over which dbm is used when there are several choices.


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] Choosing a best practice solution for Python/extension modules

[Daniel Stutzbach]

On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon  wrote:

> Now, from what I can tell, Antoine is suggesting having _pyio and a _io and
> then io is simply:
>
> try: from _io import *
> except ImportError: from _pyio import *
>
> That works for testing as you can then have test classes have an attribute
> for the module to use and then create two subclasses which set what module
> to use (kind of like how test_warnings currently does it). But this only
> really works for complete module replacements, not modules like pickle where
> only key portions have been rewritten (which happens more often than the
> complete rewrite).
>

A slight change would make it work for modules where only key functions have
been rewritten.  For example, pickle.py could read:

from _pypickle import *
try: from _pickle import *
except ImportError: pass

--
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] IO implementation: in C and Python?

[Terry Reedy]

Guido van Rossum wrote:

On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou  wrote:

Georg Brandl  gmx.net> writes:

I just hope everyone updates both versions when making changes to IO.

My proposal is just organizational, it is neutral in terms of whether or not the
Python version is correctly maintained.


I worry that with your proposal people are once again going to import
the pure Python version where they shouldn't. Maybe _pyio.py would
work though?


From a user perspective, continuity of 'import xyz' importing the 
currently best implementation is what is important, even if that 
switches back and forth.



We can hope that the IO lib *semantics* won't change too much in the future
(although there is an IMO legitimate request for a setblocking() method:
http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to
willingly use the Python version if the C version is available.


Hoping that modules won't evolve is futile. The concern for divergence
is real. Unit-testing both with the same tests might be the solution.


It seems to me that starting new features with a new test and 
prototyping in the Python version should mostly avoid the problem. 
Keeping the Python version allows non-C Pythoneers to contribute to such 
efforts.  (As opposed to fixing a C-only bug.)  If the Python version is 
ahead at the time of a release, the Python version could be reverted to 
being a master version that import the C version for most but not all 
functions.


tjr


___
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

With io getting rewritten as an extension module, I think it's time to try
to come up with a good best practice scenario for how to be able to control
when  a module uses a pure Python implementation and when it uses extension
module optimizations. This is really only important for testing as if the
extension is missing then the pure Python version is just flat-out used.

As an example, let's just go with pickle and the Pickler class, with _pickle
as the extension module.

If you look at examples in the standard library, their seems to be two
approaches. One is simply to blast the pure Python version:

class Pickler: pass

try: from _pickle import Pickler
except ImportError: pass

This is bad, though, as the only way to get a pure Python version for
testing is to clear out pickle and _pickle from sys.modules, put None in for
sys.modules['_pickle'] and then import pickle again. Yuck.

The other option is to hide the pure Python version::

class _Pickler: pass

try: from _pickle import Pickler  # pickle actualy imports *
except ImportError: Pickler = _Pickler

Better, but it still means that you are mucking around with hidden names and
it hard-codes what part of the module gets replaced (using import * gets
around this, but it also blasts things like __doc__ which you probably don't
want).

Now, from what I can tell, Antoine is suggesting having _pyio and a _io and
then io is simply:

try: from _io import *
except ImportError: from _pyio import *

That works for testing as you can then have test classes have an attribute
for the module to use and then create two subclasses which set what module
to use (kind of like how test_warnings currently does it). But this only
really works for complete module replacements, not modules like pickle where
only key portions have been rewritten (which happens more often than the
complete rewrite).

So here is my crazy idea that I came up with late last night (i.e. might not
make a lot of sense).

First, the module with the pure Python code is the main version. At the end
of that module, you make a function call: ``use_extension(__name__,
'_pickle')``. That function then does some "magic"::

def use_extension(py_name, ext_name):
try:
ext = importlib.import_module(ext_name)
except ImportError:
return
py = sys.modules[py_name]
swapped = {}
for name in (x for x in dir(ext) if not x.startswith('__')):
swapped[name] = getattr(py, name)
setattr(py, name, getattr(ext, name))
py.__extension__ = ext_name, swapped

You can also have an undo_extension('pickle') and it will unroll what was
changed. This makes choosing what version of a module to use very simple in
tests as it is a single function call in one direction or another. And doing
it this way also allows for different VMs to choose different things to
replace. For instance IronPython might decide that most of pickle is fine
and only want to change a single function with an extension; this solution
lets them do that without it being hard-coded in the standard library. At
worst other VMs simply need to refactor the Python code so that there is a
class or function that can be replaced.

So go ahead and tear this apart so that we can hopefully reach a consensus
that makes sense so that at least testing can easily be done.

-Brett
___
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] A suggestion: Do proto-PEPs in Google Docs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 20, 2009, at 1:16 PM, Guido van Rossum wrote:


Isn't it the good oportunity to try a DVCS ?


That was my original suggestion, yes, but Stephen Turnbull suggested
Google Docs instead.


I found Google docs to be both very helpful and very painful.  It was  
helpful because it supports multiple simultaneous editors pretty  
nicely.  It was painful because I was constantly battered by  
inexplicable bugs (e.g. at one point my ability to add comments just  
went away).  Maybe the closest home grown solution would be gobby,  
though the participants would have to manage persistency themselves.


A DVCS would probably work too, given these are almost entirely text  
files.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZ76AXEjvBPtnXfVAQIx5QQAs29FVEYDjbcvG2vLB3RtuuLOwahECP2Q
Yyxvz26mRgOeCX/4rfa4sI/r/dmyhbntGmvfqc/rE3Laej2G5vAqsBJfuhMM6xpx
Men3eypCKELK52nR3CQpUfODVu9ASYzNlezYkS2IEDfWRB95wBmLS9oKPwo55coi
9FSsI2rvyKQ=
=q+II
-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] A suggestion: Do proto-PEPs in Google Docs

[Guido van Rossum]

On Fri, Feb 20, 2009 at 10:02 AM, William Dode  wrote:
> On 20-02-2009, Guido van Rossum wrote:
>> On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou  wrote:
>>> Georg Brandl  gmx.net> writes:

 The Python Wiki should also be considered:

 * Comparing versions is easy, and versions are only saved on "Save"

 * It supports reStructuredText, so there is no need for conversion
   afterwards.
>>>
>>> And it's vendor-neutral :-)
>>
>> Touche.
>>
>> I still don't like wikis for this purpose very much -- a person
>> editing effectively grabs a lock on the whole file. (Wikimedia
>> addresses this to some extend by allowing sections to be edited, but I
>> don't see this feature in moinmoin yet, and I don't see us switching.)
>> Also there is no access control -- anyone who can create a login can
>> edit.
>
> Isn't it the good oportunity to try a DVCS ?

That was my original suggestion, yes, but Stephen Turnbull suggested
Google Docs instead.

-- 
--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] Summary of Python tracker Issues

[Daniel (ajax) Diniz]

Python tracker wrote:
>
> ACTIVITY SUMMARY (02/13/09 - 02/20/09)
> Python tracker at http://bugs.python.org/
[...]
>  2341 open (+55) / 14813 closed (+27) / 17154 total (+82)

I was about to cry foul, +27 closed? We closed so many issues last
week, how come?

Then, I realized the headings tell another story:

> Issues Created Or Reopened (84)
[...]
> Issues Now Closed (103)

Woot! We did it! More issues closed than opened, that's sweet :)

To celebrate, I'll have a two-day tracker sprint (probably Sunday and
Monday, a holiday here) to add a couple of search options and a view
for mass-updating issues.

During the sprint, you'll be able to get your feature requests for
and/or bug reports about the tracker at a considerably lower price, so
send them in :)

Daniel

P.S.: It seems the "2341 open (+55) / 14813 closed (+27) / 17154 total
(+82)" line is about "Issues Created" only :)
___
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] A suggestion: Do proto-PEPs in Google Docs

[William Dode]

On 20-02-2009, Guido van Rossum wrote:
> On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou  wrote:
>> Georg Brandl  gmx.net> writes:
>>>
>>> The Python Wiki should also be considered:
>>>
>>> * Comparing versions is easy, and versions are only saved on "Save"
>>>
>>> * It supports reStructuredText, so there is no need for conversion
>>>   afterwards.
>>
>> And it's vendor-neutral :-)
>
> Touche.
>
> I still don't like wikis for this purpose very much -- a person
> editing effectively grabs a lock on the whole file. (Wikimedia
> addresses this to some extend by allowing sections to be edited, but I
> don't see this feature in moinmoin yet, and I don't see us switching.)
> Also there is no access control -- anyone who can create a login can
> edit.

Isn't it the good oportunity to try a DVCS ?

-- 
William Dodé - http://flibuste.net
Informaticien Indépendant

___
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] A suggestion: Do proto-PEPs in Google Docs

[Guido van Rossum]

On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou  wrote:
> Georg Brandl  gmx.net> writes:
>>
>> The Python Wiki should also be considered:
>>
>> * Comparing versions is easy, and versions are only saved on "Save"
>>
>> * It supports reStructuredText, so there is no need for conversion
>>   afterwards.
>
> And it's vendor-neutral :-)

Touche.

I still don't like wikis for this purpose very much -- a person
editing effectively grabs a lock on the whole file. (Wikimedia
addresses this to some extend by allowing sections to be edited, but I
don't see this feature in moinmoin yet, and I don't see us switching.)
Also there is no access control -- anyone who can create a login can
edit.

-- 
--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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (02/13/09 - 02/20/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2341 open (+55) / 14813 closed (+27) / 17154 total (+82)

Open issues with patches:   817

Average duration of open issues: 656 days.
Median duration of open issues: 393 days.

Open Issues Breakdown
   open  2315 (+55)
pending26 ( +0)

Issues Created Or Reopened (84)
___

Document __instancecheck__ and __subclasscheck__ 02/13/09
   http://bugs.python.org/issue5250created  tjreedy   
   

contextlib.nested inconsistent with, well, nested with statement 02/13/09
   http://bugs.python.org/issue5251created  jwp   
   

2to3 should detect and delete import of removed statvfs module   02/13/09
   http://bugs.python.org/issue5252created  sjt   
   

os.environ.get() doesn't handle default value02/13/09
CLOSED http://bugs.python.org/issue5253created  marystern 
   

Formatting error in "findertools" header 02/13/09
   http://bugs.python.org/issue5254created  adamvan   
   

unicode support with os.readlink()   02/13/09
CLOSED http://bugs.python.org/issue5255created  scudette  
   

rlcompleter adds builtins when custom dict is used   02/14/09
   http://bugs.python.org/issue5256created  armandas  
   

test_zipfle and test_distutils write in the test directories 02/14/09
   http://bugs.python.org/issue5257created  tarek 
   

addpackage in site.py fails hard on badly formed .pth files  02/14/09
   http://bugs.python.org/issue5258created  jwheare   
   

smtplib is broken in Python3 02/14/09
   http://bugs.python.org/issue5259created  miwa  
   

longobject.c: minor fixes, cleanups and optimizations02/14/09
CLOSED http://bugs.python.org/issue5260created  marketdickinson   
   patch   

with lock fails on multiprocessing   02/14/09
   http://bugs.python.org/issue5261created  stepheng.lynch
   patch   

PythonLauncher considered harmfull   02/14/09
   http://bugs.python.org/issue5262created  ronaldoussoren
   

Error printing UTF-8 decoded text02/14/09
CLOSED http://bugs.python.org/issue5263created  grace 
   

StringIO failure when reading a chunk of text without newlines   02/14/09
   http://bugs.python.org/issue5264created  pitrou
   

StringIO can duplicate newlines in universal newlines mode   02/14/09
   http://bugs.python.org/issue5265created  pitrou
   

StringIO.read(n) does not enforce requested size in newline mode 02/14/09
   http://bugs.python.org/issue5266created  pitrou
   

Subversion problem with PythonLauncher after building 3.0 or 3.1 02/15/09
   http://bugs.python.org/issue5267created  MLModel   
   

VMSError not documented in Doc/library/exceptions.rst02/15/09
CLOSED http://bugs.python.org/issue5268created  MLModel   
   

OS X Installer: add options to specify universa

Re: [Python-Dev] IO implementation: in C and Python?

[Antoine Pitrou]

Guido van Rossum  python.org> writes:
> 
> I worry that with your proposal people are once again going to import
> the pure Python version where they shouldn't. Maybe _pyio.py would
> work though?

I'm ok with _pyio.py.

> Hoping that modules won't evolve is futile. The concern for divergence
> is real. Unit-testing both with the same tests might be the solution.

Yes, the same tests should be applied to both (modulo the few ones that test for
implementation-specific behaviour, e.g. the max_buffer_size stuff).

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] IO implementation: in C and Python?

[Guido van Rossum]

On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou  wrote:
> Georg Brandl  gmx.net> writes:
>>
>> I just hope everyone updates both versions when making changes to IO.
>
> My proposal is just organizational, it is neutral in terms of whether or not 
> the
> Python version is correctly maintained.

I worry that with your proposal people are once again going to import
the pure Python version where they shouldn't. Maybe _pyio.py would
work though?

> We can hope that the IO lib *semantics* won't change too much in the future
> (although there is an IMO legitimate request for a setblocking() method:
> http://bugs.python.org/issue949667). On the other hand, I don't expect anyone 
> to
> willingly use the Python version if the C version is available.

Hoping that modules won't evolve is futile. The concern for divergence
is real. Unit-testing both with the same tests might be the solution.

-- 
--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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've just upgraded the Bazaar mirrors on code.python.org to use bzr  
1.12.  We now have the opportunity to upgrade the repository format  
for better performance.  Because of the bzr-svn requirement, we need a  
"rich root" format.  Upgrading to 1.9-rich-root could buy us some  
significant performance improvements, but it will require all clients  
to upgrade to at least bzr 1.9, which was released on November 7, 2008.


I would like to do this upgrade.  If you are currently using the  
Bazaar mirrors at code.python.org and upgrading your client to at  
least bzr 1.9 would be a hardship, please contact me.  If I don't hear  
any objections by say Tuesday, I'll go ahead and do the repo upgrades.


Thanks,
Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZ7HwHEjvBPtnXfVAQIlxAQAk0ze8AHLY8aezrH35+Vv4tXloLy/FV1M
GHF2QzLBaV45Hr4d3i8Os32eaSvhWyFbCGeBZtm3q3pOwPy9ST/tDdI0XBwjd0M1
FV1Pg3v97IYeI6Pa1HKz0sKxbygACiZ9iQWde3b85zXEhsaZfXo7RiendmMkYift
Uvw0WWJZ1DU=
=sCFZ
-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] IO implementation: in C and Python?

[Lie Ryan]

On Thu, 19 Feb 2009 21:41:51 -0600, Benjamin Peterson wrote:

> As we prepare to merge the io-c branch, the question has come up [1]
> about the original Python implementation. Should it just be deleted in
> favor C version? The wish to maintain the two implementations together
> has been raised on the basis that Python is easier to experiment on and
> read (for other vm implementors).
> 
> Thoughts?
> 
> http://bugs.python.org/issue4565

How about making it an optional module instead, a compile flag when 
compiling python would determine whether the python or C or both versions 
of the libraries would be included with C-only as the default. 
Alternatively, if the compile flag was turned off and you want access to 
the python version, provide a downloadable pure python library (OS 
package manager could have something like python-lib-purepy or something 
similar). This would streamline python, and only people who want to mess 
around would download the purepy version.

___
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] IO implementation: in C and Python?

[Michael Foord]

Antoine Pitrou wrote:

Georg Brandl  gmx.net> writes:
  

I just hope everyone updates both versions when making changes to IO.



My proposal is just organizational, it is neutral in terms of whether or not the
Python version is correctly maintained.

We can hope that the IO lib *semantics* won't change too much in the future
(although there is an IMO legitimate request for a setblocking() method:
http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to
willingly use the Python version if the C version is available.


  


If they're functionally equivalent and single set of tests is run on 
both then -- assuming good tests -- breakage would be noticed...


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/fuzzyman%40voidspace.org.uk
  


___
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] IO implementation: in C and Python?

[Antoine Pitrou]

Georg Brandl  gmx.net> writes:
> 
> I just hope everyone updates both versions when making changes to IO.

My proposal is just organizational, it is neutral in terms of whether or not the
Python version is correctly maintained.

We can hope that the IO lib *semantics* won't change too much in the future
(although there is an IMO legitimate request for a setblocking() method:
http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to
willingly use the Python version if the C version is available.



___
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] IO implementation: in C and Python?

[Georg Brandl]

Antoine Pitrou schrieb:
> Benjamin Peterson  python.org> writes:
>> 
>> As we prepare to merge the io-c branch, the question has come up [1]
>> about the original Python implementation. Should it just be deleted in
>> favor C version? The wish to maintain the two implementations together
>> has been raised on the basis that Python is easier to experiment on
>> and read (for other vm implementors).
> 
> As I said, if it is the way forward, I suggest putting the Python version in a
> separate module (e.g. pyio.py), for the sake of clarity and also because it 
> may
> slightly improve startup times (the pure-Python module wouldn't get imported 
> in
> normal conditions).
> 
> Your thoughts?

I just hope everyone updates both versions when making changes to IO.

This is somewhat of a non-problem for small modules like bisect, or heapq.
For pickle and StringIO, we already saw how not to do it in 2.x -- hopefully
the new _pickle and pickle modules stay compatible.  IO is much larger a
piece of code...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] A suggestion: Do proto-PEPs in Google Docs

[Antoine Pitrou]

Georg Brandl  gmx.net> writes:
> 
> The Python Wiki should also be considered:
> 
> * Comparing versions is easy, and versions are only saved on "Save"
> 
> * It supports reStructuredText, so there is no need for conversion
>   afterwards.

And it's vendor-neutral :-)


___
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] A suggestion: Do proto-PEPs in Google Docs

[Georg Brandl]

Stephen J. Turnbull schrieb:

> FWIW, Google Docs is almost there.  Working with Brett et al on early
> drafts of PEP 0374 was easy and pleasant, and Google Docs gives
> control of access to the document to the editor, not the Subversion
> admin.  The ability to make comments that are not visible to
> non-editors was nice.  Now that it's in Subversion it's much less
> convenient for me (a non-committer).  I actually have to *decide* to
> work on it, rather than simply raising a browser window, hitting
> "refresh" and fixing a typo or two (then back to "day job" work).
> 
> The main problem with Google Docs is that is records a revision
> automatically every so often (good) but doesn't prune the automatic
> commits (possibly hard to do efficiently) OR mark user saves specially
> (easy to do).  This lack of marking "important" revisions makes the
> diff functionality kind of tedious.
> 
> I don't know how automatic the conversion to reST was, but the PEP in
> Subversion is a quite accurate conversion of the Google Doc version.

The Python Wiki should also be considered:

* Comparing versions is easy, and versions are only saved on "Save"

* It supports reStructuredText, so there is no need for conversion
  afterwards.

For PEPs drafted exclusively by committers, SVN is of course still the
best and simplest option.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] IO implementation: in C and Python?

[Antoine Pitrou]

Benjamin Peterson  python.org> writes:
> 
> As we prepare to merge the io-c branch, the question has come up [1]
> about the original Python implementation. Should it just be deleted in
> favor C version? The wish to maintain the two implementations together
> has been raised on the basis that Python is easier to experiment on
> and read (for other vm implementors).

As I said, if it is the way forward, I suggest putting the Python version in a
separate module (e.g. pyio.py), for the sake of clarity and also because it may
slightly improve startup times (the pure-Python module wouldn't get imported in
normal conditions).

Your thoughts?

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