Re: [Python-Dev] [Distutils] Single-file Python executables (including case of self-sufficient package manager)

[Chris Barker]

On Fri, May 29, 2015 at 7:23 AM, Paul Sokolovsky  wrote:


> > An example of a product that does this is Chef, they install their
> > own Ruby and everything but libc into /opt/chef to completely isolate
> > themselves from the host system.


this sounds a bit like what conda does -- install miniconda, and a conda
environment set up with a yaml file,, and away you go. not small, but quite
self contained, and give you exactly what you want.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Glenn Linderman]

On 5/29/2015 3:28 PM, Paul Moore wrote:

On 29 May 2015 at 23:15, Glenn Linderman  wrote:

I don't presently see any C:\Python34\DLLs or C:\Python34 on my path, but I
didn't ask the installer to put it there either. So I'm guessing your option
1 assumes asking the Python installer to put it there? Not "automatically"
but "on request", I think?

In my c:\Python34\DLLs, I don't see a python34.dll, only python3.dll... so
I'm somewhat unclear on your simplified explanation.


I'm definitely batting zero today :-(

OK, let's try to be clear. I typically do "all users" installs. The
"for me only" install is slightly different, and the new install for
3.5 may be different again. But what I see is:

1. C:\Python34\DLLs containins python3.dll, which is *never* on PATH
(and doesn't need to be for normal use). Anything that wants to use
python3.dll needs that directory manually adding to PATH.
2. python34.dll is in C:\Windows\System32. This is always available to
all processes, as it's in the Windows system directory.

If you say "add Python to my PATH" you get C:\Python34 added to PATH.
For a user install, I believe python34.dll may be in there rather than
in C:\Windows\system32, so technically, for an app that uses
python34.dll to work, you need *either* an admin install, *or* to have
done "add Python to PATH".



Interesting.

In C:\, I have directories  Python27, Python32, Python33, Python34.  I 
can't be 100% sure how I answered the install questions, even Python34 
was a couple months ago.


In C:\Windows\System32, I have python27.dll, python32.dll, python33.dll, 
pythoncom32.dll, pythoncom33.dll, pythoncomloader32.dll, and 
pythoncomloader33.dll.  But not python34.dll!  I finally found that in 
c:\Windows\SysWOW64, which I guess means that I "accidentally" installed 
a 32-bit Python 3.4.  Or maybe I had a reason at the time.  But does 
that add another dimension to the picture for the stub?




I hope that made sense. Sorry for my garbled previous version.


This matches reality better... but whether it makes sense or not is 
another question.



On 5/29/2015 3:33 PM, Steve Dower wrote:
> Paul Moore wrote:
>> One mildly annoying thing is that python3.dll is only installed in 
\DLLs, which
>> typically isn't on PATH. So actually using the limited API from your 
own application fails by default.
>> Fixing that's mostly a user admin issue, though (and you can just 
link to the full API and avoid the whole problem).

>
> I didn't even notice that 3.4 (and earlier?) were doing that, so I 
changed/fixed it by accident :)



Indeed, and earlier. It apparently started in 3.2 with the definition of 
the Stable ABI.



> Python 3.5 installs python3.dll alongside python35.dll, so it'll go 
into the user's Python directory by default or into the system directory 
for an all-users installation. The embeddable distro includes 
python3.dll alongside the other DLLs as well.

>
> Cheers,
> Steve


This makes more sense... but will it cause problems with something? It 
seems to me like it was a bug to put it in the  
rather than %windir%\System32 back in Python 3.2 days when it was 
invented. What good is it to have a stable ABI that is hidden away where 
it cannot (easily) be used, and the more dynamic API is easier to get to?


Sadly, PEP 384 is silent on the location of python3.dll.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Alexander Walters]

Python is a giant cache-miss generator.  A little performance boost on 
the opt-code dispatch isn't going to change that much.  If we really do 
care about improving python to do less environmental damage, then that 
is a discussion we should be having on it's own merits.  It was really 
out of place, even in this tangenty thread.


On 5/29/2015 20:34, Nick Coghlan wrote:



On 30 May 2015 09:57, "Antoine Pitrou" > wrote:

>
> On Sat, 30 May 2015 01:49:10 +0200
> Christian Heimes > wrote:

> > For performance patches we have to consider our responsibility for the
> > environment. Every improvement means more speed and less power
> > consumption. Python runs of hundreds of thousands of machines in the
> > cloud. Python 2.7 will be used for at least half a decade, probably
> > longer. Servers can be replaced with faster machines later and less
> > fossil fuel must be burned to produce power.
>
> Please keep your ideology out of this.

I'm a qualified engineer (in computer systems engineering), so caring 
about environmental sustainability is part of my professional ethical 
standards, not just a matter of personal preference: 
http://www.wfeo.org/ethics/


Given the power draw of large data centres, the environmental impact 
of performance improvements to the Python 2 series is a point well 
worth considering.


Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com




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


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

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Nick Coghlan]

On 30 May 2015 09:57, "Antoine Pitrou"  wrote:
>
> On Sat, 30 May 2015 01:49:10 +0200
> Christian Heimes  wrote:
> > For performance patches we have to consider our responsibility for the
> > environment. Every improvement means more speed and less power
> > consumption. Python runs of hundreds of thousands of machines in the
> > cloud. Python 2.7 will be used for at least half a decade, probably
> > longer. Servers can be replaced with faster machines later and less
> > fossil fuel must be burned to produce power.
>
> Please keep your ideology out of this.

I'm a qualified engineer (in computer systems engineering), so caring about
environmental sustainability is part of my professional ethical standards,
not just a matter of personal preference: http://www.wfeo.org/ethics/

Given the power draw of large data centres, the environmental impact of
performance improvements to the Python 2 series is a point well worth
considering.

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Antoine Pitrou]

On Sat, 30 May 2015 01:49:10 +0200
Christian Heimes  wrote:
> For performance patches we have to consider our responsibility for the
> environment. Every improvement means more speed and less power
> consumption. Python runs of hundreds of thousands of machines in the
> cloud. Python 2.7 will be used for at least half a decade, probably
> longer. Servers can be replaced with faster machines later and less
> fossil fuel must be burned to produce power.

Please keep your ideology out of this.

Regards

Antoine.


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

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Christian Heimes]

On 2015-05-29 23:14, Gregory P. Smith wrote:
> 
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan  > wrote:
> 
> 
> On 29 May 2015 11:01 am, "Victor Stinner"  > wrote:
> >
> > Why not continue to enhance Python 3 instead of wasting our time with
> > Python 2? We have limited resources in term of developers to maintain
> > Python.
> >
> > (I'm not talking about fixing *bugs* in Python 2 which is fine
> with me.)
> 
> I'm actually OK with volunteers deciding that even fixing bugs in
> 2.7 isn't inherently rewarding enough for them to be willing to do
> it for free on their own time.
> 
>  
> That is 100% okay.
> 
> What is not okay is for python-dev representatives to respond to users
> (in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in
> 3 can be backported to 2.7 with things akin to "just use Python 3" or
> "sorry, 2.7 is critical fixes only. move to python 3 already." This is
> actively driving our largest users away.  I bring this up because a user
> was bemoaning how useless they feel python core devs are because of this
> attitude recently. Leading to feelings of wishing to just abandon
> CPython if not Python all together.
> 
> I'm sure I have even made some of those responses myself (sorry!). My
> point here is: know it. recognize it. don't do it anymore. It harms the
> community.
> 
> A correct and accurate response to desires to make non-api-breaking
> changes in 2.7 is "Patches that do not change any APIs for 2.7 are
> welcome in the issue tracker." possibly including "I don't have the
> bandwidth to review 2.7 changes, find someone on python-dev to review
> and champion this for you if you need it."  Finding someone may not
> always be easy. But at least is still the "patches welcome" attitude and
> suggests that the work can be done if someone is willing to do it. Lets
> make a concerted effort to not be hostile and against it by default.
> 
> Ex: Is someone with a python application that is a million of lines
> supposed to have everyone involved in that drop the productive work they
> are doing and spend that porting their existing application to python 3
> because we have so far failed to provide the tools to make that
> migration easy?  No.  Empathize with our community.  Feel their pain.
>  (and everyone who is working on tools to aid the transition: keep doing
> that! Our users are gonna need it unless we don't want them as users
> anymore.)
> 
> We committed to supporting 2.7 until 2020 in 2014 per
> https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
> important bug or performance fixes should at least be allowed on the
> table, even if hairy, even if you won't work on them yourselves on a
> volunteer basis. This is the first long term support release of Python
> ever. This is what LTS means.  LTS could /also/ stand for Learn To
> Support...

Over the last years I have changed my mind a bit, too. For Python 2.7
LTS I welcome performance improving patches as well as security
improvements (SSL module) and build related fixes.

For performance patches we have to consider our responsibility for the
environment. Every improvement means more speed and less power
consumption. Python runs of hundreds of thousands of machines in the
cloud. Python 2.7 will be used for at least half a decade, probably
longer. Servers can be replaced with faster machines later and less
fossil fuel must be burned to produce power. Let's keep Python green! :)

Thanks to Benjamin, the patch has already landed.

Antoine's improved GIL may be another improvement for Python 2.7.
Servers are getting more cores every year. The new GIL helps to scale
multiple CPU bound threads on machines with more cores, e.g.
http://www.dabeaz.com/python/NewGIL.pdf

Christian

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

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Nick Coghlan]

On 30 May 2015 09:21, "Barry Warsaw"  wrote:
>
> On May 29, 2015, at 04:04 PM, Guido van Rossum wrote:
>
> >There are a fair number of people on this thread whose employer pays
them to
> >work on Python.
>
> My guess is that as Python 2.7 gets longer in the tooth, and it becomes
harder
> to motivate volunteers to shepherd contributed patches into Python 2,
folks
> getting paid by employers who need Python 2 to continue to be maintained,
will
> step up and go through the mentorship process so that they can more
directly
> apply such patches.  I.e. they can start to take over some of the active
> maintenance of the Python 2.7 branch.

Yep, I'm hoping to be able to do exactly that for Red Hat folks so we can
minimise our need to carry 2.7 patches downstream without imposing
additional work on volunteers upstream.

We have a few core committers working here now (me, Kushal, Christian,
Victor), but we're not the folks specifically working on Python 2.7
maintenance and support.

This means that while I don't believe "I'm getting paid to support Python
2.7" should be a free ride to commit access, I *do* think it's a factor we
ought to take into account.

Cheers,
Nick.

>
> Cheers,
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Ian Cordasco]

