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

[Xavier Combelle]

> +1. The new embeddable Python distribution for Windows is a great step
> forward for this. It's not single-file, but it's easy to produce a
> single-directory self-contained application with it. I don't know if
> there's anything equivalent for Linux/OSX - maybe it's something we
> should look at for them as well (although the whole "static binaries"
> concept seems to be fairly frowned on in the Unix world, from what
> I've seen).
>
> Just curious What is "the new embeddable Python distribution for Windows" ?
___
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

[Paul Moore]

On 31 May 2015 at 10:14, Xavier Combelle  wrote:
>> +1. The new embeddable Python distribution for Windows is a great step
>> forward for this. It's not single-file, but it's easy to produce a
>> single-directory self-contained application with it. I don't know if
>> there's anything equivalent for Linux/OSX - maybe it's something we
>> should look at for them as well (although the whole "static binaries"
>> concept seems to be fairly frowned on in the Unix world, from what
>> I've seen).
>>
> Just curious What is "the new embeddable Python distribution for Windows" ?

Python 3.5 ships a zipfile which contains a self-contained Python
installation, intended for embedding. The idea is that you unzip it
into your application directory, and use it from within your
application (either via the embedding API, or using the included
python.exe/pythonw.exe). It doesn't use the registry, or any global
resources, so it's independent of any installed python that might be
present.

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] Computed Goto dispatch for Python 2

[Paul Moore]

On 31 May 2015 at 11:41, Paul Moore  wrote:
> On 31 May 2015 at 10:14, Xavier Combelle  wrote:
>>> +1. The new embeddable Python distribution for Windows is a great step
>>> forward for this. It's not single-file, but it's easy to produce a
>>> single-directory self-contained application with it. I don't know if
>>> there's anything equivalent for Linux/OSX - maybe it's something we
>>> should look at for them as well (although the whole "static binaries"
>>> concept seems to be fairly frowned on in the Unix world, from what
>>> I've seen).
>>>
>> Just curious What is "the new embeddable Python distribution for Windows" ?
>
> Python 3.5 ships a zipfile which contains a self-contained Python
> installation, intended for embedding. The idea is that you unzip it
> into your application directory, and use it from within your
> application (either via the embedding API, or using the included
> python.exe/pythonw.exe). It doesn't use the registry, or any global
> resources, so it's independent of any installed python that might be
> present.

By the way, IMO the new embeddable distribution is a pretty big deal
on Windows. To make sure that it doesn't end up unnoticed, can I
suggest we include a prominent "What's New" entry for it, and a
section in "Python Setup and Usage" under "Using Python on Windows"
for it?

I'd hate to find that 3 or 4 versions from now, we're still trying to
remind people that they can use the embeddable distribution, in the
same way that executable zipfiles ended up an almost unknown feature
for ages.

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] Computed Goto dispatch for Python 2

[Alexander Walters]

A better course of action would be to deprecate the non-portable 
version.  Other than setting the PATH envvar, why do we need to continue 
even touching the system on install?  It is highly annoying for those of 
us that maintain several installs of python on a single windows system, 
and it really should stop.


The only use I can think of for ever touching the registry in the first 
place is to tell distutils installers where python is.  I can tell you 
right now, that design choice is a bug.  There are some mighty hacks you 
have to go through to correct that behavior when you happen to be using 
a virtualenv.


(We are calling it 'embedable', but the rest of the world would call it 
'portable', as in, runable from a usb stick)


On 5/31/2015 06:47, Paul Moore wrote:

On 31 May 2015 at 11:41, Paul Moore  wrote:

On 31 May 2015 at 10:14, Xavier Combelle  wrote:

+1. The new embeddable Python distribution for Windows is a great step
forward for this. It's not single-file, but it's easy to produce a
single-directory self-contained application with it. I don't know if
there's anything equivalent for Linux/OSX - maybe it's something we
should look at for them as well (although the whole "static binaries"
concept seems to be fairly frowned on in the Unix world, from what
I've seen).


Just curious What is "the new embeddable Python distribution for Windows" ?

Python 3.5 ships a zipfile which contains a self-contained Python
installation, intended for embedding. The idea is that you unzip it
into your application directory, and use it from within your
application (either via the embedding API, or using the included
python.exe/pythonw.exe). It doesn't use the registry, or any global
resources, so it's independent of any installed python that might be
present.

By the way, IMO the new embeddable distribution is a pretty big deal
on Windows. To make sure that it doesn't end up unnoticed, can I
suggest we include a prominent "What's New" entry for it, and a
section in "Python Setup and Usage" under "Using Python on Windows"
for it?

I'd hate to find that 3 or 4 versions from now, we're still trying to
remind people that they can use the embeddable distribution, in the
same way that executable zipfiles ended up an almost unknown feature
for ages.

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

[Ludovic Gasc]

2015-05-31 0:26 GMT+02:00 Nick Coghlan :

>
> On 31 May 2015 04:20, "Ludovic Gasc"  wrote:
> >
> > For now, I'm following the mailing-lists from a spy-glass: I don't read
> most of the e-mails.
> > However, this thread seems to be "infected": I can smell from here your
> emotions behind your words.
> >
> > Why to push a lot of emotions inside a technical discussion ?
> > What's the nerves have been hit with this discussion ?
>
> I think you answered your own question fairly well
>
Thanks.

> - there's a longstanding, but rarely articulated, culture clash between
> the folks that are primarily interested in the innovators and early
> adopters side of things, and those of us that are most interested in
> bridging the gap to the early majority, late majority and laggards.
>
> Add in the perfectly reasonable wariness a lot of folks have regarding the
> potential for commercial interests to unfairly exploit open source
> contributors without an adequate return contribution of development effort,
> gratis software, gratis services,
>
Based on my professional experience, more a client pays for your skills,
more you have chance that he will respect you, because he knows your value.
The contrary is, that, less a client pays, more he will try to manipulate
you to do more things that it was planned in the contract.

Now, for an open source software, you don't have money cost, but, you still
have the knowledge cost.
If you replace money by knowledge in my two previous sentences, theses
sentences are also true.

However, things aren't binary: Apart the contribution level [1] of each
member, the "good" and "bad" ideas for the future of Python can arrive from
everybody.
The only thing I'm sure: I'm incompetent to predict the future, I've no
idea how each member of our community will react, I can list only some
possible scenarios.
But with Internet, you know as me that with only few persons you can change
a lot of things, look Edward Snowden for example.

About Python 3 migration, I think that one of our best control stick is
newcomers, and by extension, Python trainers/teachers.
If newcomers learn first Python 3, when they will start to work
professionally, they should help to rationalize the Python 3 migration
inside existing dev teams, especially because they don't have an interest
conflict based on the fact that they haven't written plenty of code with
Python 2.
2020 is around the corner, 5 years shouldn't be enough to change the
community mind, I don't know.

[1] Don't forget that contributions aren't only the source code ;-)

> or interesting employment opportunities, and you're going to see the
> occasional flare-ups as we find those rough edges where differences in
> motivation & background lead to differences of opinion & behaviour.
>
> 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] Obtaining stack-frames from co-routine objects

