Re: [Python-Dev] Continuing 2.x

[Dirkjan Ochtman]

On Thu, Oct 28, 2010 at 08:48, Georg Brandl  wrote:
> 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.

+1.

Cheers,

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

[Simon Cross]

2010/10/28 Kristján Valur Jónsson :
> But the patient is very much alive and kicking, no matter what the good
> doctor declares.

No no! 'E's pining!

Schiavo
Simon
___
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] Buildbot for AIX

[Sébastien Sablé]

Hi Martin,

I got no reply concerning those modifications to the buildbot script so 
that I could run 2 slaves on AIX.


I am able to spend some time at the moment on Python for AIX because we 
are migrating the product in my company from AIX 5.3 to AIX 6.1.
However once this is done, by the end of November, it will be more 
difficult for me to justify spending too much time on this builbot 
installation and on Python AIX bugs.


So it would be nice if I could get this slave running as soon as 
possible, so that I could spend a few more days solving some of the 
remaining issues on this platform.


regards

--
Sébastien Sablé



Le 15/10/2010 17:38, Sébastien Sablé a écrit :

Hi Martin,

I finally got the authorization to run some buildbot slaves on our AIX
servers.

I made some tests with a buildbot script as close as possible to what
you already use. Here is a patch that show the kind of modifications I
had to do in order to get the buildbot slave to correctly run on AIX.

It is also necessary to apply the patch provided in issue 9862 so that
the tests won't hang forever.

It also would help if the corrections provided in the following issues
could be commited: 4499, 678250, 730467.

Could you please take a look at those modifications in master.cfg,
provide me some password for the bot slaves and apply the corrections in
those issues?

Once this is done, I can run 2 buildbot slaves for AIX 6.1 and AIX 5.3
with build plans for gcc and xlc.

I can't guarantee that those bots will run forever, and I may have to
ask to schedule them only at night if the activity it generates on the
server appears to be too high.
But I think it could greatly help to improve the state of Python on AIX
(which is far from perfect at the moment).

regards

--
Sébastien Sablé



Le 20/09/2010 21:21, "Martin v. Löwis" a écrit :

Also could you provide me the master.cfg file (with obfuscated
passwords) that is used by the Python buildbot master or tell me if it
is in subversion somewhere?


Attached!

Regards,
Martin




___
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

[Victor Stinner]

Le jeudi 28 octobre 2010 05:12:09, James Y Knight a écrit :
> The python community has already decided many times over that Python2 is
> dead and Python3 is the future. ... 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.

*I* don't really care to Python 2.x anymore: I consider Python 2.7 as mature 
and very stable. New features can still be developed as Python or C extensions 
(browse the Python package index to get some examples).

I don't want to touch the Python2 core (the interpreter or the standard 
library) because it is too expensive (in time).

I prefer to focus on Python3 because Python3 core has a better design: strict 
separation between bytes and characters, no more short integer type, no more 
old style class, etc. It's easier to work on Python3 core. Backport a patch 
from Python3 to Python2 takes between 10 minutes and 3 hours (or maybe more on 
complex patches) because the function names, C macros, even file names, (...), 
has changed. And I don't know automatic tools to convert a Python3 patch to a 
Python2 patch (eg. a "3to2" tool, for patches). I don't want to spend 3 hours 
or more on a "dead project".