On Fri, May 29, 2015 at 6:04 PM, Guido van Rossum  wrote:
> On Fri, May 29, 2015 at 2:52 PM, Ian Cordasco 
> wrote:
>>
>> On Fri, May 29, 2015 at 4:14 PM, Gregory P. Smith  wrote:
>> >
>> > On Fri, May 29, 2015 at 12:24 AM Nick Coghlan 
>> > wrote:
>> >>
>> >>
>> >> On 29 May 2015 11:01 am, "Victor Stinner" 
>> >> wrote:
>> >> >
>> >> > Why not continue to enhance Python 3 instead of wasting our time with
>> >> > Python 2? We have limited resources in term of developers to maintain
>> >> > Python.
>> >> >
>> >> > (I'm not talking about fixing *bugs* in Python 2 which is fine with
>> >> > me.)
>> >>
>> >> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
>> >> isn't inherently rewarding enough for them to be willing to do it for
>> >> free
>> >> on their own time.
>> >
>> >
>> > That is 100% okay.
>> >
>> > What is not okay is for python-dev representatives to respond to users
>> > (in
>> > any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3
>> > can be
>> > backported to 2.7 with things akin to "just use Python 3" or "sorry, 2.7
>> > is
>> > critical fixes only. move to python 3 already." This is actively driving
>> > our
>> > largest users away.  I bring this up because a user was bemoaning how
>> > useless they feel python core devs are because of this attitude
>> > recently.
>> > Leading to feelings of wishing to just abandon CPython if not Python all
>> > together.
>> >
>> > I'm sure I have even made some of those responses myself (sorry!). My
>> > point
>> > here is: know it. recognize it. don't do it anymore. It harms the
>> > community.
>> >
>> > A correct and accurate response to desires to make non-api-breaking
>> > changes
>> > in 2.7 is "Patches that do not change any APIs for 2.7 are welcome in
>> > the
>> > issue tracker." possibly including "I don't have the bandwidth to review
>> > 2.7
>> > changes, find someone on python-dev to review and champion this for you
>> > if
>> > you need it."  Finding someone may not always be easy. But at least is
>> > still
>> > the "patches welcome" attitude and suggests that the work can be done if
>> > someone is willing to do it. Lets make a concerted effort to not be
>> > hostile
>> > and against it by default.
>> >
>> > Ex: Is someone with a python application that is a million of lines
>> > supposed
>> > to have everyone involved in that drop the productive work they are
>> > doing
>> > and spend that porting their existing application to python 3 because we
>> > have so far failed to provide the tools to make that migration easy?
>> > No.
>> > Empathize with our community.  Feel their pain.  (and everyone who is
>> > working on tools to aid the transition: keep doing that! Our users are
>> > gonna
>> > need it unless we don't want them as users anymore.)
>> >
>> > We committed to supporting 2.7 until 2020 in 2014 per
>> > https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
>> > important bug or performance fixes should at least be allowed on the
>> > table,
>> > even if hairy, even if you won't work on them yourselves on a volunteer
>> > basis. This is the first long term support release of Python ever. This
>> > is
>> > what LTS means.  LTS could also stand for Learn To Support...
>>
>> At the same time, they can ask for it, but if people aren't motivated
>> to do the work for it, it won't happen. We should be encouraging (and
>> maybe even mentoring) these people who are desperately in need of the
>> fixes to be backported, to backport the patches themselves. With that
>> done, it can go through review and we can maybe get those fixes in
>> faster if we can also get a larger group of reviews.
>>
>> The problem consists of a few parts:
>>
>> - We're all volunteers
>
>
> Speak for yourself. There are a fair number of people on this thread whose
> employer pays them to work on Python. And this thread originated when a
> patch was being contributed by people who were also paid by their employer
> to do all the dirty work (including benchmarks). And yet they were
> (initially) given the cold shoulder by some "high and mighty" Python 3
> zealots. This attitude need to change.
>
>>
>> - Volunteers are going to work on what interests them
>> - Python 2.7 maintenance doesn't seem to interest many of our
>> volunteers currently
>>
>> Perhaps we should explain this to each of the people requesting
>> backports to (ideally) encourage them.
>
>
> Please let someone else do the explaining. I don't want to have to do the
> damage control after you "explain" something.

Good to know. I'll stop trying to make spare time to review patches then.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Barry Warsaw]

On May 29, 2015, at 04:04 PM, Guido van Rossum wrote:

>There are a fair number of people on this thread whose employer pays them to
>work on Python.

My guess is that as Python 2.7 gets longer in the tooth, and it becomes harder
to motivate volunteers to shepherd contributed patches into Python 2, folks
getting paid by employers who need Python 2 to continue to be maintained, will
step up and go through the mentorship process so that they can more directly
apply such patches.  I.e. they can start to take over some of the active
maintenance of the Python 2.7 branch.

Cheers,
-Barry

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

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

[Nick Coghlan]

On 29 May 2015 22:50, "Donald Stufft"  wrote:
>
> This might be something that people could have done before with C/C++ but
with
> a nicer language behind it... but that's kind of the point? You don't
need to
> be stuck with a terrible language to get a nice single file executable
anymore,
> you can get that and use a good language at the same time which makes it
a lot
> more compelling to a lot more people than having to be stuck with C.

Right, but the only things you can really write in Go are network services
and console applications - once you start looking at curses & GUI
applications on the end user side, you're back to the same kind of
distribution complexity as C/C++ (where you have to choose between external
dependency management or very large downloads), and once you start looking
at the infrastructure side, Docker, Rocket & Kubernetes are bringing this
kind of easy deployability to network services written in arbitrary
languages.

Hence my comment about MicroPython: the easiest way to make an interpreter
runtime that's lighter than CPython is to have it *do less*.

Communicating with embedded MicroPython instances via cffi could even
potentially offer a way for both CPython and PyPy to split work across
multiple cores without having to fundamentally redesign their main
interpreters.

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Steve Dower]

Paul Moore wrote:
> One mildly annoying thing is that python3.dll is only installed in  install dir>\DLLs, which
> typically isn't on PATH. So actually using the limited API from your own 
> application fails by default.
> Fixing that's mostly a user admin issue, though (and you can just link to the 
> full API and avoid the whole problem).

I didn't even notice that 3.4 (and earlier?) were doing that, so I 
changed/fixed it by accident :)

Python 3.5 installs python3.dll alongside python35.dll, so it'll go into the 
user's Python directory by default or into the system directory for an 
all-users installation. The embeddable distro includes python3.dll alongside 
the other DLLs as well.

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

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Guido van Rossum]

On Fri, May 29, 2015 at 2:52 PM, Ian Cordasco 
wrote:

> On Fri, May 29, 2015 at 4:14 PM, Gregory P. Smith  wrote:
> >
> > On Fri, May 29, 2015 at 12:24 AM Nick Coghlan 
> wrote:
> >>
> >>
> >> On 29 May 2015 11:01 am, "Victor Stinner" 
> >> wrote:
> >> >
> >> > Why not continue to enhance Python 3 instead of wasting our time with
> >> > Python 2? We have limited resources in term of developers to maintain
> >> > Python.
> >> >
> >> > (I'm not talking about fixing *bugs* in Python 2 which is fine with
> me.)
> >>
> >> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
> >> isn't inherently rewarding enough for them to be willing to do it for
> free
> >> on their own time.
> >
> >
> > That is 100% okay.
> >
> > What is not okay is for python-dev representatives to respond to users
> (in
> > any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3
> can be
> > backported to 2.7 with things akin to "just use Python 3" or "sorry, 2.7
> is
> > critical fixes only. move to python 3 already." This is actively driving
> our
> > largest users away.  I bring this up because a user was bemoaning how
> > useless they feel python core devs are because of this attitude recently.
> > Leading to feelings of wishing to just abandon CPython if not Python all
> > together.
> >
> > I'm sure I have even made some of those responses myself (sorry!). My
> point
> > here is: know it. recognize it. don't do it anymore. It harms the
> community.
> >
> > A correct and accurate response to desires to make non-api-breaking
> changes
> > in 2.7 is "Patches that do not change any APIs for 2.7 are welcome in the
> > issue tracker." possibly including "I don't have the bandwidth to review
> 2.7
> > changes, find someone on python-dev to review and champion this for you
> if
> > you need it."  Finding someone may not always be easy. But at least is
> still
> > the "patches welcome" attitude and suggests that the work can be done if
> > someone is willing to do it. Lets make a concerted effort to not be
> hostile
> > and against it by default.
> >
> > Ex: Is someone with a python application that is a million of lines
> supposed
> > to have everyone involved in that drop the productive work they are doing
> > and spend that porting their existing application to python 3 because we
> > have so far failed to provide the tools to make that migration easy?  No.
> > Empathize with our community.  Feel their pain.  (and everyone who is
> > working on tools to aid the transition: keep doing that! Our users are
> gonna
> > need it unless we don't want them as users anymore.)
> >
> > We committed to supporting 2.7 until 2020 in 2014 per
> > https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
> > important bug or performance fixes should at least be allowed on the
> table,
> > even if hairy, even if you won't work on them yourselves on a volunteer
> > basis. This is the first long term support release of Python ever. This
> is
> > what LTS means.  LTS could also stand for Learn To Support...
>
> At the same time, they can ask for it, but if people aren't motivated
> to do the work for it, it won't happen. We should be encouraging (and
> maybe even mentoring) these people who are desperately in need of the
> fixes to be backported, to backport the patches themselves. With that
> done, it can go through review and we can maybe get those fixes in
> faster if we can also get a larger group of reviews.
>
> The problem consists of a few parts:
>
> - We're all volunteers
>

Speak for yourself. There are a fair number of people on this thread whose
employer pays them to work on Python. And this thread originated when a
patch was being contributed by people who were also paid by their employer
to do all the dirty work (including benchmarks). And yet they were
(initially) given the cold shoulder by some "high and mighty" Python 3
zealots. This attitude need to change.


> - Volunteers are going to work on what interests them
> - Python 2.7 maintenance doesn't seem to interest many of our
> volunteers currently
>
> Perhaps we should explain this to each of the people requesting
> backports to (ideally) encourage them.
>

Please let someone else do the explaining. I don't want to have to do the
damage control after you "explain" something.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Nick Coghlan]