[Ben Leslie]

Hi Yury,

I'm just starting my exploration into using async/await; all my
'real-world' scenarios are currently hypothetical.

One such hypothetical scenario however is that if I have a server
process running, with some set of concurrent connections, each managed
by a co-routine. Each co-routine is of some arbitrary complexity e.g:
some combination of reading files, reading from database, reading from
peripherals. If I notice one of those co-routines appears stuck and
not making progress, I'd very much like to debug that, and preferably
in a way that doesn't necessarily stop the rest of the server (or even
the co-routine that appears stuck).

The problem with the "if debug: log(...)" approach is that you need
foreknowledge of the fault state occurring; on a busy server you don't
want to just be logging every 'switch()'. I guess you could do
something like "switch_state[outer_coro] = get_current_stack_frames()"
on each switch. To me double book-keeping something that the
interpreter already knows seems somewhat wasteful but maybe it isn't
really too bad.

Cheers,

Ben

On 29 May 2015 at 23:57, Yury Selivanov  wrote:
> 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/benno%40benno.id.au
___
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] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

[Nick Coghlan]

On 31 May 2015 at 19:07, Ludovic Gasc  wrote:
> About Python 3 migration, I think that one of our best control stick is
> newcomers, and by extension, Python trainers/teachers.
> If newcomers learn first Python 3, when they will start to work
> professionally, they should help to rationalize the Python 3 migration
> inside existing dev teams, especially because they don't have an interest
> conflict based on the fact that they haven't written plenty of code with
> Python 2.
> 2020 is around the corner, 5 years shouldn't be enough to change the
> community mind, I don't know.