But when I find a bug in Python3, I immediatly check if it does also exist in 
Python2. And if both version are affected, I try to fix all versions (if it 
doesn't break the API).

-- 
Victor Stinner
http://www.haypocalc.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] Continuing 2.x

[Antoine Pitrou]

On Wed, 27 Oct 2010 23:05:37 -0500
Benjamin Peterson  wrote:
> 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.

And, most of all, we're soon switching to hg (real soon now :-)).

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

[Facundo Batista]

On Wed, Oct 27, 2010 at 8:27 PM, Nick Coghlan  wrote:

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

Very well explained, you're all right.

Furthermore, our server is fairly complex: we're using quite some
libraries to do different jobs, and one of the approaches (not the
only one) that we're taking to deal with this beast is to analyze its
memory-related behaviour from an external POV (thinking it as a black
box).

So, beyond it's arguable utility, do you think that having that
information could harm us in some way?

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?

[Nick Coghlan]

On Thu, Oct 28, 2010 at 9:14 PM, Facundo Batista
 wrote:
> So, beyond it's arguable utility, do you think that having that
> information could harm us in some way?

I think the idea is sound in principle, but may run into some
practical implementation problems due to special cases when raising
MemoryError. But creating a patch and putting on the tracker sounds
like something worth trying.

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

[Martin v. Löwis]

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

If you don't plan to make a release eventually, why would anybody care?

If you do plan to make a release eventually, please say so. That would
then be the point where I can point out that I will not be available
to make Windows binaries for such a release.

Also, if you do plan to make a release, please also indicate how
you would label it.

Regards,
Martin
___
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?

[Martin v. Löwis]

> Furthermore, our server is fairly complex: we're using quite some
> libraries to do different jobs, and one of the approaches (not the
> only one) that we're taking to deal with this beast is to analyze its
> memory-related behaviour from an external POV (thinking it as a black
> box).
> 
> So, beyond it's arguable utility, do you think that having that
> information could harm us in some way?

I think implementing it might do harm. When a memory error is raised,
you are typically out of memory, so allocating more memory might fail
(it just did). Therefore, allocating more objects or doing string
formatting will likely fail (unless the requested size is much larger
than the memory required for these operations).

So the chance increases that you trigger a fatal error.

Regards,
Martin
___
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

[Nick Coghlan]

2010/10/28 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 python-dev chose to switch our own focus for new features to 3.x
only, we were quite aware that a new group forming to continue with
2.8 was a definite possibility. If you do decide to go ahead with the
idea, I have a few suggestions:

1. Since the distinguishing feature is that this branch is a 2.x
version that will accept new features, in contrast to the python-dev
maintained bugfix-only 2.7 maintenance branch, please call the branch
something-or-other-2.8, rather than any form of 2.7.
2. Check with Benjamin how he plans to handle 2.7 maintenance
releases. If he plans to release from SVN, use that as your upstream
master. If 2.7.1 will instead be released from hg.python.org, wait
until the switch happens then use the relevant hg branch as the
upstream.
3. Choose your target audience early (if the target is only developers
with existing 2.x installations that can build their own version of
Python, then that simplifies release management significantly, since
you don't need to build binaries any more).
4. Decide whether or not you need a buildbot farm (this relates to
point 3: you may choose to limit your audience to people that are
happy to run the test suite themselves on their own target platforms
of interest).
5. Give some thought to how you will handle controversial design
decisions (since you won't have the fallback of appealing to the BDFL,
and feedback from python-dev is likely to be limited).
6. Asking for a python-org SIG mailing list may be a reasonable idea
as well (e.g. py2x-sig)
7. As 3.x usage grows, such a group may have a vested interest in
helping with 3to2 development as well as simplifying backporting of
3.x extension modules to 2.x.

A 2.8 branch that sells itself as being suitable only for people
willing to run their own builds and QA could definitely have a place
in the world (CCP at least would obviously find it useful, but I
wouldn't be surprised to find other companies that might consider
adopting such a branch if the benefits of the new features over the
official 2.7 releases were sufficiently compelling).

I don't believe anyone here is implacably opposed to the idea of 2.8
development continuing - it's just that the "collective we" of
python-dev isn't interested in making it happen, so a new crop of
developers will need to step up if it is going to become more than a
CCP-specific 2.x fork.

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

[Nick Coghlan]

On Thu, Oct 28, 2010 at 11:14 PM, "Martin v. Löwis"  wrote:
>> Furthermore, our server is fairly complex: we're using quite some
>> libraries to do different jobs, and one of the approaches (not the
>> only one) that we're taking to deal with this beast is to analyze its
>> memory-related behaviour from an external POV (thinking it as a black
>> box).
>>
>> So, beyond it's arguable utility, do you think that having that
>> information could harm us in some way?
>
> I think implementing it might do harm. When a memory error is raised,
> you are typically out of memory, so allocating more memory might fail
> (it just did). Therefore, allocating more objects or doing string
> formatting will likely fail (unless the requested size is much larger
> than the memory required for these operations).
>
> So the chance increases that you trigger a fatal error.

What Martin describes here is a more explicit description of what I
meant by "practical implementation problems" and "special cases when
raising MemoryError". However, I think thresholding the additional
error formatting to only kick in the requested amount of memory
exceeds a certain size would be an adequate safeguard without reducing
the utility in Facundo's use case (the pre-allocated instance can have
a generic error message saying an allocation of less than the
threshold value failed).

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

[Georg Brandl]

Am 28.10.2010 15:14, schrieb "Martin v. Löwis":
>> Furthermore, our server is fairly complex: we're using quite some
>> libraries to do different jobs, and one of the approaches (not the
>> only one) that we're taking to deal with this beast is to analyze its
>> memory-related behaviour from an external POV (thinking it as a black
>> box).
>> 
>> So, beyond it's arguable utility, do you think that having that
>> information could harm us in some way?
> 
> I think implementing it might do harm. When a memory error is raised,
> you are typically out of memory, so allocating more memory might fail
> (it just did). Therefore, allocating more objects or doing string
> formatting will likely fail (unless the requested size is much larger
> than the memory required for these operations).
> 
> So the chance increases that you trigger a fatal error.

Especially since we have a MemoryError instance preallocated to avoid
exactly this problem.

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

[Antoine Pitrou]

On Thu, 28 Oct 2010 15:54:50 +0200
Georg Brandl  wrote:
> Am 28.10.2010 15:14, schrieb "Martin v. Löwis":
> >> Furthermore, our server is fairly complex: we're using quite some
> >> libraries to do different jobs, and one of the approaches (not the
> >> only one) that we're taking to deal with this beast is to analyze its
> >> memory-related behaviour from an external POV (thinking it as a black
> >> box).
> >> 
> >> So, beyond it's arguable utility, do you think that having that
> >> information could harm us in some way?
> > 
> > I think implementing it might do harm. When a memory error is raised,
> > you are typically out of memory, so allocating more memory might fail
> > (it just did). Therefore, allocating more objects or doing string
> > formatting will likely fail (unless the requested size is much larger
> > than the memory required for these operations).
> > 
> > So the chance increases that you trigger a fatal error.
> 
> Especially since we have a MemoryError instance preallocated to avoid
> exactly this problem.

And which creates other problems of its own, such as keeping many
objects alive:
http://bugs.python.org/issue5437

;)

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] Buildbot for AIX

[Martin v. Löwis]

> I got no reply concerning those modifications to the buildbot script so
> that I could run 2 slaves on AIX.

I'm really really reluctant here. The proposed/requested changes are
fairly intrusive, even though AIX is just a minority platform. So I need
to find some time to rewrite them, which I haven't been able to, yet.

Regards,
Martin
___
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] Buildbot for AIX

[Antoine Pitrou]

On Fri, 15 Oct 2010 17:38:47 +0200
Sébastien Sablé  wrote:
> 
> Could you please take a look at those modifications in master.cfg, 
> provide me some password for the bot slaves and apply the corrections in 
> those issues?

About the master.cfg modifications: there should be no need for
separate environment variables. Instead, you should be able to specify
them as command-line arguments to ./configure, e.g.:

["--with-pydebug", "--without-computed-gotos", "CC=xlc",
 'OPT="-O2 -qmaxmem=18000"']

Can you check this works for you?

Also, there's no need to complicate the buildbot naming procedure.
You should be able to run several buildslaves on a single machine,
provided we give you separate credentials: one per compiler type.

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

[Barry Warsaw]

Who is the target audience for a Python 2.8?  What exactly would a Python 2.8
accomplish?

