Re: [Python-Dev] r85838 - python/branches/py3k/.gitignore

[anatoly techtonik]

On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw  wrote:
> On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
>
>>On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl  wrote:
>>> This looks more like "Add gitignore".  Do we really want to check in
>>> ignore files for every possible DVCS?
>>
>>No, but supporting the current big four open source ones (svn, hg,
>>bzr, git) seems reasonable enough.
>
> +1.  A couple of extra dot files never hurt anyone. :)

Why hg and bzr can't be tuned to understand .svnignore files?
--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new buffer in python2.7

[Ulrich Eckhardt]

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 example when doign network io, you would
> want code like this: Buffer = bytearray(10)
> Socket.recv_into(Buffer)
> Header = struct.unpack("i", memoryview(Buffer)[:4])[0]

Actually I would like code like
  s = socket()
  ...
  header = struct.unpack("i", s)

In other words, struct should interact with files/streams directly, instead of 
requiring me to first read a chunk who's size I manually have to determine 
etc.

Otherwise, I'm +1 on your suggestion, avoiding copying is a good thing.

Uli
(who's going to shut up, because he doesn't have a patch either)

-- 
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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] r85838 - python/branches/py3k/.gitignore

[Scott Dial]

On 10/27/2010 3:25 AM, anatoly techtonik wrote:
> On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw  wrote:
>> On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
>>
>>> On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl  wrote:
 This looks more like "Add gitignore".  Do we really want to check in
 ignore files for every possible DVCS?
>>>
>>> No, but supporting the current big four open source ones (svn, hg,
>>> bzr, git) seems reasonable enough.
>>
>> +1.  A couple of extra dot files never hurt anyone. :)
> 
> Why hg and bzr can't be tuned to understand .svnignore files?

Is there such a thing? I think you mean the svn:ignore metadata, which I
doubt you can get to through either mirror.

Even if you could, svn:ignore is pretty weak (only applies to the
directory it is set on and can only do glob patterns). .hgignore is
significantly more robust (and only has to be written to a single spot)
since matches entire paths and supports regex. Eventually, we'll need to
build an appropriate .hgignore file for the python tree anyways.

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

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
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] Issue 10194 - Adding a gc.remap() function

[Hrvoje Niksic]

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


There are other reasons as well (thread-safety), but I guess those don't 
really apply to python.  I guess one could defend the position that the 
tuple hasn't really "changed" if its elements merely get upgraded in 
this way, but it still feels wrong.


> Changing,
> for example, the contents of a tuple that a dictionary key references
> has the same effect as changing the identity of the tuple -- both
> modify the hash value of the key and thus invalidate the dictionary.
> The full reload processs needs to rehash collections invalidated by
> hash values changing, so we might as well modify the contents of
> tuples.

Do you also rehash when tuples of upgraded objects are used as dict keys?
___
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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[Raymond Hettinger]

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 unittest.py 
from just the module name.  Now, there are ten files and you have
no way to guess any of their names or how the author grouped
the functions and methods inside them.

Let's say that I'm mystified about the difference between
assertSameElements() and assertItemsEqual() and assertSetEqual().
So, I go to http://svn.python.org/view/python/branches/py3k/Lib/unittest/ .
Now, how do you know which file contains the source?  Formerly,
I could call-up the one source file and do a find.   Or, I could do 
OpenModule: unittest with IDLE and instantly see the source and
let the class browser analyze the structure of the file.  Now, that's
not possible either.  The source for those methods is now less discoverable.

In the unittest/case.py file, the safe_repr() function function is called over
40 times and it is not used in any other file.  So how do be benefit from
it being defined in the utils.py file?  ISTM, this saved nothing.  The case.py
file is over 1000 lines long and utils is 80.  How did we benefit from that 
split?  
For me, it makes it harder to read the code because I have to go looking
elsewhere for commonly called functions.

The unittest module grew from one file in Py2.6 to ten files and one directory 
with 2500 lines in Py2.7.  Was that a win?  I've spent time trying to
read through the changes and cannot follow it without having most of 
those ten files open in my editor.  For me, it's a PITA to read the code.
It doesn't help that the file split blew away the svn blame history, so I
have a harder time being about to tell what changed.