On 30 May 2015 07:14, "Gregory P. Smith"  wrote:
>
>
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan  wrote:
>>
>>
>> On 29 May 2015 11:01 am, "Victor Stinner" 
wrote:
>> >
>> > Why not continue to enhance Python 3 instead of wasting our time with
>> > Python 2? We have limited resources in term of developers to maintain
>> > Python.
>> >
>> > (I'm not talking about fixing *bugs* in Python 2 which is fine with
me.)
>>
>> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
isn't inherently rewarding enough for them to be willing to do it for free
on their own time.
>
>
> That is 100% okay.
>
> What is not okay is for python-dev representatives to respond to users
(in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3
can be backported to 2.7 with things akin to "just use Python 3" or "sorry,
2.7 is critical fixes only. move to python 3 already." This is actively
driving our largest users away.  I bring this up because a user was
bemoaning how useless they feel python core devs are because of this
attitude recently. Leading to feelings of wishing to just abandon CPython
if not Python all together.
>
> I'm sure I have even made some of those responses myself (sorry!). My
point here is: know it. recognize it. don't do it anymore. It harms the
community.
>
> A correct and accurate response to desires to make non-api-breaking
changes in 2.7 is "Patches that do not change any APIs for 2.7 are welcome
in the issue tracker." possibly including "I don't have the bandwidth to
review 2.7 changes, find someone on python-dev to review and champion this
for you if you need it."  Finding someone may not always be easy. But at
least is still the "patches welcome" attitude and suggests that the work
can be done if someone is willing to do it. Lets make a concerted effort to
not be hostile and against it by default.

Better answer (and yes, I'm biased): "Have you asked your Python support
vendor to push for this change on your behalf?"

If well-funded entities expect open source software to just magically be
maintained without them paying someone to maintain it (whether that's their
own developers or a redistributor), then their long term risk management
processes are fundamentally broken and they need to reconsider their
approach.

> Ex: Is someone with a python application that is a million of lines
supposed to have everyone involved in that drop the productive work they
are doing and spend that porting their existing application to python 3
because we have so far failed to provide the tools to make that migration
easy?  No.  Empathize with our community.  Feel their pain.  (and everyone
who is working on tools to aid the transition: keep doing that! Our users
are gonna need it unless we don't want them as users anymore.)

Are they paying someone for Python support (or at least sponsoring the
Python Software Foundation)? If they're paying for support, are they
working with that vendor to figure out how they're going to manage the
transition to Python 3? If they're not paying for support, are they
actively participating in the community such that I know their developers
at a personal level and care about them as friends & colleagues?

If the answer to all three of those questions is "No", then no, I don't
have any sympathy for them. In the first case, my response is "Stop being a
freeloader on the generosity of the Python community and pay someone", in
the second case it's "Go make use of that commercial support you're paying
for (and stop breaking our core development funding signals by bypassing
it)", while in the third it's "What have you done for *me* lately that
should make me care about your inability to appropriately manage business
risk?".

> We committed to supporting 2.7 until 2020 in 2014 per
https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
important bug or performance fixes should at least be allowed on the table,
even if hairy, even if you won't work on them yourselves on a volunteer
basis. This is the first long term support release of Python ever. This is
what LTS means.  LTS could also stand for Learn To Support...

It also stands for commercial redistributors and the infrastructure teams
at large institutions actually doing what we're paid for, rather than
expecting other volunteers to pick up our slack.

The only thing we can legitimately ask volunteers to do is to not *object*
while we do this, and for them to redirect well-funded end users to paid
support options and other means of contributing back to the Python
community, rather than haranguing them to "just upgrade already".

Regards,
Nick.

>
> -gps
>>
>> Stepping up to extrinsically reward activities that are beneficial for
customers but aren't intrinsically interesting enough for people to be
willing to do for free is one of the key reasons commercial open source
redistributors get paid.
>>
>> That more explicitly commercial presence is a dynamic we haven't
historically had to deal with in c

Re: [Python-Dev] Computed Goto dispatch for Python 2

[Ronald Oussoren]

Op 28 mei 2015 om 21:37 heeft Chris Barker  het volgende 
geschreven:

> On Thu, May 28, 2015 at 12:25 PM, Sturla Molden  
> wrote:
> 
>> The system
>> Python should be left alone as it is.
> 
> absolutely!
> 
> By the way, py2app will build an application bundle that depends on the 
> system python, indeed, that's all it will do if you run it with the system 
> python, as Apple has added some non-redistributable bits in there.

That's not quite the reason. It's more that I don't want to guess whether or 
not it is valid to bundle binaries from a system location.  Furthermore 
bundling files from a base install of the OS is pretty useless, especially when 
those binaries won't run on earlier releases anyway due to the compilation 
options used. 

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 29 May 2015 at 23:15, Glenn Linderman  wrote:
> I don't presently see any C:\Python34\DLLs or C:\Python34 on my path, but I
> didn't ask the installer to put it there either. So I'm guessing your option
> 1 assumes asking the Python installer to put it there? Not "automatically"
> but "on request", I think?
>
> In my c:\Python34\DLLs, I don't see a python34.dll, only python3.dll... so
> I'm somewhat unclear on your simplified explanation.

I'm definitely batting zero today :-(

OK, let's try to be clear. I typically do "all users" installs. The
"for me only" install is slightly different, and the new install for
3.5 may be different again. But what I see is:

1. C:\Python34\DLLs containins python3.dll, which is *never* on PATH
(and doesn't need to be for normal use). Anything that wants to use
python3.dll needs that directory manually adding to PATH.
2. python34.dll is in C:\Windows\System32. This is always available to
all processes, as it's in the Windows system directory.

If you say "add Python to my PATH" you get C:\Python34 added to PATH.
For a user install, I believe python34.dll may be in there rather than
in C:\Windows\system32, so technically, for an app that uses
python34.dll to work, you need *either* an admin install, *or* to have
done "add Python to PATH".

I hope that made sense. Sorry for my garbled previous version.

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Glenn Linderman]

On 5/29/2015 2:45 PM, Paul Moore wrote:

On 29 May 2015 at 21:49, Glenn Linderman  wrote:

That looks interesting, I wonder what compilation environment it would need?
I don't think I've even installed a C compiler on my last couple boxes, and
the only version of a C compiler I have is, umm... M$VC++6.0, since I've
moved to using Python for anything a 5 line batch file can't do...


One mildly annoying thing is that python3.dll is only installed in
\DLLs, which typically isn't on PATH.

Ah, linking so I guess if I figured out how to create this binary, it
would contain a reference to python3.dll that would attempt to be resolved
via the PATH, from what you say, and typically fail, due to PATH seldom
containing python3.dll.  The python launcher gets around that by (1) being
installed in %windir%, and going and finding the appropriate Python (per its
own configuration file, and command line parameters), and setting up the
path to that Python, which, when executed, knows its own directory structure
and can thus find its own python3.dll.

The launcher, of course, adds an extra layer of process between the shell
and the program, because it launches the "real" Python executable.


So actually using the limited API from your own application fails by
default.
Fixing that's mostly a user admin issue, though (and you can just link
to the full API and avoid the whole problem).


Do I understand correctly that the "user admin issue" means "add the
appropriate \DLLs to the PATH"?

What I don't understand here is how linking to the full API avoids the
problem... it must put more python library code into the stub executable?
Enough to know how to search the registry to find the 
for the version of Python from which the full API was obtained? Or something
else?

Sorry, I assumed more Windows/C knowledge than you have.


It is mostly the C/Python interface knowledge that I lack... although my 
Windows/C knowledge is getting rusty.



I'll work on this and produce proper binaries in due course, so you
can always wait for them. But you can build the stub with pretty much
anything, I suspect - I managed with MSVC 2010 and mingw. I'll add
some build docs and get it on github.

Using mingw

 gcc -Wall -O2 -o stub.exe stub.c -I \Include
C:\Windows\system32\python34.dll
 strip -s stub.exe

Using MSVC

 cl /Festub.exe /O2 stub.c /I\Include \libs\python34.lib


Github sounds good.  Binaries sound good.  I would have to download the 
free MSVC10 or Ming and install and learn to use them, etc., to make 
progress... probably doable, but (1) I'm surviving at the moment with 
the launcher + zipapp, but it'd be nice for folks I code for to have 
.exe things, and (2) I'm backlogged in my other projects which don't 
need me to download a C compiler to make progress.



Regarding the DLLs, yes the "user admin issue" is adding the right
directory to PATH. I used the phrase "admin issue" as it's the aspect
that's likely to be far harder than any of the technical issues :-)
The reason using the full API helps is that the full API references
python34.dll rather than python3.dll. And the Python installer puts
python34.dll on PATH automatically, as it's what the "python" command
uses. (For the people with more Windows knowledge, I know this is a
simplification, but it's close enough for now).

So there are two  options with the code I posted.

1. Build an exe that uses a specific version of Python, but which will
"just work" in basically the same way that the "python" command works.
2. Build an exe that works with any version of Python, but requires
some setup from the user.

Either approach requires that the Python DLL is on PATH, but that's
far more likely with the version-specific one, just because of how the
installer does things.


I don't presently see any C:\Python34\DLLs or C:\Python34 on my path, 
but I didn't ask the installer to put it there either. So I'm guessing 
your option 1 assumes asking the Python installer to put it there? Not 
"automatically" but "on request", I think?


In my c:\Python34\DLLs, I don't see a python34.dll, only python3.dll... 
so I'm somewhat unclear on your simplified explanation.




With extra code, the stub could locate an appropriate Python DLL
dynamically, which would simplify usage at the cost of a bit of fiddly
code in the stub.

This might be a useful addition to the zipapp module for Python 3.6.


Indeed.  Especially with extra fiddly code if you or someone on Github 
has the time, it could be very useful for the zipapp module.




Paul

PS Current launchers (py.exe, the entry point launchers from
pip/setuptools, etc) tend to spawn the actual python program in a
subprocess. I believe there are *technically* some differences in the
runtime environment when you use an embedding approach like this, but
I don't know what they are, and they probably won't affect 99.9% of
users. Lack of support for binary extensions is likely to be way more
significant.


Lack of support for "zipped / bund

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Ryan Gonzalez]

I did that once; it wasn't worth it. It was no smaller than what
PyInstaller would output and required manually adding in the required
modules that weren't in the stdlib, along with any extra DLLs (e.g. the Qt
DLLs).


On Fri, May 29, 2015 at 4:45 PM, Paul Moore  wrote:

> On 29 May 2015 at 21:49, Glenn Linderman  wrote:
> >
> > That looks interesting, I wonder what compilation environment it would
> need?
> > I don't think I've even installed a C compiler on my last couple boxes,
> and
> > the only version of a C compiler I have is, umm... M$VC++6.0, since I've
> > moved to using Python for anything a 5 line batch file can't do...
> >
> >> One mildly annoying thing is that python3.dll is only installed in
> >> \DLLs, which typically isn't on PATH.
> >
> > Ah, linking so I guess if I figured out how to create this binary, it
> > would contain a reference to python3.dll that would attempt to be
> resolved
> > via the PATH, from what you say, and typically fail, due to PATH seldom
> > containing python3.dll.  The python launcher gets around that by (1)
> being
> > installed in %windir%, and going and finding the appropriate Python (per
> its
> > own configuration file, and command line parameters), and setting up the
> > path to that Python, which, when executed, knows its own directory
> structure
> > and can thus find its own python3.dll.
> >
> > The launcher, of course, adds an extra layer of process between the shell
> > and the program, because it launches the "real" Python executable.
> >
> >> So actually using the limited API from your own application fails by
> >> default.
> >> Fixing that's mostly a user admin issue, though (and you can just link
> >> to the full API and avoid the whole problem).
> >
> >
> > Do I understand correctly that the "user admin issue" means "add the
> > appropriate \DLLs to the PATH"?
> >
> > What I don't understand here is how linking to the full API avoids the
> > problem... it must put more python library code into the stub executable?
> > Enough to know how to search the registry to find the  dir>
> > for the version of Python from which the full API was obtained? Or
> something
> > else?
>
> Sorry, I assumed more Windows/C knowledge than you have.
>
> I'll work on this and produce proper binaries in due course, so you
> can always wait for them. But you can build the stub with pretty much
> anything, I suspect - I managed with MSVC 2010 and mingw. I'll add
> some build docs and get it on github.
>
> Using mingw
>
> gcc -Wall -O2 -o stub.exe stub.c -I \Include
> C:\Windows\system32\python34.dll
> strip -s stub.exe
>
> Using MSVC
>
> cl /Festub.exe /O2 stub.c /I\Include  home>\libs\python34.lib
>
> Regarding the DLLs, yes the "user admin issue" is adding the right
> directory to PATH. I used the phrase "admin issue" as it's the aspect
> that's likely to be far harder than any of the technical issues :-)
> The reason using the full API helps is that the full API references
> python34.dll rather than python3.dll. And the Python installer puts
> python34.dll on PATH automatically, as it's what the "python" command
> uses. (For the people with more Windows knowledge, I know this is a
> simplification, but it's close enough for now).
>
> So there are two  options with the code I posted.
>
> 1. Build an exe that uses a specific version of Python, but which will
> "just work" in basically the same way that the "python" command works.
> 2. Build an exe that works with any version of Python, but requires
> some setup from the user.
>
> Either approach requires that the Python DLL is on PATH, but that's
> far more likely with the version-specific one, just because of how the
> installer does things.
>
> With extra code, the stub could locate an appropriate Python DLL
> dynamically, which would simplify usage at the cost of a bit of fiddly
> code in the stub.
>
> This might be a useful addition to the zipapp module for Python 3.6.
>
> Paul
>
> PS Current launchers (py.exe, the entry point launchers from
> pip/setuptools, etc) tend to spawn the actual python program in a
> subprocess. I believe there are *technically* some differences in the
> runtime environment when you use an embedding approach like this, but
> I don't know what they are, and they probably won't affect 99.9% of
> users. Lack of support for binary extensions is likely to be way more
> significant.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-arch

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Ian Cordasco]