If Python 2.8 doesn't include new features, well, then what's the point?
Python 2.7 will be bug fix maintained for a long time, longer in fact than
previous Python 2 versions.  So a no-feature Python 2.8 can't be about
improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).

If Python 2.8 is about adding new features, then it has to be about
backporting those features from Python 3.  Adding new feature only to a Python
2.8 *isn't* Python, it's a fork of Python.  Of course, it's open source and
you're always allowed to do that, but you would need to be clear that this
isn't "Python".  IOW, a distro like Ubuntu would likely never package such a
thing as "/usr/bin/python".

What specific features that are showing up in say Python 3.2 are so compelling
that they need to show up in Python 2.8, *and* would compel folks who are
pinned to Python 2 to spend the resources to support it?  Porting and
certifying a code base against a new Python version is always work, sometimes
a significant amount of work.  What would be so compelling about a Python 2.8
that users, package authors, and distros would be willing to undertake this
work?

I'd *much* rather this enthusiasm be spent on making Python 3 rock, and in
porting third party code to Python 3.

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

[lutz]

Kristj?n Valur J?nsson  writes:
> 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.

Exactly.

Has anyone here analyzed download stats on py.org lately?
Please feel free to prove me wrong, but by my reckoning,
and at least for Windows MSI installer files, people are 
still downloading Python 2.X roughly 3 to 4 times more often
than Python 3.X today, some 2 years after 3.X's release.

This is from http://www.python.org/webstats for September
and October, based on file size and bytes fetched for all
significant versions.  As one metric, roughly 439K people
fetched 2.X MSI files in September, and 124K went for 3.X.

Granted, there are plenty of variables such as preinstalled
Pythons on Macs and Linux, though many would tend to skew 
2.X dominance even higher.  Moreover, downloads may be more
reflective of new users, than existing users who are likely 
in the 2.X camp.  But clearly, the 2.X patient is hardly dead;
it still reflects the vast majority of the Python world today.

I hope 3.X use expands; in fact, I've bet the future of at 
least one book on it.  And even 1/4 of new users seems a
large enough subset to care about too.  But one can't help 
but wonder if most of the development community is focused 
on some imaginary future user base, at the expense of the 
much larger current user base.  Then again, there's still
plenty of Fortran77 code out there, so...

--Mark Lutz  (http://learning-python.com, http://rmi.net/~lutz)



___
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

[exarkun]

On 04:04 pm, ba...@python.org wrote:


I'd *much* rather this enthusiasm be spent on making Python 3 rock, and 
in

porting third party code to Python 3.


Enthusiasm isn't fungible.

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

[Barry Warsaw]

On Oct 28, 2010, at 04:17 PM, exar...@twistedmatrix.com wrote:

>On 04:04 pm, ba...@python.org wrote:
>>
>>I'd *much* rather this enthusiasm be spent on making Python 3 rock, and >in
>>porting third party code to Python 3.
>
>Enthusiasm isn't fungible.

Maybe so, but I think it's actually more fun to be working on something other
people will actually use. ;)

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

[Georg Brandl]

Am 28.10.2010 18:07, schrieb l...@rmi.net:
> Kristj?n Valur J?nsson  writes:
>> 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.
> 
> Exactly.
> 
> Has anyone here analyzed download stats on py.org lately?
> Please feel free to prove me wrong, but by my reckoning,
> and at least for Windows MSI installer files, people are 
> still downloading Python 2.X roughly 3 to 4 times more often
> than Python 3.X today, some 2 years after 3.X's release.

This doesn't worry me too much.  Just look at how long it usually takes for
2.(x+1) to actually get used over 2.x, or even 2.(x-1) -- and it's fairly
obvious that this time will be a bit longer for 2.x -> 3.x.

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

[Bill Janssen]

Kristján Valur Jónsson  wrote:

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

Though I'm not personally convinced it's a good idea, I can see where
some could find it useful.

> Host it there
> without the usual stringent python quality assurance, buildbot
> support, release management and all that rigmarole.  Open-source it,
> if you will.

No real need to go that far, I think.  The tests after all are part of
the source tree, buildbots are still running them, etc.  And if the
buildbot master stops doing that, there are community buildbots for
testing things like this.  Release management is going to happen one
way or another.

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

[Alexander Belopolsky]

On Thu, Oct 28, 2010 at 12:07 PM,   wrote:
..
> Has anyone here analyzed download stats on py.org lately?
> Please feel free to prove me wrong, but by my reckoning,
> and at least for Windows MSI installer files, people are
> still downloading Python 2.X roughly 3 to 4 times more often
> than Python 3.X today, some 2 years after 3.X's release.
>

I don't think this is a fair comparison.  At least not until 3.2 final
is out for some time.   Note that 2.7 is at the moment the latest
stable release and 3.x releases so far have suffered from developers'
attention divided between 2.x and 3.x series.  I believe the trend
will change with 3.2 release.
___
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

[Barry Warsaw]

On Oct 28, 2010, at 04:07 PM, l...@rmi.net wrote:

>I hope 3.X use expands; in fact, I've bet the future of at 
>least one book on it.  And even 1/4 of new users seems a
>large enough subset to care about too.  But one can't help 
>but wonder if most of the development community is focused 
>on some imaginary future user base, at the expense of the 
>much larger current user base.  Then again, there's still
>plenty of Fortran77 code out there, so...

Python 2 will live on for a long time.  Other than promising to bug-fix
maintain Python 2.7 for much longer than usual, which we've already done, what
specifically should we do?  A no-new-feature Python 2.8 doesn't make sense,
and I'm not convinced that a new-feature Python 2.8 really helps folks who are
stuck on Python 2 for whatever reason.

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

[R. David Murray]

On Thu, 28 Oct 2010 16:07:50 -, l...@rmi.net wrote:
> I hope 3.X use expands; in fact, I've bet the future of at 
> least one book on it.  And even 1/4 of new users seems a
> large enough subset to care about too.  But one can't help 
> but wonder if most of the development community is focused 
> on some imaginary future user base, at the expense of the 
> much larger current user base.  Then again, there's still
> plenty of Fortran77 code out there, so...