The education community started switching a while back - if you watch
Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for
the broader Python community was for everyone else to just catch up
already in order to reduce student's confusion (she phrased it more
politely than that, though). Educators need to tweak examples and
exercises to account for a version switch, but that's substantially
easier than migrating hundreds of thousands or even millions of lines
of production code.

And yes, if you learn Python 3 first, subsequently encountering Python
2's quirks and cruft is likely to encourage folks that know both
versions of the language to start advocating for a version upgrade :)

After accounting for the "Wow, the existing Python 2 install base is
even larger than we realised" factour, the migration is actually in a
pretty good place overall these days. The "enterprise" crowd really
are likely to be the only ones that might need the full remaining 5
years of migration time (and they may potentially have even more time,
if they're relying on a commercial redistributor).

Web frameworks have allowed Python 3 development for a while now, and
with Django switching their tutorial to Python 3 by default, Django
downloads via pip show one of the highest proportions of Python 3
adoption on PyPI. www.python.org itself is now a production Python 3
Django web service, and the next generation of pypi.python.org will be
a Pyramid application that's also running on Python 3.

The dedicated async/await syntax in 3.5 represents a decent carrot to
encourage migration for anyone currently using yield (or yield from)
based coroutines, since the distinct syntax not only allows for easier
local reasoning about whether something is an iterator or a coroutine,
it also provides a much improved user experience for asynchronous
iterators and context managers (including finally handling the
"asynchronous database transaction as a context manager" case, which
previous versions of Python couldn't really do at all).

The matrix multiplication operator is similarly a major improvement
for the science and data analysis part of the Python community.

In terms of reducing *barriers* to adoption, after inviting them to
speak at the 2014 language summit, we spent a fair bit of time with
the Twisted and Mercurial folks over the past year or so working
through "What's still missing from Python 3 for your use cases?", as
Python 3.4 was still missing some features for binary data
manipulation where we'd been a bit too ruthless in pruning back the
binary side of things when deciding what counted as text-only
features, and what was applicable to binary data as well. So 3.5
brings back binary interpolation, adds a hex() method to bytes, and
adds binary data support directly to a couple of standard library
modules (tempfile, difflib).

If I understand the situation correctly, the work Guido et al have
been doing on PEP 484 and type hinting standardisation is also aimed
at reducing barriers to Python 3 adoption, by making it possible to
develop better migration tools that are more semantically aware than
the existing syntax focused tools. The type hinting actually acts as a
carrot as well, since it's a feature that mainly shows its value when
attempting to scale a *team* to larger sizes (as it lets you delegate
more of the code review process to an automated tool, letting the
human reviewers spend more time focusing on higher level semantic
concerns).

Finally, both Debian/Ubuntu and Fedora are well advanced in their
efforts to replace Python 2 with Python 3 in their respective default
images (but keeping Py2 available in their package repos). That work
is close to finished now (myself, Slavek Kabrda, Barry Warsaw, and
Matthias Klose had some good opportunities to discuss that at PyCon),
although there are still some significant rough edges to figure out
(such as coming up with a coherent cross-platform story for what we're
going to do with the Python symlink), as well as a few more key
projects to either migrate entirely, or at least finish porting to the
source compatible subset of Python 2 & 3 (e.g. Samba).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mai

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

[Terry Reedy]

On 5/31/2015 6:59 AM, Alexander Walters wrote:

A better course of action would be to deprecate the non-portable
version.  Other than setting the PATH envvar, why do we need to continue
even touching the system on install?  It is highly annoying for those of
us that maintain several installs of python on a single windows system,
and it really should stop.


Some people want the right-click context menu entries -- Run (also 
double click) and Edit with Idle, which should be Edit with Idle x.y.



The only use I can think of for ever touching the registry in the first
place is to tell distutils installers where python is.  I can tell you
right now, that design choice is a bug.  There are some mighty hacks you
have to go through to correct that behavior when you happen to be using
a virtualenv.

(We are calling it 'embedable', but the rest of the world would call it
'portable', as in, runable from a usb stick)


--
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] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

[Florian Bruhin]

* Nick Coghlan  [2015-06-01 00:15:01 +1000]:
> On 31 May 2015 at 19:07, Ludovic Gasc  wrote:
> > About Python 3 migration, I think that one of our best control stick is
> > newcomers, and by extension, Python trainers/teachers.
> > If newcomers learn first Python 3, when they will start to work
> > professionally, they should help to rationalize the Python 3 migration
> > inside existing dev teams, especially because they don't have an interest
> > conflict based on the fact that they haven't written plenty of code with
> > Python 2.
> > 2020 is around the corner, 5 years shouldn't be enough to change the
> > community mind, I don't know.
> 
> The education community started switching a while back - if you watch
> Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for
> the broader Python community was for everyone else to just catch up
> already in order to reduce student's confusion (she phrased it more
> politely than that, though). Educators need to tweak examples and
> exercises to account for a version switch, but that's substantially
> easier than migrating hundreds of thousands or even millions of lines
> of production code.
> 
> And yes, if you learn Python 3 first, subsequently encountering Python
> 2's quirks and cruft is likely to encourage folks that know both
> versions of the language to start advocating for a version upgrade :)