On Fri, May 29, 2015 at 4:14 PM, Gregory P. Smith  wrote:
>
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan  wrote:
>>
>>
>> On 29 May 2015 11:01 am, "Victor Stinner" 
>> wrote:
>> >
>> > Why not continue to enhance Python 3 instead of wasting our time with
>> > Python 2? We have limited resources in term of developers to maintain
>> > Python.
>> >
>> > (I'm not talking about fixing *bugs* in Python 2 which is fine with me.)
>>
>> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
>> isn't inherently rewarding enough for them to be willing to do it for free
>> on their own time.
>
>
> That is 100% okay.
>
> What is not okay is for python-dev representatives to respond to users (in
> any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3 can be
> backported to 2.7 with things akin to "just use Python 3" or "sorry, 2.7 is
> critical fixes only. move to python 3 already." This is actively driving our
> largest users away.  I bring this up because a user was bemoaning how
> useless they feel python core devs are because of this attitude recently.
> Leading to feelings of wishing to just abandon CPython if not Python all
> together.
>
> I'm sure I have even made some of those responses myself (sorry!). My point
> here is: know it. recognize it. don't do it anymore. It harms the community.
>
> A correct and accurate response to desires to make non-api-breaking changes
> in 2.7 is "Patches that do not change any APIs for 2.7 are welcome in the
> issue tracker." possibly including "I don't have the bandwidth to review 2.7
> changes, find someone on python-dev to review and champion this for you if
> you need it."  Finding someone may not always be easy. But at least is still
> the "patches welcome" attitude and suggests that the work can be done if
> someone is willing to do it. Lets make a concerted effort to not be hostile
> and against it by default.
>
> Ex: Is someone with a python application that is a million of lines supposed
> to have everyone involved in that drop the productive work they are doing
> and spend that porting their existing application to python 3 because we
> have so far failed to provide the tools to make that migration easy?  No.
> Empathize with our community.  Feel their pain.  (and everyone who is
> working on tools to aid the transition: keep doing that! Our users are gonna
> need it unless we don't want them as users anymore.)
>
> We committed to supporting 2.7 until 2020 in 2014 per
> https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
> important bug or performance fixes should at least be allowed on the table,
> even if hairy, even if you won't work on them yourselves on a volunteer
> basis. This is the first long term support release of Python ever. This is
> what LTS means.  LTS could also stand for Learn To Support...

At the same time, they can ask for it, but if people aren't motivated
to do the work for it, it won't happen. We should be encouraging (and
maybe even mentoring) these people who are desperately in need of the
fixes to be backported, to backport the patches themselves. With that
done, it can go through review and we can maybe get those fixes in
faster if we can also get a larger group of reviews.

The problem consists of a few parts:

- We're all volunteers
- Volunteers are going to work on what interests them
- Python 2.7 maintenance doesn't seem to interest many of our
volunteers currently

Perhaps we should explain this to each of the people requesting
backports to (ideally) encourage them.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 29 May 2015 at 21:49, Glenn Linderman  wrote:
>
> That looks interesting, I wonder what compilation environment it would need?
> I don't think I've even installed a C compiler on my last couple boxes, and
> the only version of a C compiler I have is, umm... M$VC++6.0, since I've
> moved to using Python for anything a 5 line batch file can't do...
>
>> One mildly annoying thing is that python3.dll is only installed in
>> \DLLs, which typically isn't on PATH.
>
> Ah, linking so I guess if I figured out how to create this binary, it
> would contain a reference to python3.dll that would attempt to be resolved
> via the PATH, from what you say, and typically fail, due to PATH seldom
> containing python3.dll.  The python launcher gets around that by (1) being
> installed in %windir%, and going and finding the appropriate Python (per its
> own configuration file, and command line parameters), and setting up the
> path to that Python, which, when executed, knows its own directory structure
> and can thus find its own python3.dll.
>
> The launcher, of course, adds an extra layer of process between the shell
> and the program, because it launches the "real" Python executable.
>
>> So actually using the limited API from your own application fails by
>> default.
>> Fixing that's mostly a user admin issue, though (and you can just link
>> to the full API and avoid the whole problem).
>
>
> Do I understand correctly that the "user admin issue" means "add the
> appropriate \DLLs to the PATH"?
>
> What I don't understand here is how linking to the full API avoids the
> problem... it must put more python library code into the stub executable?
> Enough to know how to search the registry to find the 
> for the version of Python from which the full API was obtained? Or something
> else?

Sorry, I assumed more Windows/C knowledge than you have.

I'll work on this and produce proper binaries in due course, so you
can always wait for them. But you can build the stub with pretty much
anything, I suspect - I managed with MSVC 2010 and mingw. I'll add
some build docs and get it on github.

Using mingw

gcc -Wall -O2 -o stub.exe stub.c -I \Include
C:\Windows\system32\python34.dll
strip -s stub.exe

Using MSVC

cl /Festub.exe /O2 stub.c /I\Include \libs\python34.lib

Regarding the DLLs, yes the "user admin issue" is adding the right
directory to PATH. I used the phrase "admin issue" as it's the aspect
that's likely to be far harder than any of the technical issues :-)
The reason using the full API helps is that the full API references
python34.dll rather than python3.dll. And the Python installer puts
python34.dll on PATH automatically, as it's what the "python" command
uses. (For the people with more Windows knowledge, I know this is a
simplification, but it's close enough for now).

So there are two  options with the code I posted.

1. Build an exe that uses a specific version of Python, but which will
"just work" in basically the same way that the "python" command works.
2. Build an exe that works with any version of Python, but requires
some setup from the user.

Either approach requires that the Python DLL is on PATH, but that's
far more likely with the version-specific one, just because of how the
installer does things.

With extra code, the stub could locate an appropriate Python DLL
dynamically, which would simplify usage at the cost of a bit of fiddly
code in the stub.

This might be a useful addition to the zipapp module for Python 3.6.

Paul

PS Current launchers (py.exe, the entry point launchers from
pip/setuptools, etc) tend to spawn the actual python program in a
subprocess. I believe there are *technically* some differences in the
runtime environment when you use an embedding approach like this, but
I don't know what they are, and they probably won't affect 99.9% of
users. Lack of support for binary extensions is likely to be way more
significant.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Gregory P. Smith]

On Fri, May 29, 2015 at 12:24 AM Nick Coghlan  wrote:

>
> On 29 May 2015 11:01 am, "Victor Stinner" 
> wrote:
> >
> > Why not continue to enhance Python 3 instead of wasting our time with
> > Python 2? We have limited resources in term of developers to maintain
> > Python.
> >
> > (I'm not talking about fixing *bugs* in Python 2 which is fine with me.)
>
> I'm actually OK with volunteers deciding that even fixing bugs in 2.7
> isn't inherently rewarding enough for them to be willing to do it for free
> on their own time.
>

That is 100% okay.

What is not okay is for python-dev representatives to respond to users (in
any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3 can
be backported to 2.7 with things akin to "just use Python 3" or "sorry, 2.7
is critical fixes only. move to python 3 already." This is actively driving
our largest users away.  I bring this up because a user was bemoaning how
useless they feel python core devs are because of this attitude recently.
Leading to feelings of wishing to just abandon CPython if not Python all
together.

I'm sure I have even made some of those responses myself (sorry!). My point
here is: know it. recognize it. don't do it anymore. It harms the community.

A correct and accurate response to desires to make non-api-breaking changes
in 2.7 is "Patches that do not change any APIs for 2.7 are welcome in the
issue tracker." possibly including "I don't have the bandwidth to review
2.7 changes, find someone on python-dev to review and champion this for you
if you need it."  Finding someone may not always be easy. But at least is
still the "patches welcome" attitude and suggests that the work can be done
if someone is willing to do it. Lets make a concerted effort to not be
hostile and against it by default.

Ex: Is someone with a python application that is a million of lines
supposed to have everyone involved in that drop the productive work they
are doing and spend that porting their existing application to python 3
because we have so far failed to provide the tools to make that migration
easy?  No.  Empathize with our community.  Feel their pain.  (and everyone
who is working on tools to aid the transition: keep doing that! Our users
are gonna need it unless we don't want them as users anymore.)

We committed to supporting 2.7 until 2020 in 2014 per
https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
important bug or performance fixes should at least be allowed on the table,
even if hairy, even if you won't work on them yourselves on a volunteer
basis. This is the first long term support release of Python ever. This is
what LTS means.  LTS could *also* stand for Learn To Support...

-gps

> Stepping up to extrinsically reward activities that are beneficial for
> customers but aren't intrinsically interesting enough for people to be
> willing to do for free is one of the key reasons commercial open source
> redistributors get paid.
>
> That more explicitly commercial presence is a dynamic we haven't
> historically had to deal with in core development, so there are going to be
> some growing pains as we find an arrangement that everyone is comfortable
> with (or is at least willing to tolerate, but I'm optimistic we can do
> better than that).
>
> Cheers,
> Nick.
>
> >
> > --
> >
> > By the way, I just wrote sixer, a new tool to generate patches to port
> > OpenStack to Python 3 :-)
> > https://pypi.python.org/pypi/sixer
> >
> > It's based on regex, so it's less reliable than 2to3, 2to6 or
> > modernize, but it's just enough for my specific use case. On
> > OpenStack, it's not possible to send one giant patch "hello, this is
> > python 3". Code is modified by small and incremental changes.
> >
> > Come on in the Python 3 world and... always look on the bright side of
> > life ( https://www.youtube.com/watch?v=VOAtCOsNuVM )!
> >
> > Victor
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
>
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>  ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Glenn Linderman]

On 5/29/2015 3:33 AM, Paul Moore wrote:

On 28 May 2015 at 22:09, Glenn Linderman  wrote:

This would be something I could use and benefit from immediately upon it
being available, so I laud your idea, and hope you have a successful
implementation, and look forward to using it.  It would largely replace the
need for the py.exe launcher for some classes of applications.

The following proof-of-concept works as is (based on my pretty minimal
testing), and only uses the limited API, so it should work with any
version of Python 3 (I've not tested it with Python 2, but I think the
only "new" API is PySys_SetArgvEx, which could be replaced with
PySys_SetArgv at a pinch). Excuse the dreadful coding style and lack
of error handling, I hacked it up in about an hour :-)


I have no particular interest in Python 2, having started with Python 3, 
and only used Python 2 for cases where dependent packages required it, 
and I've now reached the nirvana of all my dependency packages being 
ported to Python 3, although I have yet to port/test one remaining 
application to prove that. So I only mentioned Python 2 because it still 
could be useful for other people :)



(Actually, I just tried building on Python 2 - guess what - Unicode
:-) SetProgramName and SetArgvEx won't take Unicode values. The easy
fix is just not to use Unicode, the hard one is to do the encoding
dance, but I'm not going to bother...).


One approach would be to support Unicode arguments only for Python 3, 
but that would really be only paying lip service to Python 2 support.  
Another approach might be to not #define UNICODE for the Python 2 
version, and use the 8-bit Windows APIs, allowing Windows and the C 
runtime to do the encoding dance for you? Although I'm not sure what 
Python 2 requires in that respect.



#define UNICODE
#define _UNICODE
#include 
#include 

int
main()
{
 TCHAR program[MAX_PATH];
 LPWSTR *argv;
 int argc;
 PyObject *runpy;
 PyObject *ret;

 argv = CommandLineToArgvW(GetCommandLineW(), &argc);
 GetModuleFileName(NULL, program, MAX_PATH);
 Py_SetProgramName(program);  /* optional but recommended */
 Py_Initialize();
 PySys_SetArgvEx(argc, argv, 0);
 runpy = PyImport_ImportModule("runpy");
 if (!runpy) PyErr_Print();
 ret = PyObject_CallMethod(runpy, "run_path", "u", program);
 if (!ret) PyErr_Print();
 Py_Finalize();
 return 0;
}


That looks interesting, I wonder what compilation environment it would 
need?  I don't think I've even installed a C compiler on my last couple 
boxes, and the only version of a C compiler I have is, umm... M$VC++6.0, 
since I've moved to using Python for anything a 5 line batch file can't 
do...



One mildly annoying thing is that python3.dll is only installed in
\DLLs, which typically isn't on PATH.
Ah, linking so I guess if I figured out how to create this binary, 
it would contain a reference to python3.dll that would attempt to be 
resolved via the PATH, from what you say, and typically fail, due to 
PATH seldom containing python3.dll.  The python launcher gets around 
that by (1) being installed in %windir%, and going and finding the 
appropriate Python (per its own configuration file, and command line 
parameters), and setting up the path to that Python, which, when 
executed, knows its own directory structure and can thus find its own 
python3.dll.


The launcher, of course, adds an extra layer of process between the 
shell and the program, because it launches the "real" Python executable.



So actually using the limited API from your own application fails by default.
Fixing that's mostly a user admin issue, though (and you can just link
to the full API and avoid the whole problem).