All that being said, I started this thread with:  "Packaging is not 
always wrong.  Maybe it was the right thing to do for unittest, maybe not".

The goal of the post was just to raise awareness that splitting modules
is not a straight win.  There are costs to discoverability and searchability.
It makes pyclbr less useful.  It makes svn viewer less useful.  And it loses
history.  

The split of unittest is a done deal.   Who knows, it may have been a net win.
Am just hoping that we all understand that it was not cost free.   My hope is 
that the splitting modules unnecessarily does not become a trend.
Packages should be the last tool we reach for, not the first.
In many cases, flat is better than nested.


Raymond

P.S.  I liked your qualifier, "if done well".  There's a lot in those three 
words.

___
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] r85838 - python/branches/py3k/.gitignore

[Georg Brandl]

Am 27.10.2010 09:25, schrieb anatoly techtonik:
> On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw  wrote:
>> On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
>>
>>>On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl  wrote:
 This looks more like "Add gitignore".  Do we really want to check in
 ignore files for every possible DVCS?
>>>
>>>No, but supporting the current big four open source ones (svn, hg,
>>>bzr, git) seems reasonable enough.
>>
>> +1.  A couple of extra dot files never hurt anyone. :)
> 
> Why hg and bzr can't be tuned to understand .svnignore files?

As Scott said, this isn't possible because there are no .svnignore files.

However, it would be nice to see those VCS handling ignores as a dotfile
in the repo root developing support for a single .ignore file...

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] new buffer in python2.7

[Antoine Pitrou]

On Wed, 27 Oct 2010 10:13:12 +0800
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.

That's true, and slightly unfortunate. It could be a reason for
switching to 3.1/3.2 :-)

> IMHO this is unfortunate.  For example when doign network io, you would want 
> code like this:
> Buffer = bytearray(10)
> Socket.recv_into(Buffer)
> Header = struct.unpack("i", memoryview(Buffer)[:4])[0]

This can be an useless micro-optimization.

People are often misled by the implicit analogy with C. In Python,
a "lazy slice" still allocates memory for a whole new PyObject (for
example a memoryview). So lazy slices are only a win if they are
actually big (because a raw memcpy() is fast).

Actually, lazy slices can be *slower* if they instantatiate an object
whose allocation is less optimized than the built-in bytes object's.

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

$ ./python -m timeit -s "x = b'x'*1" "x[:1000]"
100 loops, best of 3: 0.228 usec per loop
$ ./python -m timeit -s "x = memoryview(b'x'*1)" "x[:1000]"
1000 loops, best of 3: 0.151 usec per loop

So, as you see, creating a 100-byte slice from a 10 KB bytestring is
faster when using normal (eager) slices.
It becomes slower when creating a 1KB slice, but is still very fast
(under one microsecond).

> Not forgetggin the StringI object in cStringIO.
> IMHO, not accepting buffers by these objects can be consided a bug,
> that needs fixing.

It is often tempting to say that a "necessary" feature is a bug, but
it's a slippery slope. I would say it's only a bug when it's been
documented to work. I don't think StringIO objects have ever supported
the buffer protocol. In 3.2, though, you can use the
BytesIO.getbuffer() method:
http://docs.python.org/dev/library/io.html#io.BytesIO.getbuffer

(another reason to switch perhaps :-))

In any case, I think it should be the release manager's decision here.

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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[Antoine Pitrou]

On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolsky  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 good
> thing when the resulting modules can be used independently.  This
> helps users write leaner programs, reduces mental footprint of
> individual modules, etc, etc.   The split unittest module does not
> bring any such benefits.  It still presents a single "big-ball-of-mud"
> namespace, only rather than implemented in a single file, it is now
> swept in from eight different files.

Are you saying that it has become a pile of medium-sized balls of mud?
I would like to say thanks for the mud, Michael! It's high quality mud
for sure.

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] new buffer in python2.7

[Kristján Valur Jónsson]

-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" "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 memory allocations.  One for the 
ByteArray object itself, one for its cargo.  In total, more that 100 bytes.  In 
contrast, creating the MemoryView object requires only one allocation of a few 
dozen bytes.