I think a big issue here is the lack of good newcomer tutorials for
Python 3.

In the #python IRC channel, "learn Python the hard way"[1] is often
recommended, and the common consensus seems to be that all other
tutorials (other than the official one[2] which is clearly not aimed
at newcomers to programming) seem to lack in some way.

LPTHW is Python 2 only, so at least from what I see in #python, many
newcomers are recommended to learn Python 2 rather than 3 because of
that.

I agree migrating large existing codebases (and developers) from 2 to
3 can be quite an issue, and a lot of energy went into making this
easier (which is good!). But I also think nobody fresh to Python
should start learning Python 2 now, except when there's a compelling
reason (such as unported libraries without alternatives).

Florian

[1] http://learnpythonthehardway.org/book/
[2] https://docs.python.org/3/tutorial/index.html

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgpeWqOOlFXHd.pgp
Description: PGP signature
___
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] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

[Terry Reedy]

On 5/31/2015 10:15 AM, Nick Coghlan wrote:


The education community started switching a while back - if you watch
Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for
the broader Python community was for everyone else to just catch up
already in order to reduce student's confusion (she phrased it more
politely than that, though). Educators need to tweak examples and
exercises to account for a version switch, but that's substantially
easier than migrating hundreds of thousands or even millions of lines
of production code.


There is another somewhat invisible but real aspect of migration that 
tends to get ignored: the Python embedded in applications.  LibreOffice 
4.0, for instance, upgraded from 2.6 to 3.3 (around Jan 14 I think). It 
is currently in lo4dir/program/python-core-3.3.1.  I presume unicode 
everywhere pluse the new-in-3.3 efficient, cross-platform unicode 
implementation had something to do with this.  lo4dir/program/wizards is 
a package with subpackages and over 100 .py files.  There are now 
perhaps 20 million LO4 users (and indirect 3.3 users) around the world 
(my guess from Wikipedia article). A few will use the PyUNO bridge for 
scripting.  Installations are from CDs, direct downloads, torrents, and 
linux distributions, but not from pypi.  In a few years, the number 
might grow to 100 million as more LO3 users upgrade and new users start 
with LO4.


[...]


In terms of reducing *barriers* to adoption, after inviting them to
speak at the 2014 language summit, we spent a fair bit of time with
the Twisted and Mercurial folks over the past year or so working
through "What's still missing from Python 3 for your use cases?", as
Python 3.4 was still missing some features for binary data
manipulation where we'd been a bit too ruthless in pruning back the
binary side of things when deciding what counted as text-only
features, and what was applicable to binary data as well. So 3.5
brings back binary interpolation, adds a hex() method to bytes, and
adds binary data support directly to a couple of standard library
modules (tempfile, difflib).


Perhaps we should investigate whether other apps with embedded but user 
accessible python has migrated and if not, ask why not (dependencies?) 
and whether planned.


--
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] Computed Goto dispatch for Python 2

[Nick Coghlan]

