On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw ba...@python.org wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl g.bra...@gmx.net wrote:
This looks more like Add gitignore. Do we really want to check in
ignore files for every possible DVCS?
On Wednesday 27 October 2010, Kristján Valur Jónsson wrote:
Although 2.7 has the new buffer interface and memoryview objects, these are
widely not accepted in the built in modules. Examples are the structmodule,
some of the socketmodule apis, structmodule, etc.
IMHO this is unfortunate. For
On 10/27/2010 3:25 AM, anatoly techtonik wrote:
On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw ba...@python.org wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl g.bra...@gmx.net wrote:
This looks more like Add gitignore. Do we really want
On 10/26/2010 07:11 PM, Peter Ingebretson wrote:
The main argument is that preserving immutable objects increases the
complexity of remapping and does not actually solve many problems.
The primary reason for objects to be immutable is so that their
comparison operators and hash value can remain
On Oct 26, 2010, at 8:37 PM, Barry Warsaw wrote:
If done well, a split can help improve the readability and discoverability of
the code.
No doubt that is true. The problem is that splitting can also impair
discoverability.
When unittest was in one file, you knew the filename was
Am 27.10.2010 09:25, schrieb anatoly techtonik:
On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw ba...@python.org wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl g.bra...@gmx.net wrote:
This looks more like Add gitignore. Do we really want
On Wed, 27 Oct 2010 10:13:12 +0800
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Although 2.7 has the new buffer interface and memoryview
objects, these are widely not accepted in the built in modules.
That's true, and slightly unfortunate. It could be a reason for
switching to 3.1/3.2
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
While I appreciate your and Michael's eloquence, I don't really see
why five 400-line modules are necessarily easier to maintain than one
2000-line module. Splitting code into modules is certainly a
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Antoine Pitrou
Sent: Wednesday, October 27, 2010 18:36
Here are micro-benchmarks under 3.2:
$ ./python -m timeit -s x = b'x'*1
Here are micro-benchmarks under 3.2:
$ ./python -m timeit -s x = b'x'*1 x[:100]
1000 loops, best of 3: 0.134 usec per loop
$ ./python -m timeit -s x = memoryview(b'x'*1) x[:100]
1000 loops, best of 3: 0.151 usec per loop
That's weird. The greedy slice needs two
On Oct 27, 2010, at 03:54 AM, Scott Dial wrote:
As with others, I don't see the harm in committers who use those tools
adding and maintaining these files. Seems akin to having
Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of
supporting the tools that people are actually
Ah, well in 2.7 you don't have the luxury of a bytes object. A str() would be
similar in 2.7
Anyway, isn't the bytes object immutable? In that case, it is not a useful
target for a sock.recv_into() call.
Calling getbuffer on a bytearray or a bytes object should be really cheap, so I
still
On 26 Oct, 11:31 pm, pinge...@yahoo.com wrote:
--- On Tue, 10/26/10, exar...@twistedmatrix.com
exar...@twistedmatrix.com wrote:
This can be implemented with ctypes right now (I half did
it several years ago).
Jean-Paul
Is there a trick to doing it this way, or are you suggesting
building a
On Wed, 27 Oct 2010 20:00:10 +0800
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Calling getbuffer on a bytearray or a bytes object should
be really cheap, so I still don't accept this as a matter of fact
situation.
It *is* cheap. It's just that copying a short slice is dirt cheap as
2010/10/27 Barry Warsaw ba...@python.org:
On Oct 27, 2010, at 03:54 AM, Scott Dial wrote:
As with others, I don't see the harm in committers who use those tools
adding and maintaining these files. Seems akin to having
Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of
I remember a discussion about Vim files some time ago. I use Vim with
the files from Misc/Vim, which are up-to-date and more useful than the
files shipped with Vim. I don’t use plugins or external files, so I’m
-1 on removing Misc/Vim.
Regards
___
On Oct 27, 2010, at 02:54 PM, Éric Araujo wrote:
I remember a discussion about Vim files some time ago. I use Vim with
the files from Misc/Vim, which are up-to-date and more useful than the
files shipped with Vim. I don’t use plugins or external files, so I’m
-1 on removing Misc/Vim.
FWIW,
There are a lot of places where Python or modules do something like:
self-buf = (char *)malloc(size);
if (!self-buf) {
PyErr_SetString(PyExc_MemoryError, out of memory);
At job, we're having some MemoryErrors, and one thing that we would
love to know, if how much memory it
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam r...@ronadam.com wrote:
I still would like to know what your thoughts are concerning where to put,
and/or how to package, the simple threaded text server?
Given the time frame until beta 1, I'd suggest leaving it in pydoc for
now. We can look at
On 10/27/2010 08:51 AM, Nick Coghlan wrote:
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adamr...@ronadam.com wrote:
I still would like to know what your thoughts are concerning where to put,
and/or how to package, the simple threaded text server?
Given the time frame until beta 1, I'd suggest
So, I did some profiling. It turns out that the difference is not due to the
creation of the MemoryView object as such, but the much more complicated slice
handling for generic objects.
Here is the interesting part of the inclusive sample measurements for the
MemoryView:
Function Name
Sorry, here the tables properly formatted:
Function Name
Inclusive Samples
Exclusive Samples
Inclusive Samples %
Exclusive Samples %
apply_slice
8.997
468
62,23
3,24
_PyObject_GetItem
6.257
400
43,28
2,77
memory_subscript
5.857
1.051
40,51
7,27
Not cheap enough. There is no reason why creating another memoryview shouldn't
be as cheap as creating a string slice.
I'm investigating why.
K
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Tue, 26 Oct 2010 23:37:10 -0400, Barry Warsaw ba...@python.org wrote:
On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
I think it comes down to the preference of whoever works the most
actively on it. Michael is the most active contributor to unittest by
far, and I suppose he prefers it
Forwarded conversation
Subject: Fixing zipfile.BadZipfile to zipfile.BadZipFile
From: *Boštjan Mejak* bostjan.me...@gmail.com
Date: Fri, Oct 15, 2010 at 11:02 PM
To: python-dev@python.org
I am very glad you're reorganizing the Standard Library. Thumbs up! I
hope
From: *Boštjan Mejak* bostjan.me...@gmail.com
Since Python 3.2 accepts feature requests, take this fix as a feature
request. Please forget about preserving the compatibility with old pickles.
You can reopen #7351 as a feature request for 3.2. A serious proposal
has to take compatibility into
On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson benja...@python.org wrote:
Isn't this usually when you do something like [None]*2**300? In that
case, wouldn't you know how much memory you're requesting?
It could happen on any malloc. It depends on how much you have free.
Don't think on
On 07:09 pm, facundobati...@gmail.com wrote:
On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson
benja...@python.org wrote:
Isn't this usually when you do something like [None]*2**300? In that
case, wouldn't you know how much memory you're requesting?
It could happen on any malloc. It depends
Facundo Batista facundobati...@gmail.com writes:
On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson benja...@python.org
wrote:
Isn't this usually when you do something like [None]*2**300? In that
case, wouldn't you know how much memory you're requesting?
It could happen on any malloc.
On Thu, Oct 28, 2010 at 8:00 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Facundo Batista facundobati...@gmail.com writes:
On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson benja...@python.org
wrote:
Isn't this usually when you do something like [None]*2**300? In that
case,
Hello all.
So, python 2.7 is in bugfix only mode. 'trunk' is off limit. So, where does
one make improvements to the distinguished, and still very much alive, 2.x
series of Python?
The answer would seem to be one doesn't. But must it be that way?
When Morris stopped producing the Oxford III
2010/10/27 Kristján Valur Jónsson krist...@ccpgames.com
So, here is my suggestion:
Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for
submissions from people such as myself that use 2.7 on a regular basis and
are willing to give it some extra love. Host it there
2010/10/27 Kristján Valur Jónsson krist...@ccpgames.com
Svn.python.org already plays host to some other, less official, projects
such as stackless, so why not this?
What are the benefits of hosting such a project on svn.python.org instead of
somewhere else? (such as GitHub or BitBucket)
--
On Oct 27, 2010, at 10:22 PM, Kristján Valur Jónsson wrote:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does
one make improvements to the distinguished, and still very much alive, 2.x
series of Python?
The answer would seem to be “one doesn’t”.
Firstly, the ease of integrating changes. It would be possible to port those
bugfixes that release-27 gets, and also backport selected things from py3k
using the tools already in place such as svnmerge.
Second, it would be an official nod from the python community that, yes, we are
not
2010/10/27 Kristján Valur Jónsson krist...@ccpgames.com:
Firstly, the ease of integrating changes. It would be possible to port
those bugfixes that release-27 gets, and also backport selected things from
py3k using the tools already in place such as svnmerge.
svn lets you merge across repos,
2010/10/27 Kristján Valur Jónsson krist...@ccpgames.com
Firstly, the ease of integrating changes. It would be possible to port
those bugfixes that release-27 gets, and also backport selected things from
py3k using the tools already in place such as svnmerge.
py3k will soon be moving to
Kristján Valur Jónsson writes:
Second, it would be an official nod from the python community that,
yes, we are not actively developing 2.x anymore, we want to focus
on 3.x but we acknowledge that there are members of our community
that cannot, for various reasons, move to 3.x, but still
38 matches
Mail list logo