The performance difference must come from some other weird overhead, such as 
initializing the new MemoryView object.

This would be pretty cool to profile using a proper profiler.  I'll see what my 
MS tools can come up with.

Meanwhile, a patch is in the tracker:

http://bugs.python.org/issue10212
Also this:
http://bugs.python.org/issue10211

There is a precedent of treating the failure to accept the Py_buffer interface 
as bugs in 2.7.  After all, this is a supported internal buffer.  See for 
example:
http://bugs.python.org/issue8104

K


___
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] new buffer in python2.7

[Antoine Pitrou]

> >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 memory allocations.  One for
> the ByteArray object itself, one for its cargo.  In total, more that
> 100 bytes.  In contrast, creating the MemoryView object requires only
> one allocation of a few dozen bytes.

It's not a bytearray object, it's a bytes object. It requires only a
single allocation since the data is allocated inline.
The memoryview object must also call getbuffer() again on the original
object.

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

[Python-Dev] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)

[Barry Warsaw]

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

Oh crap, Misc/python-mode.el is still there and way out of date.  Please, if
anybody's using it, switch to the latest one at

http://launchpad.net/python-mode

I'd like to delete the one in Misc for the py3k branch and replace it with a
README.python-mode that points to the new location.  What do y'all think about
doing the same for the Python 2.7 and 3.1 branches?

-Barry


signature.asc
Description: 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] new buffer in python2.7

[Kristján Valur Jónsson]

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 don't accept this as a matter of fact situation.

Btw, going to 3.2 isn't a real option for us any time soon.  A lot of companies 
probably find themselves in a similar situation.  This is why I spend so much 
effort applying some love to 2.7.  Most of the stuff I locally do to 2.7 I then 
contribute to python as 3.2 patches.  Someday they'll get backported, no doubt 
:)

K

-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 19:16
To: python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7


> >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 memory allocations.  One for 
> the ByteArray object itself, one for its cargo.  In total, more that
> 100 bytes.  In contrast, creating the MemoryView object requires only 
> one allocation of a few dozen bytes.

It's not a bytearray object, it's a bytes object. It requires only a single 
allocation since the data is allocated inline.
The memoryview object must also call getbuffer() again on the original object.

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/kristjan%40ccpgames.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue 10194 - Adding a gc.remap() function

[exarkun]

On 26 Oct, 11:31 pm, pinge...@yahoo.com wrote:
--- On Tue, 10/26/10, 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 ctypes wrapper for each C type in the Python
library, and then effectively reimplementing tp_traverse
in Python?


That's the idea, yes.

Jean-Paul




___
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/exarkun%40twistedmatrix.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new buffer in python2.7

[Antoine Pitrou]

On Wed, 27 Oct 2010 20:00:10 +0800
Kristján Valur Jónsson  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
well.

Of course, it you manipulate 1 KB slices or longer, it's different.

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] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)

[Benjamin Peterson]

2010/10/27 Barry Warsaw :
> 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 using.
>
> Oh crap, Misc/python-mode.el is still there and way out of date.  Please, if
> anybody's using it, switch to the latest one at
>
> http://launchpad.net/python-mode
>
> I'd like to delete the one in Misc for the py3k branch and replace it with a
> README.python-mode that points to the new location.  What do y'all think about
> doing the same for the Python 2.7 and 3.1 branches?

+1 and this should probably happen to the other editor related things in Misc.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)

[Éric Araujo]

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

___
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] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)

[Barry Warsaw]

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, Python support in Emacs is muddled.  GNU Emacs comes with python.el
which is an alternative implementation that shares some features with, but
also has differences to, python-mode.el.  Many of us hard-core Python Emacsers
prefer the latter, but sadly the FSF won't bundle it and a merge has proven
impossible so far.

I think I'll replace Misc/python-mode.el with Misc/README.Emacs that attempts
to discuss the issue in a neutral way.  I'll fix this in Python 2.7, 3.1, and
3.2.

Thanks,
-Barry


signature.asc
Description: 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

[Python-Dev] MemoryError... how much memory?