On 1 June 2015 at 00:44, Terry Reedy  wrote:
> On 5/31/2015 6:59 AM, Alexander Walters wrote:
>>
>> A better course of action would be to deprecate the non-portable
>> version.  Other than setting the PATH envvar, why do we need to continue
>> even touching the system on install?  It is highly annoying for those of
>> us that maintain several installs of python on a single windows system,
>> and it really should stop.
>
>
> Some people want the right-click context menu entries -- Run (also double
> click) and Edit with Idle, which should be Edit with Idle x.y.

And system administrators responsible for deploying and maintaining
Standard Operating Environments want the MSI integration. In that
regard, the default behaviour of the python.org installers is the
rough equivalent of the system Python on Linux distributions (with the
added complexity of needing to deal with the Windows registry).

Portable installations are often good for developers, but they come at
the cost of failing to integrate properly with the underlying
operating system.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

[Stephen J. Turnbull]

Florian Bruhin writes:

 > I think a big issue here is the lack of good newcomer tutorials for
 > Python 3.

My business students (who are hardly advanced programmers) don't take
tutorials seriously.  They're way too focused on getting results.  And
there it's the "Doing  with Python" books that
are the killer.  They just cargo cult those books, which are almost
all still Python-2-focused in my experience.

I don't think there's much we can do about those books except hope
they're popular enough to justify new editions in short order, but I
did want to point out that tutorials are not the only way beginners
are introduced to Python, and a lot of those entry ports remain
Python-2-oriented.

What I would really like to see is a Python 3 (and if you really need
Python 2, here's how it differs) version of Python: Essential
Reference.

BTW, for my students the main thing that trips them is not Unicode,
but rather things like the print function (vs. statement in Python 2).

 > But I also think nobody fresh to Python should start learning
 > Python 2 now, except when there's a compelling reason (such as
 > unported libraries without alternatives).

I agree, but the cargo cult thing is big for people coming to Python
because somebody told them it's a good way to do something practical.
(Fortunately my students have to deal with the insane proliferation of
encodings in Japan, so "less mojibake" is a compelling reason for
Python 3.  I get no backtalk.)
___
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

[Steve Dower]

"We are calling it 'embedable', but the rest of the world would call it
'portable', as in, runable from a usb stick"

I called it embeddable because it's not intended for direct use and is not 
complete. There's no test suite, no documentation, no tkinter (pending high 
demand), no pip, no site-packages, and no folder structure. It really is meant 
to be a component in another application that provides the rest of the layout 
for its own needs. (I probably ought to blog about it so there's at least one 
detailed example of what it's for...)

A nice side-effect is that you can make a regular per-user install portable by 
adding a pyvenv.cfg with "applocal = True", which disables regular path 
resolution (and also ignores PYTHONPATH, which is a feature or a bug, depending 
on your point of view). This only works on Windows right now, but could 
probably be ported from getpathp.c into getpath.c easily.

Cheers,
Steve

Top-posted from my Windows Phone

From: Alexander Walters
Sent: ‎5/‎31/‎2015 6:39
To: python-dev@python.org
Subject: Re: [Python-Dev] Computed Goto dispatch for Python 2

A better course of action would be to deprecate the non-portable
version.  Other than setting the PATH envvar, why do we need to continue
even touching the system on install?  It is highly annoying for those of
us that maintain several installs of python on a single windows system,
and it really should stop.

The only use I can think of for ever touching the registry in the first
place is to tell distutils installers where python is.  I can tell you
right now, that design choice is a bug.  There are some mighty hacks you
have to go through to correct that behavior when you happen to be using
a virtualenv.

(We are calling it 'embedable', but the rest of the world would call it
'portable', as in, runable from a usb stick)

On 5/31/2015 06:47, Paul Moore wrote:
> On 31 May 2015 at 11:41, Paul Moore  wrote:
>> On 31 May 2015 at 10:14, Xavier Combelle  wrote:
 +1. The new embeddable Python distribution for Windows is a great step
 forward for this. It's not single-file, but it's easy to produce a
 single-directory self-contained application with it. I don't know if
 there's anything equivalent for Linux/OSX - maybe it's something we
 should look at for them as well (although the whole "static binaries"
 concept seems to be fairly frowned on in the Unix world, from what
 I've seen).

>>> Just curious What is "the new embeddable Python distribution for Windows" ?
>> Python 3.5 ships a zipfile which contains a self-contained Python
>> installation, intended for embedding. The idea is that you unzip it
>> into your application directory, and use it from within your
>> application (either via the embedding API, or using the included
>> python.exe/pythonw.exe). It doesn't use the registry, or any global
>> resources, so it's independent of any installed python that might be
>> present.
> By the way, IMO the new embeddable distribution is a pretty big deal
> on Windows. To make sure that it doesn't end up unnoticed, can I
> suggest we include a prominent "What's New" entry for it, and a
> section in "Python Setup and Usage" under "Using Python on Windows"
> for it?
>
> I'd hate to find that 3 or 4 versions from now, we're still trying to
> remind people that they can use the embeddable distribution, in the
> same way that executable zipfiles ended up an almost unknown feature
> for ages.
>
> 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/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/steve.dower%40microsoft.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] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

[Carol Willing]

On 5/31/15 8:39 AM, Stephen J. Turnbull wrote:

What I would really like to see is a Python 3 (and if you really need
Python 2, here's how it differs) version of Python: Essential
Reference.
Agreed.  If anyone has Python 3 books, talks, or resources that they 
find helpful and of high quality, please send me an email and I will 
happily curate a cheatsheet, document, or website with the results. For 
example, Harry Percival's TDD book and tutorials on PyVideo.org are well 
done with a Python 3 focus.


If you have other favorite Python 2 books that you wish were 
revised/rewritten to have a Python 3 focus, please email me that as well.

I agree, but the cargo cult thing is big for people coming to Python
because somebody told them it's a good way to do something practical.
For our user group attendees (whether novice or experienced, teens or 
post-docs), "practical and simple" trumps "shiny and complex". Search 
gives them a mountain of resources. Yet, these users are looking for 
guidance on a reasonable approach to do the practical things that 
interest them. These creators, innovators, and experimenters care less 
about programming language or version than they do about building their 
ideas. Fortunately, the Python language, especially when combined with 
the Python community and its outreach, enables building these 
ideas...when we are not tripping all over our own perspectives of which 
version "should" suit the use case. Practically, use whichever version 
is best suited to the use case.


Warmly,
Carol

P.S. Whether you develop for version 2, version 3, or both, thank you 
for doing so :-)

--
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.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] Can someone configure the buildbots to build the 3.5 branch?