Do I understand correctly that the "user admin issue" means "add the 
appropriate \DLLs to the PATH"?


What I don't understand here is how linking to the full API avoids the 
problem... it must put more python library code into the stub 
executable? Enough to know how to search the registry to find the 
 for the version of Python from which the full API 
was obtained? Or something else?


Are there other alternatives?  Assuming that the reference to the 
missing DLL is not required until the point at which a symbol from it is 
first referenced, so that the stub would have some ability to do 
something before that first call, maybe...


1. The stub above could be enhanced to contained a "hard coded"
   directory that it adds to the PATH itself?
2. The stub above could be enhanced to define that its first parameter
   is the , and tweak its PATH.
3. These days, the Python installer does offer to optionally add itself
   to the PATH. Is that sufficient to make the stub work?
4. The launcher could be used, assuming it is installed, but then you
   don't need a stub, and you get the extra process layer.
5. stubpy.cmd could be created, a four line batch file below [1], which
   wouldn't require the launcher or its extra process layer, but would

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2015-05-22 - 2015-05-29)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4844 (+11)
  closed 31241 (+47)
  total  36085 (+58)

Open issues with patches: 2217 


Issues opened (38)
==

#23970: Update distutils.msvccompiler for VC14
http://bugs.python.org/issue23970  reopened by benjamin.peterson

#23996: _PyGen_FetchStopIterationValue() crashes on unnormalised excep
http://bugs.python.org/issue23996  reopened by scoder

#24267: test_venv.EnsurePipTest.test_with_pip triggers version check o
http://bugs.python.org/issue24267  opened by vadmium

#24270: PEP 485 (math.isclose) implementation
http://bugs.python.org/issue24270  opened by ncoghlan

#24272: PEP 484 docs
http://bugs.python.org/issue24272  opened by gvanrossum

#24274: erroneous comments in dictobject.c
http://bugs.python.org/issue24274  opened by Jim.Jewett

#24277: Take the new email package features out of provisional status
http://bugs.python.org/issue24277  opened by r.david.murray

#24278: Docs on Parsing arguments should say something about mem mgmt 
http://bugs.python.org/issue24278  opened by blais

#24279: Update test_base64 to use test.support.script_helper
http://bugs.python.org/issue24279  opened by bobcatfish

#24280: Unable to install Python
http://bugs.python.org/issue24280  opened by Jeff77789

#24284: Inconsistency in startswith/endswith
http://bugs.python.org/issue24284  opened by serhiy.storchaka

#24287: Let ElementTree prolog include comments and processing instruc
http://bugs.python.org/issue24287  opened by rhettinger

#24290: c_uint32 bitfields break structures
http://bugs.python.org/issue24290  opened by Rony Batista

#24291: wsgiref.handlers.SimpleHandler truncates large output blobs
http://bugs.python.org/issue24291  opened by Jonathan Kamens

#24292: wsgiref.simple_server.WSGIRequestHandler doesn't log request t
http://bugs.python.org/issue24292  opened by Jonathan Kamens

#24294: DeprecationWarnings should be visible by default in the intera
http://bugs.python.org/issue24294  opened by njs

#24295: Backport of #17086 causes regression in setup.py
http://bugs.python.org/issue24295  opened by moritzs

#24296: Queue documentation note needed
http://bugs.python.org/issue24296  opened by Sandy Chapman

#24299: 2.7.10 test__locale.py change breaks on Solaris
http://bugs.python.org/issue24299  opened by jbeck

#24300: Code Refactoring  in function nis_mapname()
http://bugs.python.org/issue24300  opened by pankaj.s01

#24301: gzip module failing to decompress valid compressed file
http://bugs.python.org/issue24301  opened by Eric Gorr

#24302: Dead Code of Handler check in function faulthandler_fatal_erro
http://bugs.python.org/issue24302  opened by pankaj.s01

#24303: OSError 17 due to _multiprocessing/semaphore.c assuming a one-
http://bugs.python.org/issue24303  opened by Paul Hobbs

#24305: The new import system makes it impossible to correctly issue a
http://bugs.python.org/issue24305  opened by njs

#24306: Backport py.exe to 3.4
http://bugs.python.org/issue24306  opened by steve.dower

#24307: pip error on windows whose current user name contains non-asci
http://bugs.python.org/issue24307  opened by tanbro-liu

#24308: Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3
http://bugs.python.org/issue24308  opened by koobs

#24309: string.Template should be using str.format and/or deprecated
http://bugs.python.org/issue24309  opened by vlth

#24310: Idle documentation -- what to do if you do not see an undersco
http://bugs.python.org/issue24310  opened by lac

#24313: json fails to serialise numpy.int64
http://bugs.python.org/issue24313  opened by thomas-arildsen

#24314: irrelevant cross-link in documentation of user-defined functio
http://bugs.python.org/issue24314  opened by july

#24317: Change installer Customize default to match quick settings
http://bugs.python.org/issue24317  opened by steve.dower

#24318: Better documentaiton of profile-opt (and release builds in gen
http://bugs.python.org/issue24318  opened by skip.montanaro

#24319: Crash during "make coverage-report"
http://bugs.python.org/issue24319  opened by skip.montanaro

#24320: Remove a now-unnecessary workaround from importlib._bootstrap.
http://bugs.python.org/issue24320  opened by eric.snow

#24322: Hundreds of linker warnings on Windows
http://bugs.python.org/issue24322  opened by BreamoreBoy

#24323: Typo in Mutable Sequence Types documentation.
http://bugs.python.org/issue24323  opened by eimista

#24324: Remove -Wunreachable-code flag
http://bugs.python.org/issue24324  opened by skip.montanaro



Most recent 15 issues with no replies (15)
==

#24324: Remove -Wunreachable-code flag
http://bugs.python.org/issue24324

#24322: Hundreds of linker warnings on Windows
http://bugs.python.org/issue24322

#24319: Crash during "make coverag

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Terry Reedy]

On 5/28/2015 4:29 PM, Paul Moore wrote:

On 28 May 2015 at 20:47, Brett Cannon  wrote:

I think it's to have a single tool to do it for any platform, not to have
the technical nuts and bolts be the same necessarily. I think it's also to
figure out if there is anything the interpreter and/or stdlib can do to
facilitate this.


Precisely. At the moment, the story seems to be "if you're on Windows,
use py2exe, if you're on OSX use py2app, or on Unix, ..., or..."

What would be a compelling story is "to build your app into a single
file executable, do "python -m build ". The machinery behind
the build can be as different as necessary - but being able to use the
same command on every platform is the goal.


The python-based ren'py visual novel development system has something 
like this  When one is ready to publish, there is an easy option to 
build single-file downloadable redistributables for any or all of 
Windows, Linux, and Mac.  I know it works as far as it goes because I 
help my wife use the system not for a novel, but a photo-based tutorial. 
 After testing the resulting files with the help of others on linux and 
mac systems (we developed on Windows), she put the files up on one of 
her university pages.


As far as I know, the build code should be Python, if anyone want to 
look at it.


--
Terry Jan Reedy

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

Re: [Python-Dev] Single-file Python executables (including case of self-sufficient package manager)

[Paul Sokolovsky]

Hello,

On Fri, 29 May 2015 08:35:44 -0400
Donald Stufft  wrote:

[]
 
> Another example is one that I personally worked on recently, where
> the company I worked for wanted to distribute a CLI to our customers
> which would "just work" that they could use to interact with the
[]
> particular piece I was feeling like I should be suggesting to my
> manager that we throw away the Python code and just write it in Go.

Please consider next time thinking about MicroPython for this usecase,
as that's exactly why there're people who think that MicroPython is
interesting for "desktop" systems, not just bare-metal
microcontrollers. There're too few such people so far, unfortunately,
so progress is slow.

> An example of a product that does this is Chef, they install their
> own Ruby and everything but libc into /opt/chef to completely isolate
> themselves from the host system. I’m told this made things *much*
> easier for them as they don't really have to worry at all about
> what's available on the host system, Chef pretty much just works.