Given the existing rate of Python3 adoption (which by the signs we see in
the tracker is increasing), you can hardly call the user base imaginary.
Further, Python development (and development in general!) is *always*
focused on a "future user base" in the sense you are using it, not the
"current user base".  That's pretty much part of the definition of
development :) 

But the reality is that almost all those Python2 users are future Python3
users, so they *are* the future user base.  And like Georg said, as far
as we can see Python3 uptake is pretty much right on the schedule that
was predicted when it was first released.

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

Re: [Python-Dev] Continuing 2.x

[Ian Bicking]

On Thu, Oct 28, 2010 at 9:04 AM, Barry Warsaw  wrote:

> Who is the target audience for a Python 2.8?  What exactly would a Python
> 2.8
> accomplish?
>
> If Python 2.8 doesn't include new features, well, then what's the point?
> Python 2.7 will be bug fix maintained for a long time, longer in fact than
> previous Python 2 versions.  So a no-feature Python 2.8 can't be about
> improving Python 2 stability over time (i.e. just fix the bug in Python
> 2.7).
>
> If Python 2.8 is about adding new features, then it has to be about
> backporting those features from Python 3.  Adding new feature only to a
> Python
> 2.8 *isn't* Python, it's a fork of Python.


Thinking about language features and core type this seems reasonable, but
with the standard library this seems less reasonable -- there's lots of
conservative changes to the standard library which aren't bug fixes, and the
more the standard library is out of sync between Python 2 and 3 the harder
maintaining software that works across those versions becomes.

Though one opportunity is to distribute modules from the standard library
under new names (e.g., unittest2), and at least in Python 2 you don't have
to do anything fancy or worry about the standard library has catching up to
the standard library forked module.

Library installers seem particularly apropos to this discussion, as everyone
seems excited to get them into the standard library and distributed with
Python, but with the current plan that will never happen with Python 2.

-- 
Ian Bicking  |  http://blog.ianbicking.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

[geremy condra]

On Wed, Oct 27, 2010 at 11:48 PM, Georg Brandl  wrote:
> 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

Huge +1 from me- I think this would be an excellent development.

Geremy Condra

PS- this should not be taken as an endorsement of the original
proposal, I simply don't use 2.x anymore and don't have an opinion on
it.
___
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]

Barry Warsaw writes:

 > Maybe so, but I think it's actually more fun to be working on
 > something other people will actually use. ;)

I think that the point is that the people will be doing this are
supporting software to pay for Johnny's piano lessons, not for
personal pleasure.  I imagine many, perhaps most, of them would rather
be coding and/or Python 3, too!

___
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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/28/2010 12:04 PM, Barry Warsaw wrote:

> Who is the target audience for a Python 2.8?  What exactly would a Python 2.8
> accomplish?
> 
> If Python 2.8 doesn't include new features, well, then what's the point?
> Python 2.7 will be bug fix maintained for a long time, longer in fact than
> previous Python 2 versions.  So a no-feature Python 2.8 can't be about
> improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
> 
> If Python 2.8 is about adding new features, then it has to be about
> backporting those features from Python 3.

I think that assumption may not be warranted.  If the current core folks
are focused only on developing Python 3, but others are working on a
notional 2.8, there is no necessary correlation any longer between the
two.  In particular, the judgement of the current core about various
tradeoffs in the Python 2 codebase won't be as relevant as it has been,
in particular because the overarching drive (add features / warnings
etc. which ease / encourage migration to Python 3) won't be in the
forefront of the new group's perspective.

>  Adding new feature only to a Python 2.8 *isn't* Python, it's a fork of 
> Python.

- From the perspective of this notional group of 2.8 developers, that
particular horse is out of the barn already:  it is called "Python 3".

>  Of course, it's open source and
> you're always allowed to do that, but you would need to be clear that this
> isn't "Python".

Pythonic is in the eye of the beholder.

> IOW, a distro like Ubuntu would likely never package such a
> thing as "/usr/bin/python".

For the set of folks who might care about the retro-forked 2.8, I doubt
that will matter.  For instance, although I'm not (necessarily) in that
camp, I choose not to use the system python for any app I deploy:  the
system packagers make tradeoffs which are inappropriate for my
applications, and I don't want to risk having a sysadmin-driven update
break them.  I always build Python from source and install under '/opt'.

Distros who desire to package not-yet-or-maybe-ever-ported-to-Python-3
apps will have to make their own choices.  Perhaps the retro-fork is
available via a PPA or "extras" repository, and installs explictly as
'/usr/bin/python2'.

> What specific features that are showing up in say Python 3.2 are so compelling
> that they need to show up in Python 2.8, *and* would compel folks who are
> pinned to Python 2 to spend the resources to support it?  Porting and
> certifying a code base against a new Python version is always work, sometimes
> a significant amount of work.  What would be so compelling about a Python 2.8
> that users, package authors, and distros would be willing to undertake this
> work?

I can imagine features (and particularly library changes) which aren't
even on the radar for Python 3, which provide real value to to folks
maintaining the notional 2.8, and hence which get developed there first;
 perhaps they get forward-ported later to a future Python 3 release.

> I'd *much* rather this enthusiasm be spent on making Python 3 rock, and in
> porting third party code to Python 3.

Sure you would -- you're already invested there.  I would like to be
there, but can't take off the several months required to port the whole
stack under my own code.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzJtxMACgkQ+gerLs4ltQ7iTACglNlfMd+zEx0isiTAvTECGT6h
VccAmgMHBMGkLQaqONU9CC5wY9uso63V
=Qpxy
-END PGP SIGNATURE-

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