[Facundo Batista]

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 was asking when that happened.

So, I thought about doing something like:

char message[50];
...
self->buf = (char *)malloc(size);
if (!self->buf) {
  snprintf(message, 50, "out of memory (asked: %lld)", size);
  PyErr_SetString(PyExc_MemoryError, &message);


Is any inherent problem in doing this?

May it be a good idea to make it generic, like providing a
PyErr_MemoryError that could accept a message and a number, and stores
that number in the exception objects internals?

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[Nick Coghlan]

On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam  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 possibly documenting it and moving it to
http.servers for 3.3.

(The patch is attached to issue 2001 for anyone else that wants to
take a look at it)

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] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[Ron Adam]

On 10/27/2010 08:51 AM, Nick Coghlan wrote:

On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam  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 possibly documenting it and moving it to
http.servers for 3.3.

(The patch is attached to issue 2001 for anyone else that wants to
take a look at it)

Cheers,
Nick.


Fantastic!

Thanks Nick


___
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] new buffer in python2.7

[Kristján Valur Jónsson]

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   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_subscript5.857   1.051   40,51   7,27
_PyMemoryView_FromBuffer2.642   455 18,27   3,15
memory_dealloc  1.572   297 10,87   2,05
_PyObject_Malloc1.374   1.374   9,509,50
__PyObject_GC_New   1.256   236 8,691,63
_PySlice_New1.211   333 8,382,30
slice_dealloc   1.061   769 7,345,32
__PyObject_GC_Malloc1.022   293 7,072,03
bytearray_getbuffer 987 354 6,832,45
dup_buffer  932 932 6,456,45

Notice how  a Slice object is generated.  Then a PyObject_GetItem() is done.  
The salient code path is from apply_slice().  A slice object must be 
constructed and destroyed.

In contrast, when done on a string directly (or a bytes object in py3k) you go 
directly to PySequence_GetSlice.
Function Name   Inclusive Samples   Exclusive Samples   Inclusive 
Samples % Exclusive Samples %
apply_slice 3.888   502 48,44   6,25
_PySequence_GetSlice3.039   350 37,86   4,36
string_slice2.689   281 33,50   3,50
_PyString_FromStringAndSize 2.409   575 30,01   7,16
[MSVCR90.dll]   1.413   1.407   17,61   17,53
string_dealloc  467 150 5,821,87
_PyObject_Malloc379 379 4,724,72
_PyObject_Free  378 378 4,714,71
__PyEval_SliceIndex 347 347 4,324,32

(The measurements for the MemoryView above already contain some optimizations 
I've done on naïve functions).
This area is ripe for improvements.

K
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Kristján Valur Jónsson
Sent: Wednesday, October 27, 2010 20:00
To: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7

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 don't accept this as a matter of fact situation.

Btw, going to 3.2 isn't a real option for us any time soon.  A lot of companies 
probably find themselves in a similar situation.  This is why I spend so much 
effort applying some love to 2.7.  Most of the stuff I locally do to 2.7 I then 
contribute to python as 3.2 patches.  Someday they'll get backported, no doubt 
:)

K

-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 19:16
To: python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7


> >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 memory allocations.  One for 
> the ByteArray object itself, one for its cargo.  In total, more that
> 100 bytes.  In contrast, creating the MemoryView object requires only 
> one allocation of a few dozen bytes.

It's not a bytearray object, it's a bytes object. It requires only a single 
allocation since the data is allocated inline.
The memoryview object must also call getbuffer() again on the original object.

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/kristjan%40ccpgames.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new buffer in python2.7

[Kristján Valur Jónsson]

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


_PyMemoryView_FromBuffer


2.642


455


18,27


3,15


memory_dealloc


1.572


297


10,87


2,05


_PyObject_Malloc


1.374


1.374


9,50


9,50


__PyObject_GC_New


1.256


236


8,69


1,63


_PySlice_New


1.211


333


8,38


2,30


slice_dealloc


1.061


769


7,34


5,32


__PyObject_GC_Malloc


1.022


293


7,07


2,03


bytearray_getbuffer


987


354


6,83


2,45


dup_buffer


932