[]
> As folks may or may not know, I'm heavily involved in pip which is
> probably one of the most widely used CLIs written in Python. A single
> file executable won't help pip, however through my experience there I

It's interesting you bring up this case of pip (and Chef), as I had
similar concerns/issues when developing a self-hosted package manager
for MicroPython. MicroPython doesn't come out of the box with standard
library - beyond few builtin modules ("core" library), every other
module/package needs to be installed individually (micropython-*
modules on PyPI). That makes a package manager a critical component, and
means that package manager itself cannot rely on standard library -
presence, absence, of specific version (or contents of standard
modules).

My initial idea was to write single-file script, but we're not ready
for self-sufficiency yet anyway (no SSL support, have to rely on wget),
and it's a bit of chore anyway. So instead, I made a semi-automated
"library subset package" (e.g. os renamed to upip_os), and all such
modules comes package together with the main script:
https://github.com/micropython/micropython-lib/tree/master/upip ,
https://pypi.python.org/pypi/micropython-upip . Then we have a script
to bootstrap upip:
https://github.com/micropython/micropython/blob/master/tools/bootstrap_upip.sh ,
after which any package can be installed using upip proper.



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

[André Freitas]

Speaking about distribution I believe Pip is the simplest way of
distributing. I have used some freezing tools in the past such cxfreeze but
with more complex projects they start being hard to manage. Now instead of
saying people to goto an url, download and put in the path I just say: pip
install 

Unfortunately, this approach only works well with products built for
developers.

A Sex, 29/05/2015, 13:50, Donald Stufft  escreveu:

>
>
> On May 29, 2015 at 2:58:28 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
> > On 29 May 2015 9:48 am, "Donald Stufft" wrote:
> > >
> > >
> > >
> > > On May 28, 2015 at 7:40:26 PM, Nick Coghlan (ncogh...@gmail.com)
> wrote:
> > > > >
> > > > > One thing I've seen more than once is that new development happens
> > > > in Python
> > > > > until the problem is understood, then the code is ported to Go.
> > > > Python's
> > > > > short path from idea to working code, along with its ability
> > > > to quickly morph
> > > > > as requirements and understanding changes, its batteries
> > > > included philosophy,
> > > > > and its "fits-your-brain" consistency are its biggest strengths!
> > > >
> > > >
> > > > Right, Go is displacing C/C++ in that regard (moreso than Python
> > > > itself), and now that Rust has hit 1.0, I expect we'll see it
> becoming
> > > > another contender for this task. Rust's big advantage over Go
> > > > in that regard is being compatible with the C/C++ ecosystem,
> > > > including Python's cffi.
> > > >
> > >
> > > I’m not sure if I’m reading this right or not, but just to be clear,
> I’ve
> > > seen a number of people express the sentiment that they are switching
> from
> > > Python to Go and that the deployment story is one of the reasons. It’s
> not
> > > just people switching from C/C++.
> >
> > C and C++ used to be the main "second version" languages used to create
> > statically linked standalone binaries after an initial prototype in
> Python.
> >
> > Folks that learned Python first understandably weren't keen on that idea,
> > so they tended to either use Cython (or its predecessor, Pyrex), or else
> > not bother doing it at all until first Go and now Rust came along (for
> > reasons unknown to me, D appears to have never gained any popularity
> > outside the ACM crowd).
> >
> > If I seem blase about Go, that's the main reason why - the benefits it
> > offers aren't novel from the point of view of C/C++ programmers, they're
> > just now available without having to put up with arcane syntax, manual
> > memory management, an unmaintainable threading model, relatively poor
> > support for text manipulation, etc, etc.
> >
>
> I don't think Go is going to "kill" Python or anything, but I do think that
> not taking a look at other languages and why people are picking them over
> Python is important, otherwise we will end up dying (and would deserve to)
> because we'd be like the big company that didn't bother to keep up with the
> times and just assumed we'd be big forever. I talk to a lot of people about
> the distribution story of Python applications, what works and what doesn't.
> A very large majority of the people who have used both Go and Python in a
> serious capacity have indicated that they've at least considered writing
> new
> things in Go instead of Python due to the fact that distributing it is much
> easier and a not insignificant number of them have in fact started to
> switch
> to using Go in situations where they are trying to distribute things to
> disparate boxes.
>
> This might be something that people could have done before with C/C++ but
> with
> a nicer language behind it... but that's kind of the point? You don't need
> to
> be stuck with a terrible language to get a nice single file executable
> anymore,
> you can get that and use a good language at the same time which makes it a
> lot
> more compelling to a lot more people than having to be stuck with C.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/p.andrefreitas%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

[Yury Selivanov]

Hi Ben,

Is there any real-world scenario where you would need this?

It looks like this can help with debugging, somehow, but the easiest
solution is to put a "if debug: log(...)" before "yield" in your
"switch()" function.  You'll have a perfect traceback there.

Thanks,
Yury

On 2015-05-29 12:46 AM, Ben Leslie wrote:

Hi all,

Apologies in advance; I'm not a regular, and this may have been
handled already (but I couldn't find it when searching).

I've been using the new async/await functionality (congrats again to
Yury on getting that through!), and I'd like to get a stack trace
between the place at which blocking occurs and the outer co-routine.

For example, consider this code:

"""
async def a():
 await b()

async def b():
 await switch()

@types.coroutine
def switch():
 yield

coro_a = a()
coro_a.send(None)
"""

At this point I'd really like to be able to somehow get a stack trace
similar to:

test.py:2
test.py:4
test.py:9

Using the gi_frame attribute of coro_a, I can get the line number of
the outer frame (e.g.: line 2), but from there there is no way to
descend the stack to reach the actual yield point.

I thought that perhaps the switch() co-routine could yield the frame
object returned from inspect.currentframe(), however once that
function yields that frame object has f_back changed to None.

A hypothetical approach would be to work the way down form the
outer-frame, but that requires getting access to the co-routine object
that the outer-frame is currently await-ing. Some hypothetical code
could be:

"""
def show(coro):
 print("{}:{}".format(coro.gi_frame.f_code.co_filename,
coro.gi_frame.f_lineno))
 if dis.opname[coro.gi_code.co_code[coro.gi_frame.f_lasti + 1]] ==
'YIELD_FROM':
 show(coro.gi_frame.f_stack[0])
"""

This relies on the fact that an await-ing co-routine will be executing
a YIELD_FROM instruction. The above code uses a completely
hypothetical 'f_stack' property of frame objects to pull the
co-routine object which a co-routine is currently await-ing from the
stack. I've implemented a proof-of-concept f_stack property in the
frameobject.c just to test out the above code, and it seems to work.

With all that, some questions:

1) Does anyone else see value in trying to get the stack-trace down to
the actual yield point?
2) Is there a different way of doing it that doesn't require changes
to Python internals?
3) Assuming no to #2 is there a better way of getting the information
compared to the pretty hacking byte-code/stack inspection?

Thanks,

Ben
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com


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

Re: [Python-Dev] Not getting the exact file to start

[Brett Cannon]

This mailing list is for the development *of* Python, not *with* it. Your
best option for getting help like this is python-l...@python.org.

On Fri, May 29, 2015 at 9:36 AM Saket Sourav 
wrote:

> Hello sir.
> I have just installed python 3.4.2.
> I'm not getting the file 'IDLE (python GUI)'
> to start programming.
> Or which file I should open to write code
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Not getting the exact file to start

[Saket Sourav]

Hello sir.
I have just installed python 3.4.2.
I'm not getting the file 'IDLE (python GUI)'
to start programming.
Or which file I should open to write code
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Antoine Pitrou]

On Fri, 29 May 2015 18:36:02 +1000
Steven D'Aprano  wrote:
> 
> The point is, in the Linux circles I move in, this idea of single file 
> installation would be about as popular as a police raid at a rave club. 

This is frankly not true. There are many programs (e.g. games) which are
not available as distribution packages, and can't rely on the user's
distribution to provide the right versions of the required pieces of
infrastructure. Those programs have to bundle the whole stack
independently.

Perhaps in *your* Linux circle you never use such programs, but they do
exist and are part of the ecosystem.

Regards

Antoine.


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

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

[Donald Stufft]

On May 29, 2015 at 2:58:28 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
> On 29 May 2015 9:48 am, "Donald Stufft" wrote:
> >
> >
> >
> > On May 28, 2015 at 7:40:26 PM, Nick Coghlan (ncogh...@gmail.com) wrote:
> > > >
> > > > One thing I've seen more than once is that new development happens
> > > in Python
> > > > until the problem is understood, then the code is ported to Go.
> > > Python's
> > > > short path from idea to working code, along with its ability
> > > to quickly morph
> > > > as requirements and understanding changes, its batteries
> > > included philosophy,
> > > > and its "fits-your-brain" consistency are its biggest strengths!
> > >
> > >
> > > Right, Go is displacing C/C++ in that regard (moreso than Python
> > > itself), and now that Rust has hit 1.0, I expect we'll see it becoming
> > > another contender for this task. Rust's big advantage over Go
> > > in that regard is being compatible with the C/C++ ecosystem,
> > > including Python's cffi.
> > >
> >
> > I’m not sure if I’m reading this right or not, but just to be clear, I’ve
> > seen a number of people express the sentiment that they are switching from
> > Python to Go and that the deployment story is one of the reasons. It’s not
> > just people switching from C/C++.
>  
> C and C++ used to be the main "second version" languages used to create
> statically linked standalone binaries after an initial prototype in Python.
>  
> Folks that learned Python first understandably weren't keen on that idea,
> so they tended to either use Cython (or its predecessor, Pyrex), or else
> not bother doing it at all until first Go and now Rust came along (for
> reasons unknown to me, D appears to have never gained any popularity
> outside the ACM crowd).
>  
> If I seem blase about Go, that's the main reason why - the benefits it
> offers aren't novel from the point of view of C/C++ programmers, they're
> just now available without having to put up with arcane syntax, manual
> memory management, an unmaintainable threading model, relatively poor
> support for text manipulation, etc, etc.
>  

I don't think Go is going to "kill" Python or anything, but I do think that
not taking a look at other languages and why people are picking them over
Python is important, otherwise we will end up dying (and would deserve to)
because we'd be like the big company that didn't bother to keep up with the
times and just assumed we'd be big forever. I talk to a lot of people about
the distribution story of Python applications, what works and what doesn't.
A very large majority of the people who have used both Go and Python in a
serious capacity have indicated that they've at least considered writing new
things in Go instead of Python due to the fact that distributing it is much
easier and a not insignificant number of them have in fact started to switch
to using Go in situations where they are trying to distribute things to
disparate boxes.

This might be something that people could have done before with C/C++ but with
a nicer language behind it... but that's kind of the point? You don't need to
be stuck with a terrible language to get a nice single file executable anymore,
you can get that and use a good language at the same time which makes it a lot
more compelling to a lot more people than having to be stuck with C.

---  
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Donald Stufft]