Re: [Python-Dev] Continuing 2.x

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/28/2010 09:33 AM, Nick Coghlan wrote:
> 2010/10/28 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 python-dev chose to switch our own focus for new features to 3.x
> only, we were quite aware that a new group forming to continue with
> 2.8 was a definite possibility. If you do decide to go ahead with the
> idea, I have a few suggestions:
> 
> 1. Since the distinguishing feature is that this branch is a 2.x
> version that will accept new features, in contrast to the python-dev
> maintained bugfix-only 2.7 maintenance branch, please call the branch
> something-or-other-2.8, rather than any form of 2.7.
> 2. Check with Benjamin how he plans to handle 2.7 maintenance
> releases. If he plans to release from SVN, use that as your upstream
> master. If 2.7.1 will instead be released from hg.python.org, wait
> until the switch happens then use the relevant hg branch as the
> upstream.
> 3. Choose your target audience early (if the target is only developers
> with existing 2.x installations that can build their own version of
> Python, then that simplifies release management significantly, since
> you don't need to build binaries any more).
> 4. Decide whether or not you need a buildbot farm (this relates to
> point 3: you may choose to limit your audience to people that are
> happy to run the test suite themselves on their own target platforms
> of interest).
> 5. Give some thought to how you will handle controversial design
> decisions (since you won't have the fallback of appealing to the BDFL,
> and feedback from python-dev is likely to be limited).
> 6. Asking for a python-org SIG mailing list may be a reasonable idea
> as well (e.g. py2x-sig)
> 7. As 3.x usage grows, such a group may have a vested interest in
> helping with 3to2 development as well as simplifying backporting of
> 3.x extension modules to 2.x.
> 
> A 2.8 branch that sells itself as being suitable only for people
> willing to run their own builds and QA could definitely have a place
> in the world (CCP at least would obviously find it useful, but I
> wouldn't be surprised to find other companies that might consider
> adopting such a branch if the benefits of the new features over the
> official 2.7 releases were sufficiently compelling).
> 
> I don't believe anyone here is implacably opposed to the idea of 2.8
> development continuing - it's just that the "collective we" of
> python-dev isn't interested in making it happen, so a new crop of
> developers will need to step up if it is going to become more than a
> CCP-specific 2.x fork.

Thanks for the helpful guidance to such prospective volunteers!


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzJtxgACgkQ+gerLs4ltQ6OKgCcCH1Wt0Bg1COSqMdBm7whSL8H
JOMAnRqA9jy8eazZnTMV+Q/gvKNX7zLb
=yu2I
-END PGP SIGNATURE-

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

Re: [Python-Dev] Continuing 2.x

[Antoine Pitrou]

On Thu, 28 Oct 2010 10:25:28 -0700
Ian Bicking  wrote:
> 
> Thinking about language features and core type this seems reasonable, but
> with the standard library this seems less reasonable -- there's lots of
> conservative changes to the standard library which aren't bug fixes, and the
> more the standard library is out of sync between Python 2 and 3 the harder
> maintaining software that works across those versions becomes.

For the same reason that new features only get in 3.2 and not in 3.1 or
2.7, for example.

I know people would like both stability *and* new features in the same
codebase, but that doesn't work. There's a reason most decently managed
software projects have separate bugfix branches and feature branches.
That's the same old discussion and it isn't specific to Python.

(and, believe me, not having to backport new 3.x features to the 2.x
branch makes our work much easier than it was; people generally seem
to underestimate the amount of care needed for such things, especially
in areas where 2.x is significantly more complex - old-style classes,
two parallel buffer APIs, misleading implicit conversions...)

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

[Michael Foord]

On 28/10/2010 13:20, R. David Murray wrote:

On Thu, 28 Oct 2010 16:07:50 -, l...@rmi.net wrote:

I hope 3.X use expands; in fact, I've bet the future of at
least one book on it.  And even 1/4 of new users seems a
large enough subset to care about too.  But one can't help
but wonder if most of the development community is focused
on some imaginary future user base, at the expense of the
much larger current user base.  Then again, there's still
plenty of Fortran77 code out there, so...

Given the existing rate of Python3 adoption (which by the signs we see in
the tracker is increasing),


The Wing IDE guys get a lot of feedback from the "report issue" dialog 
that is built in to the IDE. This sends information to them which 
includes which version of Python the user is working with. They are 
seeing an ever increasing proportion number of users working with Python 
3 (I don't have numbers though).


All the best,

Michael Foord



you can hardly call the user base imaginary.
Further, Python development (and development in general!) is *always*
focused on a "future user base" in the sense you are using it, not the
"current user base".  That's pretty much part of the definition of
development :)

But the reality is that almost all those Python2 users are future Python3
users, so they *are* the future user base.  And like Georg said, as far
as we can see Python3 uptake is pretty much right on the schedule that
was predicted when it was first released.

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



--
http://www.voidspace.org.uk/

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

Re: [Python-Dev] Continuing 2.x

[Stephen J. Turnbull]

l...@rmi.net writes:

 > But one can't help but wonder if most of the development community
 > is focused on some imaginary future user base, at the expense of
 > the much larger current user base.

Of course not.  Most of the development community is *focused* on a
very real, very current, and very *small* user base.  Themselves and
their employers and/or customers.  What attention they do pay to other
user bases is relatively unconcentrated (but far from negligible!)

And that's as it should be.

And so what if it's at the "expense" of the current user base.  By and
large, the "user base" has paid no expenses of the developers to date.
Nobody has a problem with that, but there is no promise that free ride
will continue forever.  Eventually the Piper presents his bill

___
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

[Martin v. Löwis]

> (and, believe me, not having to backport new 3.x features to the 2.x
> branch makes our work much easier than it was; people generally seem
> to underestimate the amount of care needed for such things, especially
> in areas where 2.x is significantly more complex - old-style classes,
> two parallel buffer APIs, misleading implicit conversions...)

I completely agree with that point. I find it unlikely that those
who do regular maintenance of Python will join a continuing-2.x effort.

Regards,
Martin
___
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

[Martin v. Löwis]

Am 28.10.2010 18:07, schrieb l...@rmi.net:
> Kristj?n Valur J?nsson  writes:
>> 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.
> 
> Exactly.
> 
> Has anyone here analyzed download stats on py.org lately?

I don't think anybody here questions that usage of 2.x
is orders of magnitude larger than that of 3.x, and that
it will stay that way for quite some time.

If, by "Exactly", you also supported "it is a bit harsh",
then I disagree. It's not harsh at all. Existing 2.x users
are *not* deprived at all. 2.7 releases are still being made,
and existing 2.x code will continue to run just fine for many
years to come. Users who chose to ignore 3.x can well continue
to work in their projects, without having to worry that bugs
won't be fixed anymore.

> Please feel free to prove me wrong, but by my reckoning,
> and at least for Windows MSI installer files, people are 
> still downloading Python 2.X roughly 3 to 4 times more often
> than Python 3.X today, some 2 years after 3.X's release.

Again, no doubt about that - I readily believe you without
checking, and you could have said that the factor was 10
and I still would have believe it. It just doesn't worry
me.

> But one can't help 
> but wonder if most of the development community is focused 
> on some imaginary future user base, at the expense of the 
> much larger current user base.

Yes, we do focus on future users, but we are also working
on future releases. But not at the expense of the much larger
current user base. They are being given much time to convert
their code to 3.x. So far, there has been no pressure at
all to migrate. Now, we are telling them that there won't
be new features in 2.x anymore - but many haven't switched
to 2.7, either.

Debian still ships with 2.5, and the next Debian release will be
shipping with 2.6. So any theoretical 2.8 release would be
just as irrelevant to existing users for many years to come
(e.g. the *next* Debian release would switch to 2.7).

Regards,
Martin
___
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] A sad state of doctests in the python manual