932


6,45


6,45




Function Name


Inclusive Samples


Exclusive Samples


Inclusive Samples %


Exclusive Samples %


apply_slice


3.888


502


48,44


6,25


_PySequence_GetSlice


3.039


350


37,86


4,36


string_slice


2.689


281


33,50


3,50


_PyString_FromStringAndSize


2.409


575


30,01


7,16


[MSVCR90.dll]


1.413


1.407


17,61


17,53


string_dealloc


467


150


5,82


1,87


_PyObject_Malloc


379


379


4,72


4,72


_PyObject_Free


378


378


4,71


4,71


__PyEval_SliceIndex


347


347


4,32


4,32








-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Kristján Valur Jónsson
Sent: Wednesday, October 27, 2010 20:00
To: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7



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 don't accept this as a matter of fact situation.



Btw, going to 3.2 isn't a real option for us any time soon.  A lot of companies 
probably find themselves in a similar situation.  This is why I spend so much 
effort applying some love to 2.7.  Most of the stuff I locally do to 2.7 I then 
contribute to python as 3.2 patches.  Someday they'll get backported, no doubt 
:)



K



-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 19:16

To: python-dev@python.org

Subject: Re: [Python-Dev] new buffer in python2.7





> >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 memory allocations.  One for

> the ByteArray object itself, one for its cargo.  In total, more that

> 100 bytes.  In contrast, creating the MemoryView object requires only

> one allocation of a few dozen bytes.



It's not a bytearray object, it's a bytes object. It requires only a single 
allocation since the data is allocated inline.

The memoryview object must also call getbuffer() again on the original object.



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/kristjan%40ccpgames.com



___

Python-Dev mailing list

Python-Dev@python.org

http://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new buffer in python2.7

[Kristján Valur Jónsson]

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 Behalf Of 
Antoine Pitrou
Sent: Wednesday, October 27, 2010 20:15
To: python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7



On Wed, 27 Oct 2010 20:00:10 +0800

Kristján Valur Jónsson mailto: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 well.



Of course, it you manipulate 1 KB slices or longer, it's different.



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/kristjan%40ccpgames.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

[R. David Murray]

On Tue, 26 Oct 2010 23:37:10 -0400, Barry Warsaw  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 to be split into several submodules.
> 
> And that seems perfectly reasonable to me, especially if the alternative were
> that Michael was so frustrated with a massive single .py file that it
> discouraged him from working on it.
> 
> If done well, a split can help improve the readability and discoverability of
> the code.  I shudder at the madness that a single email.py file would cause.

To put your mind at ease, Barry, I'd not want to do that either :)

But by (IMO good) design Generator, FeedParser, and Message are all
supposed to be independent (use only each other's public APIs).  And
Header can be (and is, I think) used without the other pieces of email,
as is true for other of the helper modules (base64mime, quoprimime, etc).
On the other hand, I have no clue why 'iterators.py' exists :)

The one that bugs me most, though, is MIME.  Combining all the mime
stuff into one file seems like it would be a big win (not that it's
possible, now).  What is the benefit of email.mime.text.MIMEText over
email.mime.MIMEText, when each of the files in the mime package consists
of a single subclass?

So, to clarify, like Raymond I'm not saying that packages are always bad.
I'm just saying that packages are also not always good; and, further,
that the number of lines of code in a file should, IMO, have nothing to
do with the decision as to whether or not to create a package.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Boštjan Mejak]

Forwarded conversation
Subject: Fixing zipfile.BadZipfile to zipfile.BadZipFile


From: *Boštjan Mejak* 
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 everything will comply to PEP 8 after you're done.

Since you're reorganizing, I have my own contribution. I have attached
a patch. The issue7351  was not
accepted at the time, so I hope you'll accept this fix now.

My point is that every class name in the module zipfile is like this:
- LargeZipFile
- ZipFile
- PyZipFile
.

.

.

So apply my patch to make the class name BadZipfile consistent to
other class names in the zipfile module and let it be named
BadZipFile. Thank you.



Best regards,

Boštjan Mejak