On May 29, 2015 at 4:37:37 AM, Steven D'Aprano (st...@pearwood.info) wrote:
> On Thu, May 28, 2015 at 01:20:06PM -0400, Donald Stufft wrote:
>  
> > I think it’s an issue for all platforms, even when there is a system Python
> > that can be used.
> >
> > Here’s why:
> >
> > * Even on Linux systems Python isn’t always a guaranteed thing to be 
> > installed,
> > for instance Debian works just fine without any Python installed.
>  
> Donald, are you a Linux user? If so, which distro? Because in the Linux
> world that I'm familiar with, this (and the points you make below) are
> absolutely not an issue. You let the package manager worry about
> dependencies:
>  
> yum install myapp # Red Hat based distros
> apt-get install myapp # Debian based distros
>  
> will ensure that the right version of Python is installed.
>  
> In the circles I move in, installing anything which does not go through
> the package manager is considered to be quite dubious. In order of
> preference (best to worst):
>  
> - install from official distro repositories;
> - install from a third-party repo;
> - install from source;
> - find an alternative application;
> - do without;
> - install from some binary format (also known as "would you like
> a root kit with that?").
>  
>  
> [...]
> > * Even if you have Python installed already, is it the right one? What if 
> > it’s
> > an ancient RHEL box that has 2.6 or (heaven forbid) 2.4? What if it’s a not
> > ancient box that has Python 2.7 but you want to deploy your app in Python 3?
>  
> Most recent distros have both a python2 and python3 package, and when
> building your rpm or deb file, you specify which is your dependency in
> the normal fashion.
>  
>  
> > * What if you have Python installed already, but it’s been patched by the 
> > place
> > you got it from and now the behavior is different than what you expected?
>  
> Normally you would write for the version of Python provided by the
> distros you wish to support. In practice that might mean writing hybrid
> code targetting (say) 2.6 and 2.7, which covers most recent Red Hat and
> Debian based systems, and anything else, you provide the source code and
> let the user work it out.
>  
> I suppose that in principle you could include whatever version of Python
> you like *in your application*, but that would be considered an unusual
> thing to do. I believe that LibreOffice and OpenOffice do that, so they
> can support Python as a scripting language, but they're generally
> considered (1) a special case because they're cross-platform, and (2)
> not "proper" Unix or Linux apps anyway.
>  
> The point is, in the Linux circles I move in, this idea of single file
> installation would be about as popular as a police raid at a rave club.
> Maybe you move in different circles (perhaps more enterprisey?), but I
> can already imagine the sort of derogatory comments the sys admins I
> work with would make about this idea.
>  

I use Linux for servers yes, I don't stick with a single Distribution and right
now I manage services that are running on CentOS, Ubuntu, Debian, Alpine, and
FreeBSD (not a Linux, but w/e). 

Here's the thing though, when you make software that is designed for other
people to consume you have two choices. Either you have to try to anticipate
every single environment that they might possibly run it in and what is
available there so that your software either runs there or you can provide
instructions on how to run it there, or you need to depend on as little from
the OS as possible.

An example of a product that does this is Chef, they install their own Ruby
and everything but libc into /opt/chef to completely isolate themselves from
the host system. I’m told this made things *much* easier for them as they
don't really have to worry at all about what's available on the host system,
Chef pretty much just works.

Another example is one that I personally worked on recently, where the company
I worked for wanted to distribute a CLI to our customers which would
"just work" that they could use to interact with the service we provided. We
were writing this client in Python and it was very painful to satisfy the
requirement that it work without Python installed as a single file executable.
That was a hard requirement as anything else would be more difficult to
distribute to end users and be more likely to break. The entire time I was
working on that particular piece I was feeling like I should be suggesting to
my manager that we throw away the Python code and just write it in Go.

As folks may or may not know, I'm heavily involved in pip which is probably one
of the most widely used CLIs written in Python. A single file executable won't
help pip, however through my experience there I can tell you that a significant
portion of our issues come from random weird differences in how a particular
person's Python environment is setup. If someone is distributing a CLI app
written in Python, being able to remain independent from the OS

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

[Antoine Pitrou]

On Fri, 29 May 2015 21:39:55 +1000
Nick Coghlan  wrote:
> The key is whether or not we can readily notify people when the "most
> recent known good" hash *changes*, and less about the mechanics of how we
> then record the history of which commits *were* stable, or the identity of
> the most recent commit.
> 
> That said, prompted by Nathaniel's comment, I realised that having a
> "post-BuildBot" stable repo is one possible way we could achieve that. That
> way we could introduce merge gating without needing to change anything at
> all about how we manage the current development repo, we'd just push stable
> versions to a separate repo that only the BuildBot master (or a dedicated
> service monitoring for successful cross-platform BuildBot runs) and the
> release managers had permissions to push to.

Any amount of merge gating or other automated workflow is dependent on
stabilizing our test suite and buildbot fleet, so that regressions can
be unambiguously spotted. 

Regards

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

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

[Nick Coghlan]

On 29 May 2015 20:24, "Stephen J. Turnbull"  wrote:
>
> Nathaniel Smith writes:
>
>  > DVCS back in the day :-). Unfortunately hg makes this a little
>  > trickier than it could be, because in hg the same commit can't be in
>  > two different branches; but this just means you have to insert some
>  > no-op merges, oh well.
>
> Don't use named branches ("friends don't let friends ...").  Use
> bookmarks.  Theoretically that should work fine.

The key is whether or not we can readily notify people when the "most
recent known good" hash *changes*, and less about the mechanics of how we
then record the history of which commits *were* stable, or the identity of
the most recent commit.

That said, prompted by Nathaniel's comment, I realised that having a
"post-BuildBot" stable repo is one possible way we could achieve that. That
way we could introduce merge gating without needing to change anything at
all about how we manage the current development repo, we'd just push stable
versions to a separate repo that only the BuildBot master (or a dedicated
service monitoring for successful cross-platform BuildBot runs) and the
release managers had permissions to push to.

The commit hooks on that *stable* repo could then be used to trigger third
party test suites only for builds that at least passed CPython's own test
suite.

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Sokolovsky]

Hello,

On Fri, 29 May 2015 20:53:53 +1000
Steven D'Aprano  wrote:

[ insightful statistics skipped ]

> I think there are some exciting and interesting languages coming up: 
> Swift, Julia, Go, Rust and others. 

Only those? Every one in a dozen university student comes up with an
exciting, interesting language - it has always been like that. Further
development and maintenance is what levels it below the common crowd.

> Why are we threatened by this?

Because at least some of them are backed by media companies, who use
them as leverage for their advertisement and PR campaigns. Obviously,
media companies already have great advertisement influence, and can
fool anybody's head with their tricks.

> Python makes a wonderful glue language. It would be great for Python
> to glue to more than just C and Fortran code. For scientific users,
> imagine being able to call Julia code from Python, and vice versa.

There "always" were things like integration of Python and Lua, etc.
Did somebody use them? No, they're of interest only to their authors. 

> Instead of thinking of Go as an opponent to beat, wouldn't it be
> great to be able to write extensions in a modern language like Go,
> Rust or D instead of creaky old C with all its safety issues?

Because very few people use Go, Rust, or D at all. And then they're
likely concentrated in a small niche. Going 2-level, using experimental
language L in an area A, where A is arbitrary/random, has almost zero
interest for majority of population. Let's wait till Rust becomes
real rust and talk again.

> -- 
> Steve


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Steven D'Aprano]

On Fri, May 29, 2015 at 07:08:43AM +1000, Nick Coghlan wrote:
> On 29 May 2015 05:25, "Chris Barker"  wrote:
> >
> > OK, I'm really confused here:
> >
> > 1) what the heck is so special about go all of a sudden? People have been
> > writing and deploying single file executables built with C and ++, 
> > and whatever else? forever. (and indeed, it was a big sticking point 
> > for me when I introduced python in my organization)
> 
> For scientific Python folks, the equivalent conversations I have are about
> Julia.
> 
> If you're not used to thinking of Python's competitive position as "best
> orchestration language, solid competitor in any given niche", then the rise
> of niche specific competitors like Go & Julia can feel terrifying, as the
> relatively narrow user base changes the trade-offs you can make in the
> language & ecosystem design to better optimise them for that purpose.

We've been there before, with the "Ruby is the Python-killer" FUD of a 
few years ago. If Go is different and does overtake Python, I think it 
will be due to its privileged position on Android.

Personally, I don't pay a lot of attention to language popularity 
statistics. Who cares whether Python is used by 8% of projects or 10% of 
projects? Either way, it's huge. But from time to time, it might be 
useful to look at a few different measurements of popularity.

According to CodeEval, Python is still *by far* the most popular 
language, at 31.2% (second place is below 20%), with Go at #9 with 2.3%.

According to Redmonk, Python is stable at #4, while Go has jumped from 
#21 to #17 in six months.

LangPop gives various different measures of popularity, and according to 
the overall summary, Python is at #6, but Go doesn't appear to be a 
language they look at.

TIOBE has Python moving up two places to #6, and Go (which was the 2009 
"Hall Of Fame" winner) doesn't even appear in the top 100.

http://blog.codeeval.com/codeevalblog/2015
http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15/
http://langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html


I think there are some exciting and interesting languages coming up: 
Swift, Julia, Go, Rust and others. Why are we threatened by this? Python 
makes a wonderful glue language. It would be great for Python to glue to 
more than just C and Fortran code. For scientific users, imagine being 
able to call Julia code from Python, and vice versa. Instead of thinking 
of Go as an opponent to beat, wouldn't it be great to be able to write 
extensions in a modern language like Go, Rust or D instead of creaky old 
C with all its safety issues?



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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Stephen J. Turnbull]

Paul Moore writes:

 > In my environments, we frequently have ancient versions of RHEL
 > installed, sometimes with no Python at all (IIRC) or nothing better
 > than 2.4.

That's pretty advanced as older Red Hat systems go.  You're lucky it
isn't 1.5.2!

Getting serious, Red Hat systems have included Python for about as
long as the youngest core committers have been alive, and I'm sure
that goes back before they called it "Enterprise" Linux.



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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 28 May 2015 at 22:09, Glenn Linderman  wrote:
> This would be something I could use and benefit from immediately upon it
> being available, so I laud your idea, and hope you have a successful
> implementation, and look forward to using it.  It would largely replace the
> need for the py.exe launcher for some classes of applications.

The following proof-of-concept works as is (based on my pretty minimal
testing), and only uses the limited API, so it should work with any
version of Python 3 (I've not tested it with Python 2, but I think the
only "new" API is PySys_SetArgvEx, which could be replaced with
PySys_SetArgv at a pinch). Excuse the dreadful coding style and lack
of error handling, I hacked it up in about an hour :-)

(Actually, I just tried building on Python 2 - guess what - Unicode
:-) SetProgramName and SetArgvEx won't take Unicode values. The easy
fix is just not to use Unicode, the hard one is to do the encoding
dance, but I'm not going to bother...).

#define UNICODE
#define _UNICODE
#include 
#include 

int
main()
{
TCHAR program[MAX_PATH];
LPWSTR *argv;
int argc;
PyObject *runpy;
PyObject *ret;

argv = CommandLineToArgvW(GetCommandLineW(), &argc);
GetModuleFileName(NULL, program, MAX_PATH);
Py_SetProgramName(program);  /* optional but recommended */
Py_Initialize();
PySys_SetArgvEx(argc, argv, 0);
runpy = PyImport_ImportModule("runpy");
if (!runpy) PyErr_Print();
ret = PyObject_CallMethod(runpy, "run_path", "u", program);
if (!ret) PyErr_Print();
Py_Finalize();
return 0;
}

