Benjamin Peterson benjamin at 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
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
Georg Brandl g.brandl at 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 :-)
Antoine Pitrou schrieb:
Benjamin Peterson benjamin at 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
Georg Brandl g.brandl at 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
Antoine Pitrou wrote:
Georg Brandl g.brandl at 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
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
-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
On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou solip...@pitrou.net wrote:
Georg Brandl g.brandl at 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
Guido van Rossum guido at 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
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
On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote:
Georg Brandl g.brandl at 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
On 20-02-2009, Guido van Rossum wrote:
On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote:
Georg Brandl g.brandl at gmx.net writes:
The Python Wiki should also be considered:
* Comparing versions is easy, and versions are only saved on Save
* It supports
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
On Fri, Feb 20, 2009 at 10:02 AM, William Dode w...@flibuste.net wrote:
On 20-02-2009, Guido van Rossum wrote:
On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote:
Georg Brandl g.brandl at gmx.net writes:
The Python Wiki should also be considered:
* Comparing versions
-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
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
Guido van Rossum wrote:
On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou solip...@pitrou.net wrote:
Georg Brandl g.brandl at 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
On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon 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
[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
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 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
On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger pyt...@rcn.com 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
On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org 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 br...@python.org wrote:
Now, from what I can tell, Antoine is suggesting having _pyio
Brett Cannon wrote:
On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach
dan...@stutzbachenterprises.com
mailto:dan...@stutzbachenterprises.com wrote:
On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon br...@python.org
mailto:br...@python.org wrote:
Now, from what I can tell,
On Fri, Feb 20, 2009, Brett Cannon wrote:
On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org 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.
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
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
-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
On Fri, Feb 20, 2009 at 12:53, Aahz a...@pythoncraft.com wrote:
On Fri, Feb 20, 2009, Brett Cannon wrote:
On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org wrote:
On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
A slight change would
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
On Fri, Feb 20, 2009 at 13:15, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
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
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 stdin,
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,
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
On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan ncogh...@gmail.com 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
Daniel Stutzbach wrote:
On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com 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
On Fri, Feb 20, 2009 at 3:14 PM, Nick Coghlan ncogh...@gmail.com 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
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,
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
expr_value = _lc(x)
I was under the impression that in 3.x, it was equivalent to
On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org 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:
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
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
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
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)
David Cournapeau writes:
On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org 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
On Sat, Feb 21, 2009 at 3:52 PM, Stephen J. Turnbull step...@xemacs.org wrote:
David Cournapeau writes:
On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org wrote:
In both those cases, you can use the PPA:
Please note that for many people in a corporate/university
46 matches
Mail list logo