--
From: *Éric Araujo* 
Date: Sun, Oct 17, 2010 at 11:00 PM
To: python-dev@python.org
Cc: Boštjan Mejak 


Hello

(A bit of context: The original message comes from bug #2775, “Implement
PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.)
You may have missed the timeline: Most of the PEP 3108 changes have been
done before the first 3.x release went out.  Now that we have 3.1 out as
a stable and supported, we cannot reorganize and break compatibility
anymore.

(A note about PEP 8 compliance: Module names have been mostly fixed, but
not all function/method names, for example in logging and unittest.  If
I recall correctly, readability did not seem to make all the rewrites
worth it.)
> a patch. The issue7351  was not
I’ve just re-read the answers there and they are still valid.

Ezio and me: “Your patch need to include an alias (BadZipfile =
BadZipFile) to preserve compatibility with old pickles, as explains
msg95477.”

Antoine: “I don't think changing it for the sake of aesthetics is a good
deal given that many existing programs will have to be converted to the
new spelling.”

Regards


--
From: *Boštjan Mejak* 
Date: Mon, Oct 18, 2010 at 9:25 AM
To: Éric Araujo 


Shoot. Well, too bad. I thought Python is all about readability, but I think
you developers don't take it very seriously. If I was a developer, I would
certainly go to the trouble of all the rewrittes of
package/module/class/method/function names that do not comply to PEP 8 and
have them done by the time the first sub-version of Python 3 would be
released.

--
From: *Éric Araujo* 
Date: Mon, Oct 18, 2010 at 2:14 PM
To: Boštjan Mejak 


Hi

Could you repost your message to the mailing list, so that other people
can see it and eventually react?  Thanks.

(P.S. please make sure not to top-post on the mailing list)

Regards


--
From: *Éric Araujo* 
Date: Mon, Oct 18, 2010 at 2:45 PM
To: python-dev@python.org


Hello

[Sorry if this comes twice, connection errors here]
> a patch. The issue7351  was not
___
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/bostjan.mejak%40gmail.com

--
From: *Nick Coghlan* 
Date: Mon, Oct 18, 2010 at 3:13 PM
To: Éric Araujo 
Cc: python-dev@python.org


Correct. We went through this for one module that I recall (threading)
and that was annoying enough that we mostly left things alone after
that unless they were truly obnoxious.

For threading we were able to clean a lot of things up in the process
(such as adding properties where appropriate), but even so, we still
made sure all the old names continued to work.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

--
From: *Boštjan Mejak* 
Date: Mon, Oct 18, 2010 at 4:36 PM
To: Nick Coghlan 


Then please make an alias for this custom BadZipfile exception class.
Add  BadZipfile = BadZipFile  in the zipfile module.


--
From: *Boštjan Mejak* 
Date: Tue, Oct 19, 2010 at 10:34 PM
To: Nick Coghlan 


Sorry, let me correct myself:
 Add  BadZipFile = BadZipfile in the zipfile module.

Please add the above assignment statement in the right place to the zipfile
module and create an alias. Thank you.

--
From: *Boštjan Mejak* 
Date: Wed, Oct 20, 2010 at 11:13 PM
To: Nick Coghlan 


Ah, leave it as is. If in the future you will be able to rename BadZipfile
to BadZipFile, please do.

--
From: *Éric Araujo* 
Date: Wed, Oct 27, 2010 at 6:26 PM
To: python-dev 
Cc: Boštjan Mejak 


[Reply received off-list quoted here]

Le 18/10/2010 09:25, Boštjan Mejak a écrit :
Readability has to be balanced with other important things:
maintainability, discoverability, compatibility, rapidity and other
things ending in -ity.  I’m personally glad that readability gets a huge
place in the language definition itself (no braces, standard
indentation), I follow 98 % of PEP 8 where I can, and have learned to
accept that sometimes, a piece of code in the standard lib won’t 

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

> From: *Boštjan Mejak* 
> 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 account, note.  It is simply not possible
to break everyone’s pickles for a very minor inconsistency in one name.
 There is a wide Python world out there.

I’d like to suggest again that the time you want to give to Python
(thanks!) would be better employed on something else than BadZipfile.
For example, if you don’t think you can contribute code now, you could
suggest improvements for unclear sections in the documentation.  Recent
reports sent by beginners can be found on the archives of the
d...@python.org mailing list.