One mildly annoying thing is that python3.dll is only installed in
\DLLs, which typically isn't on PATH. So actually
using the limited API from your own application fails by default.
Fixing that's mostly a user admin issue, though (and you can just link
to the full API and avoid the whole problem).

> Of course, per other disccusions, this doesn't solve the problem for:
>
> A) machine without Python installed
> B) programs that need binary extensions
>
> Other discussions have suggested:
>
> 3) The stub could offer to download and install Python
>
> A corollary:
>
> 4) The stub could offer to download and install the needed binary extensions
> as well as Python. This would require the installation uniformity of
> something like pip, so perhaps would be restricted to extensions available
> via pip.  And it would be much enhanced by some technique where the zipapp
> would contain metadata readable by the stub, that would declare the list of
> binary extensions required.  Or, of course, it could even declare non-binary
> extension that are not packaged with the zipapp, if the process is smooth,
> the modules available via pip, etc., as a tradeoff.

I'm pretty strongly against downloading interpreters or extensions.
Apart from the pretty huge added complexity, as a user I'm not sure
I'd trust a supposedly simple application I'd received if it started
asking to download stuff unexpectedly...

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

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

[Stephen J. Turnbull]

Nathaniel Smith writes:

 > DVCS back in the day :-). Unfortunately hg makes this a little
 > trickier than it could be, because in hg the same commit can't be in
 > two different branches; but this just means you have to insert some
 > no-op merges, oh well.

Don't use named branches ("friends don't let friends ...").  Use
bookmarks.  Theoretically that should work fine.

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 29 May 2015 at 09:36, Steven D'Aprano  wrote:
> The point is, in the Linux circles I move in, this idea of single file
> installation would be about as popular as a police raid at a rave club.
> Maybe you move in different circles (perhaps more enterprisey?), but I
> can already imagine the sort of derogatory comments the sys admins I
> work with would make about this idea.

In my environments, we frequently have ancient versions of RHEL
installed, sometimes with no Python at all (IIRC) or nothing better
than 2.4. The sysadmins won't install newer versions, as Python isn't
formally needed, but we'd happily use it for adhoc admin-style scripts
(the alternative is typically shell scripts or nothing). It's not
precisely acceptable, but being able to create a single-file small
executable in the support user's home directory made from an admin
script would be immensely useful.

It's hardly a core use case, and we generally just live with shell
scripts, but such environments *do* exist :-(

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

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Steven D'Aprano]

On Thu, May 28, 2015 at 01:20:06PM -0400, Donald Stufft wrote:

> I think it’s an issue for all platforms, even when there is a system Python
> that can be used.
> 
> Here’s why:
> 
> * Even on Linux systems Python isn’t always a guaranteed thing to be 
> installed,
>   for instance Debian works just fine without any Python installed.

Donald, are you a Linux user? If so, which distro? Because in the Linux 
world that I'm familiar with, this (and the points you make below) are 
absolutely not an issue. You let the package manager worry about 
dependencies:

yum install myapp  # Red Hat based distros
apt-get install myapp  # Debian based distros

will ensure that the right version of Python is installed.

In the circles I move in, installing anything which does not go through 
the package manager is considered to be quite dubious. In order of 
preference (best to worst):

- install from official distro repositories;
- install from a third-party repo;
- install from source;
- find an alternative application;
- do without;
- install from some binary format (also known as "would you like
  a root kit with that?").


[...]
> * Even if you have Python installed already, is it the right one? What if it’s
>   an ancient RHEL box that has 2.6 or (heaven forbid) 2.4? What if it’s a not
>   ancient box that has Python 2.7 but you want to deploy your app in Python 3?

Most recent distros have both a python2 and python3 package, and when 
building your rpm or deb file, you specify which is your dependency in 
the normal fashion.


> * What if you have Python installed already, but it’s been patched by the 
> place
>   you got it from and now the behavior is different than what you expected?

Normally you would write for the version of Python provided by the 
distros you wish to support. In practice that might mean writing hybrid 
code targetting (say) 2.6 and 2.7, which covers most recent Red Hat and 
Debian based systems, and anything else, you provide the source code and 
let the user work it out.

I suppose that in principle you could include whatever version of Python 
you like *in your application*, but that would be considered an unusual 
thing to do. I believe that LibreOffice and OpenOffice do that, so they 
can support Python as a scripting language, but they're generally 
considered (1) a special case because they're cross-platform, and (2) 
not "proper" Unix or Linux apps anyway.

The point is, in the Linux circles I move in, this idea of single file 
installation would be about as popular as a police raid at a rave club. 
Maybe you move in different circles (perhaps more enterprisey?), but I 
can already imagine the sort of derogatory comments the sys admins I 
work with would make about this idea. 



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

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

[Nathaniel Smith]

On Thu, May 28, 2015 at 11:40 PM, Nick Coghlan  wrote:
>
> On 29 May 2015 9:17 am, "Antoine Pitrou"  wrote:
>>
>> On Thu, 28 May 2015 08:48:11 +1000
>> Nick Coghlan  wrote:
>
>> > After all, the real difference between the alphas and the final releases
>> > isn't about anything *we* do, it's about the testing *other people* do
>> > that
>> > picks up gaps in our test coverage. A gated trunk makes it more feasible
>> > for other projects to do continuous integration against it.
>>
>> Long ago (before I became a core developer) we had "community
>> buildbots" for that. They didn't receive any attention or maintenance
>> from third-party projects.
>
> Right, but it's hard to integrate against trunk when trunk itself may be
> broken. If we had a way of publishing "known good" commit hashes that passed
> the test suite on all the stable buildbots, that could potentially provide a
> basis for integration testing without needing to switch to merge gating
> first.

ISTM the most natural way to publish a "known good" commit hash is by
updating a branch head to point at the latest good version. In fact
this is pretty much the exact use case that motivated the invention of
DVCS back in the day :-). Unfortunately hg makes this a little
trickier than it could be, because in hg the same commit can't be in
two different branches; but this just means you have to insert some
no-op merges, oh well.

Interestingly, this is almost identical to merge gating (at least, if
I'm correctly guessing what you mean by that -- the "not rocket
science rule"?), just with different names for the branches :-).

-n

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

Re: [Python-Dev] Computed Goto dispatch for Python 2

[Nick Coghlan]

On 29 May 2015 11:01 am, "Victor Stinner"  wrote:
>
> Why not continue to enhance Python 3 instead of wasting our time with
> Python 2? We have limited resources in term of developers to maintain
> Python.
>
> (I'm not talking about fixing *bugs* in Python 2 which is fine with me.)

I'm actually OK with volunteers deciding that even fixing bugs in 2.7 isn't
inherently rewarding enough for them to be willing to do it for free on
their own time.

Stepping up to extrinsically reward activities that are beneficial for
customers but aren't intrinsically interesting enough for people to be
willing to do for free is one of the key reasons commercial open source
redistributors get paid.

That more explicitly commercial presence is a dynamic we haven't
historically had to deal with in core development, so there are going to be
some growing pains as we find an arrangement that everyone is comfortable
with (or is at least willing to tolerate, but I'm optimistic we can do
better than that).

Cheers,
Nick.

>
> --
>
> By the way, I just wrote sixer, a new tool to generate patches to port
> OpenStack to Python 3 :-)
> https://pypi.python.org/pypi/sixer
>
> It's based on regex, so it's less reliable than 2to3, 2to6 or
> modernize, but it's just enough for my specific use case. On
> OpenStack, it's not possible to send one giant patch "hello, this is
> python 3". Code is modified by small and incremental changes.
>
> Come on in the Python 3 world and... always look on the bright side of
> life ( https://www.youtube.com/watch?v=VOAtCOsNuVM )!
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Steven D'Aprano]

On Thu, May 28, 2015 at 05:38:49PM +0100, Paul Moore wrote:

> I suspect "single file executables" just aren't viewed as a desirable
> solution on Unix. 

More of an anti-pattern than a pattern. A single file executable means 
that when you have a security update, instead of patching one library, 
you have to patch all fifty applications that include that library.


> Although Donald referred to a 4K binary, which
> probably means just a stub exe that depends on system-installed .so
> files, likely including Python (I'm just guessing here). 

The machine I'm currently on has a 5.6K Python executable:

[steve@ando ~]$ ls -lh /usr/bin/python*
-rwxr-xr-x 2 root root 5.6K Jan  9  2013 /usr/bin/python
lrwxrwxrwx 1 root root6 Jan 22  2013 /usr/bin/python2 -> python
-rwxr-xr-x 2 root root 5.6K Jan  9  2013 /usr/bin/python2.4

but that doesn't include libpython:

[steve@ando ~]$ ls -lh /usr/lib/libpython2.4.so*
lrwxrwxrwx 1 root root   19 Jan 22  2013 /usr/lib/libpython2.4.so -> 
libpython2.4.so.1.0
-r-xr-xr-x 1 root root 1.1M Jan  9  2013 /usr/lib/libpython2.4.so.1.0

or the standard library.


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

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

[Nick Coghlan]

On 29 May 2015 9:48 am, "Donald Stufft"  wrote:
>
>
>
> On May 28, 2015 at 7:40:26 PM, Nick Coghlan (ncogh...@gmail.com) wrote:
> > >
> > > One thing I've seen more than once is that new development happens
> > in Python
> > > until the problem is understood, then the code is ported to Go.
> > Python's
> > > short path from idea to working code, along with its ability
> > to quickly morph
> > > as requirements and understanding changes, its batteries
> > included philosophy,
> > > and its "fits-your-brain" consistency are its biggest strengths!
> >
> >
> > Right, Go is displacing C/C++ in that regard (moreso than Python
> > itself), and now that Rust has hit 1.0, I expect we'll see it becoming
> > another contender for this task. Rust's big advantage over Go
> > in that regard is being compatible with the C/C++ ecosystem,
> > including Python's cffi.
> >
>
> I’m not sure if I’m reading this right or not, but just to be clear, I’ve
> seen a number of people express the sentiment that they are switching from
> Python to Go and that the deployment story is one of the reasons. It’s not
> just people switching from C/C++.

C and C++ used to be the main "second version" languages used to create
statically linked standalone binaries after an initial prototype in Python.

Folks that learned Python first understandably weren't keen on that idea,
so they tended  to either use Cython (or its predecessor, Pyrex), or else
not bother doing it at all until first Go and now Rust came along (for
reasons unknown to me, D appears to have never gained any popularity
outside the ACM crowd).

If I seem blase about Go, that's the main reason why - the benefits it
offers aren't novel from the point of view of C/C++ programmers, they're
just now available without having to put up with arcane syntax, manual
memory management, an unmaintainable threading model, relatively poor
support for text manipulation, etc, etc.

There's no shortage of software needing to be written, so powerful new
additions to our collective toolkit like Go are advancements to be
celebrated and learned from, rather than feared.

Cheers,
Nick.

>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com