[Alexander Belopolsky]

I have just discovered that sphinx supports running doctests embedded
in ReST documentation.   It looks like it is as simple as "cd Doc;
make doctest".  The result, however is not encouraging:

$ make doctest
...
Doctest summary
===
 1162 tests
  262 failures in tests
0 failures in setup code
...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A sad state of doctests in the python manual

[Alexander Belopolsky]

On the second look, the problem may not be that bad - "make doctest"
picks up system python instead of the one from the source tree.  I'll
try to figure out how to rerun the doctests properly.

On Thu, Oct 28, 2010 at 4:48 PM, Alexander Belopolsky
 wrote:
> I have just discovered that sphinx supports running doctests embedded
> in ReST documentation.   It looks like it is as simple as "cd Doc;
> make doctest".  The result, however is not encouraging:
>
> $ make doctest
> ...
> Doctest summary
> ===
>  1162 tests
>  262 failures in tests
>    0 failures in setup code
> ...
>
___
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] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[anatoly techtonik]

Can anybody summarize the outcome?
Is it that renaming BadZipfile to BadZipFile with backward compatible
alias and deprecation note breaks something?

-- 
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] A sad state of doctests in the python manual

[Alexander Belopolsky]

On Thu, Oct 28, 2010 at 4:52 PM, Alexander Belopolsky
 wrote:
> On the second look, the problem may not be that bad ...

Nope, the problem is even worse.  It looks like Sphinx in py3k
requires 2.x python:

$ ../python.exe tools/sphinx-build.py -b doctest -d build/doctrees -D
latex_paper_size=  . build/doctest
Traceback (most recent call last):
  File "tools/sphinx-build.py", line 27, in 
from sphinx import main
  File "tools/sphinx/__init__.py", line 44
except ImportError, err:
  ^
SyntaxError: invalid syntax
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A sad state of doctests in the python manual

[Barry Warsaw]

On Oct 28, 2010, at 04:57 PM, Alexander Belopolsky wrote:

>On Thu, Oct 28, 2010 at 4:52 PM, Alexander Belopolsky
> wrote:
>> On the second look, the problem may not be that bad ...
>
>Nope, the problem is even worse.  It looks like Sphinx in py3k
>requires 2.x python:
>
>$ ../python.exe tools/sphinx-build.py -b doctest -d build/doctrees -D
>latex_paper_size=  . build/doctest
>Traceback (most recent call last):
>  File "tools/sphinx-build.py", line 27, in 
>from sphinx import main
>  File "tools/sphinx/__init__.py", line 44
>except ImportError, err:
>  ^
>SyntaxError: invalid syntax

It would be really cool if you fixed this! 

-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] A sad state of doctests in the python manual

[Alexander Belopolsky]

On Thu, Oct 28, 2010 at 5:18 PM, Barry Warsaw  wrote:
..
>
> It would be really cool if you fixed this! 
>
Working on it.  Stay tuned. :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A sad state of doctests in the python manual

[Alexander Belopolsky]

On Thu, Oct 28, 2010 at 5:30 PM, Alexander Belopolsky
 wrote:
> On Thu, Oct 28, 2010 at 5:18 PM, Barry Warsaw  wrote:
> ..
>>
>> It would be really cool if you fixed this! 
>>
> Working on it.  Stay tuned. :-)
>

See http://bugs.python.org/issue10224
___
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] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

Le 28/10/2010 22:52, anatoly techtonik a écrit :
> Can anybody summarize the outcome?
> Is it that renaming BadZipfile to BadZipFile with backward compatible
> alias and deprecation note breaks something?

See #7351 or r85874.

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

[Nick Coghlan]

On Fri, Oct 29, 2010 at 3:47 AM, Tres Seaver  wrote:
> I think that assumption may not be warranted.  If the current core folks
> are focused only on developing Python 3, but others are working on a
> notional 2.8, there is no necessary correlation any longer between the
> two.  In particular, the judgement of the current core about various
> tradeoffs in the Python 2 codebase won't be as relevant as it has been,
> in particular because the overarching drive (add features / warnings
> etc. which ease / encourage migration to Python 3) won't be in the
> forefront of the new group's perspective.