Regards

___
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] MemoryError... how much memory?

[Facundo Batista]

On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson  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 getting a MemoryError on a python you just opened in
the console. Think about a server with a month of uptime, where you
have all the memory fragmented, etc.


> Also, why is that useful?

It helps to determine why we're having some Memory Errors on our
long-lived server, how is the behaviour when that happens, etc.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] MemoryError... how much memory?

[exarkun]

On 07:09 pm, facundobati...@gmail.com wrote:
On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson 
 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 getting a MemoryError on a python you just opened in
the console. Think about a server with a month of uptime, where you
have all the memory fragmented, etc.

Also, why is that useful?


It helps to determine why we're having some Memory Errors on our
long-lived server, how is the behaviour when that happens, etc.


But... If you allocated all of your memory to some garbage, and then a 5 
byte string can't be allocated, you don't really care about the 5 byte 
string, you care about the garbage that's wasting your memory.


Tools like heapy will give you a lot of information.  Maybe it wouldn't 
hurt anyone to have more information in a MemoryError.  But I don't 
think it's going to help a lot either.  It's not the information that 
you're really interested in.


Jean-Paul
___
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] MemoryError... how much memory?

[Ben Finney]

Facundo Batista  writes:

> On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson  
> 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.

It also depends on how much is being requested. The caller knows that
amount, surely?

