Re: [Python-Dev] Attention Bazaar mirror users

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 op

Re: [Python-Dev] Attention Bazaar mirror users

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] Attention Bazaar mirror users

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

Re: [Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...

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 t

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

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

Re: [Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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 mo

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

Re: [Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...

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

[Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...

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 "", l

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

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 >

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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 _

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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 mod

Re: [Python-Dev] Attention Bazaar mirror users

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

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

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 defini

Re: [Python-Dev] Choosing a best practice solution for Python/extensionmodules

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 d

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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 th

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 ext

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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 Im

Re: [Python-Dev] Choosing a best practice solution for Python/extensionmodules

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

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

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

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

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 main

[Python-Dev] Choosing a best practice solution for Python/extension modules

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 th

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] Summary of Python tracker Issues

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 anot

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

[Python-Dev] Summary of Python tracker Issues

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

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

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

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

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 w

[Python-Dev] Attention Bazaar mirror users

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

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

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

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

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

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

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 f

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

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 bee

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

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 t

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

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 Pyth