That's a fair point actually, but it would be a decision for the
possible-but-not-yet-existing group to take as they formed. Given the
likely divergence in design goals, it would probably be best to just
bite the bullet and declare it a fork of Python 2.7 (py2x 2.8?
RetroPython 2.8?). It would hardly be the first such fork - other
flavours of 2.x with design goals that differ from those of python-dev
certainly have a long history (Stackless, wpython, etc).

There are also IP issues to consider in setting up such a group
though. The PSF takes care of it for python.org, but those contributor
agreements wouldn't necessarily cover a new fork.

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

[Kristján Valur Jónsson]

Hi all.
This has been a lively discussion. 
My desire to keep 2.x alive in some sense is my own and I don't know if anyone 
shares it but as a member of this community I think I'm allowed to voice it.  
So, just to clarify my particular position, let me explain where all this comes 
from.

I am the maintainer of a private fork of Stackless Python 2.7, used by EVE 
Online.  Since I started doing this, we have moved from version 2.1 to 2.3, 2.5 
and finally a few months ago to 2.7.
Python is embedded into the C application so we use the C API extensively.
For a long while now I have been contributing a few improvements and patches to 
both the interpreter core and the standard library.  These are changes that 
stem from solving particular problems that we face in our rather extensive use 
of python, and range from crash bugs to performance optimizations as well as 
the occasional feature.
Usually the process is something like this:
1) We identify a problem that needs fixing.
2) We then spend some development effort on finding the right fix for it.
3) We then reflect:  Shouldn't this be contributed back to standard Python? 
That means
  a) others will benefit
  b) It reduces the diff of our fork from the central branch.
4) I spend some time reworking the change, submit a patch to the 2.x version 
that eventually  gets accepted or rejected by the community
5) And in the last few years, should a change be accepted, I am then often 
asked port the change to 3.x, which I normally do.  (and sometimes even 
correctly using svnmerge...)
This has been a happy and a personally fulfilling process, because who doesn't 
like to contribute to Python?

Now, of late some of this has changed.   Changes, (except those that pass as 
"bugfixes") are no longer accepted into the 2.x branches.  Should the change 
apply to 3.x, then I have to locally port it to 3.x, and submit it to that 
branch.  Some changes don't really apply to 3.x at all and have no place to go. 
 So people using a platform similar to mine won't benefit.
The result is that there is a much higher threshold for any of our improvements 
to make it back to the community and much less personal pleasure derived from 
it. 

What finally drove me to write the original post, was that working with the new 
bytearray and memoryview object in 2.7 made me realize that they don't 
interoperate with other classes in a natural way and so nullify their 
advantages.  My straightforward patches to 2.7 to remedy this situation (issues 
10211 and 10212) were met with the usual "it's not a bugfix" reply.

So, I'm frustrated.  I work with 2.7 on a day to day basis, and will continue 
to do so for quite some time.  It's a great product with some shortcomings, and 
I'd like to contribute to it but such contributions aren't welcome anymore.

I'm not sure what I'm actually proposing.  But I certainly wasn't thinking of a 
new "fork" of python.  And not a new version 2.8 that gets all new 3.x features 
backported.
I'm more thinking of a place where usability improvements, C API improvements, 
performance improvements, Library improvments, can go.

Cheers,

Kristján

-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Barry 
Warsaw
Sent: Friday, October 29, 2010 0:04
To: python-dev@python.org
Subject: Re: [Python-Dev] Continuing 2.x

Who is the target audience for a Python 2.8?  What exactly would a Python 2.8 
accomplish?

If Python 2.8 doesn't include new features, well, then what's the point?
Python 2.7 will be bug fix maintained for a long time, longer in fact than 
previous Python 2 versions.  So a no-feature Python 2.8 can't be about 
improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).

___
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] [Python-checkins] r85902 - in python/branches/py3k/Lib: os.py test/test_os.py

[Benjamin Peterson]