-- 
 \   “If you do not trust the source do not use this program.” |
  `\—Microsoft Vista security dialogue |
_o__)  |
Ben Finney

___
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] MemoryError... how much memory?

[Nick Coghlan]

On Thu, Oct 28, 2010 at 8:00 AM, Ben Finney  wrote:
> Facundo Batista  writes:
>
>> On Wed, Oct 27, 2010 at 12:05 PM, Benjamin Peterson  
>> 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.
>
> It also depends on how much is being requested. The caller knows that
> amount, surely?

For a server process, the MemoryError in the log won't always have the
context information showing what the values were in the calling
frames. The idea behind Facundo's request is similar to the reason why
we print the type names in a lot of TypeErrors.

If you see MemoryError (5 bytes), the things you go looking for are
very different from those you look for when you see MemoryError(1
gajillion bytes). (i.e. for the former, you look for a memory or other
resource leak, for the latter, you look for the reason your code is
trying to get 1 gajillion bytes from the OS). If a long-lived server
isn't crashing but is still getting MemoryError occasionally, problems
with specific oversized requests are much more likely than a general
resource leak (as those usually bring the whole process down
eventually).

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] Continuing 2.x

[Kristján Valur Jónsson]

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 model back in '57 in favor of new 
developments, it didn't spell the end for it.   The plant was sold to India and 
the Hindustan Ambassador 
continues to be developed and produced to this day.  It even has fuel injection.
The Morris Motor Company isn't around anymore.

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 without the usual stringent 
python quality assurance, buildbot support, release management and all that 
rigmarole.  Open-source it, if you will.
Svn.python.org already plays host to some other, less official, projects such 
as stackless, so why not this?

What do you think?

Kristján
___
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] Continuing 2.x

[Brian Curtin]

2010/10/27 Kristján Valur Jónsson 

>
> 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 without the usual
> stringent python quality assurance, buildbot support, release management and
> all that rigmarole.
>

Without that rigmarole I wouldn't consider using such a product. I also
don't know who would, and I think you'll have a hard time marketing a branch
that doesn't receive the attention that the others do.

I think it would be bad to associate an untested, free-for-all version of
Python with python.org.
___
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] Continuing 2.x

[Daniel Stutzbach]

2010/10/27 Kristján Valur Jónsson 

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

-- 
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] Continuing 2.x

[James Y Knight]

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”.  But must it be that way?
>  
> When Morris stopped producing the Oxford III model back in ’57 in favor of 
> new developments, it didn’t spell the end for it.   The plant was sold to 
> India and the Hindustan Ambassador continues to be developed and produced to 
> this day.  It even has fuel injection.
> The Morris Motor Company isn’t around anymore.
>  
> 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 without the usual 
> stringent python quality assurance, buildbot support, release management and 
> all that rigmarole.  Open-source it, if you will.
> Svn.python.org already plays host to some other, less official, projects such 
> as stackless, so why not this?

The python community has already decided many times over that Python2 is dead 
and Python3 is the future. So if you want to continue maintaining Python2, that 
means you need to fork it. I think you'd be best off doing so on your own 
infrastructure: convincing the python developers to support such a thing is 
quite unlikely, and furthermore, completely unnecessary.

Unlike the Oxford III, you don't need to be "sold" python2: it's open source, 
you can fork it without any official approval. So, just do it. I wish you best 
of luck, though: most unofficial forks die a lonely death. But, if enough 
people feel like you do, it could become successful.

But I really doubt anyone else is going to want to use it any python2 afterlife 
without stringent quality assurance, multi-platform support releases, and other 
rigamarole. You'd have to set up all that stuff for yourself if you possibly 
hope to attract users. I can't think of any possible use for an unreliably 
maintained version of python2...

James

___
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] Continuing 2.x

[Kristján Valur Jónsson]

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 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 want to be able to improve their platform and share those 
improvements with others.

James Y Knight said:
The python community has already decided many times over that Python2 is dead 
and Python3 is the future

But the patient is very much alive and kicking, no matter what the good doctor 
declares.  Python 2.x is in widespread use, with gazillion lines of .py code.  
In, there is another gazillion lines of .c and .cpp code both in extensions and 
embedding applications in use.  I’m quite happy with the community at large 
moving its development focus to 3.x but it is a bit harsh to deprive those left 
behind of the keys to the old house.

Cheers,
K

From: Daniel Stutzbach [mailto:dan...@stutzbachenterprises.com]
Sent: Thursday, October 28, 2010 11:45
To: Kristján Valur Jónsson
Cc: Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] Continuing 2.x

already plays host to some other, less official, projects such as stackless, so 
why not this?

___
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] Continuing 2.x

[Benjamin Peterson]

2010/10/27 Kristján Valur Jónsson :
> 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, I believe.
>
> Second, it would be an official nod

How would it "official" if you were the only one maintaining it?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Continuing 2.x

[Daniel Stutzbach]

2010/10/27 Kristján Valur Jónsson 

> 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 Mercurial, so svnmerge would not be helpful for
much longer.  On the plus side, since Mercurial is a Distributed Version
Control System, if you setup an unofficial continuation of Python 2 on the
host of your choice, it will be easy for you to pull patches from py3k.

-- 
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] Continuing 2.x

[Stephen J. Turnbull]

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 want to be
 > able to improve their platform and share those improvements with
 > others.

I don't see an insuperable problem in principle with hosting it on
python.org (for the practical reasons you give, it would be helpful),
but I think the repository belongs in /projects/v2-afterlife, not in
/projects/python.

 > I’m quite happy with the community at large moving its development
 > focus to 3.x but it is a bit harsh to deprive those left behind of
 > the keys to the old house.

If you mean the current set of 2.x branches in the repository, no,
that's not an "old" house, that's the same house we still live in.  It
contains the official history of each 2.x branch.  The continuing
development you propose is unofficial, and doesn't belong there.

___
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] http://bugs.python.org/issue9981

[Kristján Valur Jónsson]

I didn't get any response to this.  I know that it is a 2.7 patch, but I´m 
willing to port it to 3.x, if there is interest.
Supporting parallel compilation is a big win.
K
___
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] Continuing 2.x

[Georg Brandl]

Am 28.10.2010 06:13, schrieb Daniel Stutzbach:
> 2010/10/27 Kristján Valur Jónsson  >
> 
> 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 Mercurial, so svnmerge would not be helpful for 
> much
> longer.  On the plus side, since Mercurial is a Distributed Version Control
> System, if you setup an unofficial continuation of Python 2 on the host of 
> your
> choice, it will be easy for you to pull patches from py3k.

I believe we'll eventually have the ability to create user repos as well, so
that Kristjan can simply put his branch into one of these and still have it
on hg.python.org.

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