[Larry Hastings]

On 05/30/2015 08:25 PM, Zachary Ware wrote:

On Thu, May 28, 2015 at 6:59 PM, Larry Hastings  wrote:

The buildbots currently live in a state of denial about the 3.5 branch.
Could someone whisper tenderly in their collective shell-like ears so that
they start building 3.5, in addition to 3.4 and trunk?

The 3.5 branch seems to be set up on the buildbots, we'll see how it
goes when somebody commits something to 3.5.


It looks like they're working--thanks!


//arry/
___
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] [RELEASED] Python 3.5.0b2 is now available

[Larry Hastings]

On behalf of the Python development community and the Python 3.5 release 
team, I'm relieved to announce the availability of Python 3.5.0b2.  
Python 3.5.0b1 had a major regression (see 
http://bugs.python.org/issue24285 for more information) and as such was 
not suitable for testing Python 3.5. Therefore we've made this extra 
beta release, only a week later.  Anyone trying Python 3.5.0b1 should 
switch immediately to testing with Python 3.5.0b2.


Python 3.5 has now entered "feature freeze".  By default new features 
may no longer be added to Python 3.5.  (However, there are a handful of 
features that weren't quite ready for Python 3.5.0 beta 2; these were 
granted exceptions to the freeze, and are scheduled to be added before 
beta 3.)


This is a preview release, and its use is not recommended for production 
settings.


Three important notes for Windows users about Python 3.5.0b2:

 * If installing Python 3.5.0b2 as a non-privileged user, you may need
   to escalate to administrator privileges to install an update to your
   C runtime libraries.
 * There is now a third type of Windows build for Python 3.5.  In
   addition to the conventional installer and the web-based installer,
   Python 3.5 now has an embeddable release designed to be deployed as
   part of a larger application's installer for apps using or extending
   Python.  During the 3.5 alpha releases, this was an executable
   installer; as of 3.5.0 beta 1 the embeddable build of Python is now
   shipped in a zip file.


You can find Python 3.5.0b2 here:

   https://www.python.org/downloads/release/python-350b2/

Happy hacking,


//arry/
___
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