2010/10/28 victor.stinner :
> Author: victor.stinner
> Date: Fri Oct 29 02:38:58 2010
> New Revision: 85902
>
> Log:
> Issue #10210: os.get_exec_path() ignores BytesWarning warnings
>
>
> Modified:
>   python/branches/py3k/Lib/os.py
>   python/branches/py3k/Lib/test/test_os.py
>
> Modified: python/branches/py3k/Lib/os.py
> ==
> --- python/branches/py3k/Lib/os.py      (original)
> +++ python/branches/py3k/Lib/os.py      Fri Oct 29 02:38:58 2010
> @@ -382,18 +382,32 @@
>     *env* must be an environment variable dict or None.  If *env* is None,
>     os.environ will be used.
>     """
> +    # Use a local import instead of a global import to avoid bootstrap issue:
> +    # the os module is used to build Python extensions.
> +    import warnings

This sort of function import should be avoided.



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

[Brett Cannon]

2010/10/28 Kristján Valur Jónsson :
> Hi all.
> This has been a lively discussion.
> My desire to keep 2.x alive in some sense is my own and I don't know if 
> anyone shares it but as a member of this community I think I'm allowed to 
> voice it.  So, just to clarify my particular position, let me explain where 
> all this comes from.
>
> I am the maintainer of a private fork of Stackless Python 2.7, used by EVE 
> Online.  Since I started doing this, we have moved from version 2.1 to 2.3, 
> 2.5 and finally a few months ago to 2.7.
> Python is embedded into the C application so we use the C API extensively.
> For a long while now I have been contributing a few improvements and patches 
> to both the interpreter core and the standard library.  These are changes 
> that stem from solving particular problems that we face in our rather 
> extensive use of python, and range from crash bugs to performance 
> optimizations as well as the occasional feature.
> Usually the process is something like this:
> 1) We identify a problem that needs fixing.
> 2) We then spend some development effort on finding the right fix for it.
> 3) We then reflect:  Shouldn't this be contributed back to standard Python? 
> That means
>  a) others will benefit
>  b) It reduces the diff of our fork from the central branch.
> 4) I spend some time reworking the change, submit a patch to the 2.x version 
> that eventually  gets accepted or rejected by the community
> 5) And in the last few years, should a change be accepted, I am then often 
> asked port the change to 3.x, which I normally do.  (and sometimes even 
> correctly using svnmerge...)
> This has been a happy and a personally fulfilling process, because who 
> doesn't like to contribute to Python?
>

And all of that work has been appreciated obviously (in case that
wasn't obvious =).

> Now, of late some of this has changed.   Changes, (except those that pass as 
> "bugfixes") are no longer accepted into the 2.x branches.  Should the change 
> apply to 3.x, then I have to locally port it to 3.x, and submit it to that 
> branch.  Some changes don't really apply to 3.x at all and have no place to 
> go.  So people using a platform similar to mine won't benefit.
> The result is that there is a much higher threshold for any of our 
> improvements to make it back to the community and much less personal pleasure 
> derived from it.
>
> What finally drove me to write the original post, was that working with the 
> new bytearray and memoryview object in 2.7 made me realize that they don't 
> interoperate with other classes in a natural way and so nullify their 
> advantages.  My straightforward patches to 2.7 to remedy this situation 
> (issues 10211 and 10212) were met with the usual "it's not a bugfix" reply.
>

Which is the correct reply.

> So, I'm frustrated.  I work with 2.7 on a day to day basis, and will continue 
> to do so for quite some time.  It's a great product with some shortcomings, 
> and I'd like to contribute to it but such contributions aren't welcome 
> anymore.

Well, they are welcome, just in Python 3.2 instead of Python 2.7 (when
they apply to Python 3.2 in the first place). We have had a bugfix
version in development as well as the new features version for ages.
It just so happens that a bunch of people have not decided when they
plan to switch to the new features version yet.

>
> I'm not sure what I'm actually proposing.  But I certainly wasn't thinking of 
> a new "fork" of python.  And not a new version 2.8 that gets all new 3.x 
> features backported.
> I'm more thinking of a place where usability improvements, C API 
> improvements, performance improvements, Library improvments, can go.

It's called a fork. I realize you are trying to avoid that "dirty"
word, Kristján, and I appreciate it, but you are describing a fork.
Python 2.7 is the last sanctioned version of the Python 2.x series,
period. Any non-bugfix changes will not go in there as policy
dictates. And with there being no way Python 2.8 will happen (I know
we as a group have said "slim chance" since Python 3.0 came out,
uptake of Python 3 is such I am willing to personally say "never" for
a python-dev sanctioned Python 2.8), that means it will take a fork,
whether it be internal to CCP or public somewhere, it will still be a
fork.

And as everyone has said so far (and with which I agree), that's fine.
As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty
Python reference -- then that's fine. And as pointed out by folks,
once Hg kicks in and we have user repos you can even host it on
hg.python.org yourself to give it some semblance of authority if you
want.

I understand the desire to have the final version of the Python 2.x to
be as perfect as it can be, but that will never happen. Every release
of Python is imperfect. There will always be mistakes we made that
require incompatible changes to rectify. It's life and that's just a
part of software development.

I think people need t

Re: [Python-Dev] Continuing 2.x

[Stephen J. Turnbull]

Brett Cannon writes:

 > I think people need to stop viewing the difference between Python 2.7
 > and Python 3.2 as this crazy shift and view it from python-dev's
 > perspective;

That phrasing *is* harsh.  People also need to work with code bases
that are incompatible with Python 3.2 for various reasons, and will be
very expensive to port to 3.2.  Some, perhaps many, of those people
*do* consider Python 3 to be the way to go, and I imaginge they are
already going that way when they can.  Nevertheless, their bread-and-
butter projects are feeling pain; their world is going out of whack.

It is a "crazy shift" (or "crazy-making" shift) for them.

And for now the book writers have to feel the same way; a lot of
Python-2-based applications are going to be perfectly happy to stay
that way with Python 2.7 for years to come.  The book writers need (as
a commercial matter) to serve the new engineers who will be hired to
maintain *and extend* those products.  I suspect there will be a
substantial market for Python 2 content in Python books until 2015
(although Mark Lutz should be able to sit back and just collect
royalties on that part of his book starting in 2012).

 > You can view it as Python 3.2 is the next version after Python
 > 2.7 just like 2.7 followed to 2.6,

Kristján acknowledges that.  He's looking for some relief from his
*current* headache.

Mark's position is different.  His words suggest that he thinks that
Python.org owes the users something, although if pressed I imagine
he'd present some argument that more users will lead to development of
a better language.  I think the developers universally consider that
to be objectively false: Python 3 is a much better language, and is on
track to be a much better environment for development -- of itself and
of applications -- in 2013 than Python 2 could conceivably be.
___
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] issue 10212

[Antoine Pitrou]

On Fri, 29 Oct 2010 10:10:31 +0800
Kristján Valur Jónsson  wrote:
> 
> What finally drove me to write the original post, was that working with
> the new bytearray and memoryview object in 2.7 made me realize that
> they don't interoperate with other classes in a natural way and so
> nullify their advantages.  My straightforward patches to 2.7 to remedy
> this situation (issues 10211 and 10212) were met with the usual "it's
> not a bugfix" reply.

For the record, and that's not because you are using it here as an
argument, I misevaluated issue 10212. I thought you wanted to make
cStringIO objects *provide* the buffer protocol. Actually, your patch
simply makes it *accept* new buffer-compliant objects in places where it
already accepts old buffer-compliant objects (such as the write()
method). There is then much less contention against letting the patch
in (provided it gets reviewed :-)).

That doesn't change the rest of your argument, though; and I agree with
other people's voiced opinions that what you are proposing ("usability
improvements", etc.) is what we usually consider a new feature, in QA
terms.

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] x86 Leopard buildbot

[Antoine Pitrou]

Hello,

As a leap of faith, I have added Stephen Hansen's x86 Leopard buildbot
to the list of stable bots. Stephen has been very proactive in
diagnosing and fixing issues (thank you!).

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