Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 23/03/2015 01:46, Glenn Linderman wrote:
> On 3/22/2015 8:12 AM, Tim Golden wrote:
>> I'll create a £££ user (which is the easiest non-ASCII name to create
>> on a UK keyboard) to see how cleanly the latest installer works. 
> 
> You can also copy/paste.  A path with a Cyrillic, Greek, Chinese,
> Tibetan, Japanese, Armenian, and Romanian character, none of which are
> in the "Windows ANSI" character set, should suffice...  Here ya go...
> 
> ț硕բ文བོདΘ
> 
> In my work with Windows, I've certainly seen that £ is much more
> acceptable to more programs than ț or these other ones.
> 

Thanks, Glenn. Good point.

TJG
___
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] Use ptyhon -s as default shbang for system python executables/daemons

[Toshio Kuratomi]

-Toshio
On Mar 19, 2015 3:27 PM, "Victor Stinner"  wrote:
>
> 2015-03-19 21:47 GMT+01:00 Toshio Kuratomi :
> > I think I've found the Debian discussion (October 2012):
> >
> > http://comments.gmane.org/gmane.linux.debian.devel.python/8188
> >
> > Lack of PYTHONWARNINGS was brought up late in the discussion thread
>
> Maybe we need to modify -E or add a new option to only ignore PYTHONPATH.
>
I think pythonpath is still useful on its own.

Building off Nick's idea of a system python vs a python for users to use, I
would see a more useful modification to be able to specify SPYTHONPATH (and
other env vars) to go along with /usr/bin/spython .  That way the user
maintains the capability to override specific libraries globally just like
with LD_LIBRARY_PATH, PATH, and similar but you won't accidentally
configure your own python to use one set of paths for your five python apps
and then have that leak over and affect system tools.

-Toshio
___
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] Use ptyhon -s as default shbang for system python executables/daemons

[Antoine Pitrou]

On Mon, 23 Mar 2015 07:22:56 -0700
Toshio Kuratomi  wrote:
> 
> Building off Nick's idea of a system python vs a python for users to use, I
> would see a more useful modification to be able to specify SPYTHONPATH (and
> other env vars) to go along with /usr/bin/spython .  That way the user
> maintains the capability to override specific libraries globally just like
> with LD_LIBRARY_PATH, PATH, and similar but you won't accidentally
> configure your own python to use one set of paths for your five python apps
> and then have that leak over and affect system tools.

I really think Donald has a good point when he suggests a specific
virtualenv for system programs using Python.

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] super() does not work during class initialization

[Martin Teichmann]

> For folks that haven't looked at the tracker issue: I personally like
> the change, but it does involve storing the cell object in a
> dunder-variable in the class namespace while it's being defined (until
> type.__new__ executes and both populates it and removes it from the
> class namespace).

I think I had the same weird feelings like you when writing the code. It feels
a bit dodgy to abuse the class namespace to transport information from the
compiler to type.__new__. Only when I saw that __qualname__ already does
it, I decided it was probably not such a bad idea. The current implementation,
setting the __class__ cell at the end of __build_class__ doesn't feel dodgy to
me, it simply feels wrong. Nothing of real importance should happen there, as
it is just an implementation detail.

If we are fearing that we clutter namespace too much, we might call the
entries @qualname and @cell, then we are sure they will never mask
a user's class member.

Most of my bad feelings actually only come from the fact that we don't know
what we actually put our entries into, as __prepare__ might return something
weird that doesn't do what we expect. Given Eric Snow's comment that
class namespaces will be ordered by default soon anyways, we might deprecate
__prepare__ altogether, eliminating most of the bad feelings.

Speaking of which, instead of having OrderedDict re-implemented in C, maybe
we could just change the compiler to leave the order in which things are defined
in a class in the class namespace, say as a member __order__? Then we could
use plain-old dicts for the class namespace, and we would not slow down class
creation (not that it matters much), as determining the order would happen at
compile time.

> Since it introduces new behaviour that's visible to Python level code,
> I've suggested that Martin roll the suggestion into his current PEP
> 487 (which adds __init_subclass__ to similarly tidy up a few
> challenges with the way classes are currently initialised).

I thought about that, but while I stumbled over this issue while working
on PEP 487, it is actually unrelated. I didn't want people to think that
this change is needed to implement PEP 487. And while
"and now for something completely different" might be a nice
Monty Python reference, it is mostly frowned upon in PEPs as per PEP 1.

Alternatively, I could write a new PEP. But I actually think that
the change is not worth a PEP, because the changes will move
the CPython implementation actually closer to what is documented,
so I feel it is more a bugfix than an extension.

I have no problem to pursue any of the above paths,
how do other people feel about it?

Greetings

Martin
___
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] Use ptyhon -s as default shbang for system python executables/daemons

[Toshio Kuratomi]

On Mon, Mar 23, 2015 at 03:30:23PM +0100, Antoine Pitrou wrote:
> On Mon, 23 Mar 2015 07:22:56 -0700
> Toshio Kuratomi  wrote:
> > 
> > Building off Nick's idea of a system python vs a python for users to use, I
> > would see a more useful modification to be able to specify SPYTHONPATH (and
> > other env vars) to go along with /usr/bin/spython .  That way the user
> > maintains the capability to override specific libraries globally just like
> > with LD_LIBRARY_PATH, PATH, and similar but you won't accidentally
> > configure your own python to use one set of paths for your five python apps
> > and then have that leak over and affect system tools.
> 
> I really think Donald has a good point when he suggests a specific
> virtualenv for system programs using Python.
> 
The isolation is what we're seeking but I think the amount of work required
and the added complexity for the distributions will make that hard to get
distributions to sign up for.

If someone had the time to write a front end to install packages into
a single "system-wide isolation unit" whose backend was a virtualenv we
might be able to get distributions on-board with using that.

The front end would need to install software so that you can still invoke
/usr/bin/system-application and "system-application" would take care of
activating the virtualenv.  It would need to be about as simple to build
as the present python2 setup.py build/install with the flexibility in
options that the distros need to install into FHS approved paths.  Some
things like man pages, locale files, config files, and possibly other data
files might need to be installed outside of the virtualenv directory.  Many
setup.py's already punt on some of those, though, letting the user choose
to install them manually.  So this might be similar.  It would need to be able
to handle 32bit and 64bit versions of the same library installed on the same
system.  It would need to be able to handle different versions of the same
library installed on the same system (as few of those as possible but it's
an unfortunate cornercase that can't be entirely ignored even for just
system packages).  It would need a mode where it doesn't use the network at
all; only operates with the packages and sources that are present on the
box.

And remember these two things: (1) we'd be asking the distros to do
a tremendous amount of work changing their packages to install into
a virtualenv instead of the python setup.py way that is well documented and
everyone's been using for ages.  it'll be a tough sell even with good
tooling.  (2) this theoretical front-end would have to appeal to the distro
maintainers so there would have to be a lot of talk to understand what
capabilities the distro maintainers would need from it.

-Toshio


pgp1JMWtlRGec.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] Use ptyhon -s as default shbang for system python executables/daemons

[Antoine Pitrou]

On Mon, 23 Mar 2015 08:06:13 -0700
Toshio Kuratomi  wrote:
> > 
> > I really think Donald has a good point when he suggests a specific
> > virtualenv for system programs using Python.
> > 
> The isolation is what we're seeking but I think the amount of work required
> and the added complexity for the distributions will make that hard to get
> distributions to sign up for.
> 
> If someone had the time to write a front end to install packages into
> a single "system-wide isolation unit" whose backend was a virtualenv we
> might be able to get distributions on-board with using that.

I don't think we're asking distributions anything. We're suggesting a
possible path, but it's not python-dev's job to dictate distributions
how they should package Python.

The virtualenv solution has the virtue that any improvement we might
put in it to help system packagers would automatically benefit everyone.
A specific "system Python" would not.

> The front end would need to install software so that you can still invoke
> /usr/bin/system-application and "system-application" would take care of
> activating the virtualenv.  It would need to be about as simple to build
> as the present python2 setup.py build/install with the flexibility in
> options that the distros need to install into FHS approved paths.  Some
> things like man pages, locale files, config files, and possibly other data
> files might need to be installed outside of the virtualenv directory.

Well, I don't understand what difference a virtualenv would make.
Using a virtualenv amounts to invoking a different interpreter path.
The rest of the filesystem (man pages locations, etc.) is still
accessible in the same way. But I may miss something :-)

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

[Python-Dev] --with-valgrind and --enable-shared

[Andrea Griffini]

Hello,

does it have any sense for a linux distribution (arch to be specific) to
provide default Python package compiled with valgrind support? I thought
this flag was just about silencing false positives generated by valgrind
(in other words a workaround for "bugs" of another software) and useful
only when developing Python itself or C extensions.

The same distribution also compiles by default to a shared library and this
has a quite noticeable impact on performance on x64 (surprisingly for me)
for CPU bound processing; in a few test cases I measured valgrind+shared
Python running at 66% the speed of plain ./configure && make Python on my
system. Is this setting reasonable for general users?

If they are good defaults, why aren't them the default?

Andrea Griffini
___
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] --with-valgrind and --enable-shared

[Brett Cannon]

On Mon, Mar 23, 2015 at 1:59 PM Andrea Griffini  wrote:

> Hello,
>
> does it have any sense for a linux distribution (arch to be specific) to
> provide default Python package compiled with valgrind support? I thought
> this flag was just about silencing false positives generated by valgrind
> (in other words a workaround for "bugs" of another software) and useful
> only when developing Python itself or C extensions.
>

It's not really our place to say if it makes sense for Arch to compile with
valgrind flags turned on. It really depends on how they use Python in their
Linux distribution and what their own goals are.


>
> The same distribution also compiles by default to a shared library and
> this has a quite noticeable impact on performance on x64 (surprisingly for
> me) for CPU bound processing; in a few test cases I measured
> valgrind+shared Python running at 66% the speed of plain ./configure &&
> make Python on my system. Is this setting reasonable for general users?
>

Once again, it all depends on how Arch uses Python.


>
> If they are good defaults, why aren't them the default?
>

That's a question for Arch Linux and not us.
___
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] --with-valgrind and --enable-shared

[Andrea Griffini]

On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon  wrote:
>
>
>
> It's not really our place to say if it makes sense for Arch to compile
> with valgrind flags turned on. It really depends on how they use Python in
> their Linux distribution and what their own goals are.
>

I already asked the package maintainers about this, I just wanted to know
if my understanding about what --with-valgrind means is correct or if there
are good reason to turn it on (except debugging Python).


>
>
>>
>> If they are good defaults, why aren't them the default?
>>
>
> That's a question for Arch Linux and not us.
>

I probably didn't explain myself correctly: I was asking why they're not
the default values for Python configure script...

Andrea
___
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] --with-valgrind and --enable-shared

[Antoine Pitrou]

On Mon, 23 Mar 2015 19:16:17 +0100
Andrea Griffini  wrote:
> On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon  wrote:
> >
> > It's not really our place to say if it makes sense for Arch to compile
> > with valgrind flags turned on. It really depends on how they use Python in
> > their Linux distribution and what their own goals are.
> >
> 
> I already asked the package maintainers about this, I just wanted to know
> if my understanding about what --with-valgrind means is correct or if there
> are good reason to turn it on (except debugging Python).

I think your understanding is correct. It's the first time I hear of
Python being compiled --with-valgrind in a Linux distribution.

As for --enable-shared, it's more of a distro policy and isn't unheard
of. The RedHat world (Mageia, etc.) enables it as well. Perhaps it
makes updates easier if there are many installed programs embedding the
Python interpreter.

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] Use ptyhon -s as default shbang for system python executables/daemons

[Nathaniel Smith]

On Mar 23, 2015 8:15 AM, "Antoine Pitrou"  wrote:
>
> On Mon, 23 Mar 2015 08:06:13 -0700
> Toshio Kuratomi  wrote:
> > >
> > > I really think Donald has a good point when he suggests a specific
> > > virtualenv for system programs using Python.
> > >
> > The isolation is what we're seeking but I think the amount of work
required
> > and the added complexity for the distributions will make that hard to
get
> > distributions to sign up for.
> >
> > If someone had the time to write a front end to install packages into
> > a single "system-wide isolation unit" whose backend was a virtualenv we
> > might be able to get distributions on-board with using that.
>
> I don't think we're asking distributions anything. We're suggesting a
> possible path, but it's not python-dev's job to dictate distributions
> how they should package Python.
>
> The virtualenv solution has the virtue that any improvement we might
> put in it to help system packagers would automatically benefit everyone.
> A specific "system Python" would not.
>
> > The front end would need to install software so that you can still
invoke
> > /usr/bin/system-application and "system-application" would take care of
> > activating the virtualenv.  It would need to be about as simple to build
> > as the present python2 setup.py build/install with the flexibility in
> > options that the distros need to install into FHS approved paths.  Some
> > things like man pages, locale files, config files, and possibly other
data
> > files might need to be installed outside of the virtualenv directory.
>
> Well, I don't understand what difference a virtualenv would make.
> Using a virtualenv amounts to invoking a different interpreter path.
> The rest of the filesystem (man pages locations, etc.) is still
> accessible in the same way. But I may miss something :-)

The main issue that jumps to my mind is that 'yum/apt-get install
some-python-package' should install it into both the base python
interpreter and the system virtualenv, but that 'sudo pip install
some-python-package' should install into only the base interpreter but not
the system virtualenv. (Even if those two commands are run in sequence with
different versions of some-python-package.) This seems potentially complex.

-n
___
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] Use ptyhon -s as default shbang for system python executables/daemons

[Toshio Kuratomi]

On Mon, Mar 23, 2015 at 04:14:52PM +0100, Antoine Pitrou wrote:
> On Mon, 23 Mar 2015 08:06:13 -0700
> Toshio Kuratomi  wrote:
> > > 
> > > I really think Donald has a good point when he suggests a specific
> > > virtualenv for system programs using Python.
> > > 
> > The isolation is what we're seeking but I think the amount of work required
> > and the added complexity for the distributions will make that hard to get
> > distributions to sign up for.
> > 
> > If someone had the time to write a front end to install packages into
> > a single "system-wide isolation unit" whose backend was a virtualenv we
> > might be able to get distributions on-board with using that.
> 
> I don't think we're asking distributions anything. We're suggesting a
> possible path, but it's not python-dev's job to dictate distributions
> how they should package Python.
> 
> The virtualenv solution has the virtue that any improvement we might
> put in it to help system packagers would automatically benefit everyone.
> A specific "system Python" would not.
> 
> > The front end would need to install software so that you can still invoke
> > /usr/bin/system-application and "system-application" would take care of
> > activating the virtualenv.  It would need to be about as simple to build
> > as the present python2 setup.py build/install with the flexibility in
> > options that the distros need to install into FHS approved paths.  Some
> > things like man pages, locale files, config files, and possibly other data
> > files might need to be installed outside of the virtualenv directory.
> 
> Well, I don't understand what difference a virtualenv would make.
> Using a virtualenv amounts to invoking a different interpreter path.
> The rest of the filesystem (man pages locations, etc.) is still
> accessible in the same way. But I may miss something :-)
> 
  I think people who are saying "The system should just use
virtualenv" aren't realizing all of the reasons that's not as simple as it
sounds for distributions to implement.  thus the work required to implement
alternate solutions like a system python may seem less to the distros 
unless those issues are partially addressed at the virtualenv and
python-packaging level.

-Toshio


pgpVr_lDSoJ_Q.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] Use ptyhon -s as default shbang for system python executables/daemons

[Gregory P. Smith]

On Wed, Mar 18, 2015 at 9:48 AM Barry Warsaw  wrote:

> On Mar 18, 2015, at 05:31 PM, Victor Stinner wrote:
>
> >Does it work to pass command line options to Python in the shebang?
>
> Yes, but only one "word", thus -Es or -I.
>
> We've often mused about whether it makes sense to have two Pythons on the
> system.  One for system scripts and another for users.  System Python
> ('/usr/bin/spython' perhaps) would be locked down and only extensible by
> system packages.  On Debuntu that might mean no /usr/local on sys.path.  It
> would also have a much more limited set of installed packages, i.e. only
> those
> needed to support system functionality.
>

I recommend this. It'd be nice to see a common OS distro actually do it.

For a system-only Python lockdown you should remove distutils and pip to
prevent anyone from easily installing anything that isn't a distro package
into it. Possibly even removing its site-packages directory and sys.path
entry all together (things your distro needs to install could mix directly
with the stdlib packages)


> /usr/bin/python2 and /usr/bin/python3 then would be user tools, with all
> the
> goodness they currently have.
>
> It's never gotten much farther than musings, but protecting the system
> against
> the weird things people install would be a good thing.  OTOH, this feels a
> lot
> like virtual environments so maybe there's something useful to be mined
> there.
>

While people sometimes suggest virtualenv as a solution for this. It isn't
really the same thing. It isn't a hermetic clone of the original
interpreter.  It copies the main binary but symlinks back to much of the
stdlib.  So any existing virtualenv can be an out of date unsupported mix
of both after the original interpreter is updated. This has caused users
problems in the past with some minor version updates where an internal
non-public API used between some binary and a stdlib module was updated as
part of a bugfix. Suddenly they didn't match up for existing virtualenvs.

virtualenv is an amazing hack that I promote to most anyone for their own
applications use with the occasional known caveats (solvable by regurly
rebuilding your virtualenvs)...  But I wouldn't want to see it used for the
core OS itself even though it sounds better at first glance.

-gps
___
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] Use ptyhon -s as default shbang for system python executables/daemons

[Antoine Pitrou]

On Mon, 23 Mar 2015 21:58:06 +
"Gregory P. Smith"  wrote:
> 
> virtualenv is an amazing hack that I promote to most anyone for their own
> applications use with the occasional known caveats (solvable by regurly
> rebuilding your virtualenvs)...  But I wouldn't want to see it used for the
> core OS itself even though it sounds better at first glance.

pyvenv is not a hack, it mostly creates a couple symlinks and adds a
pip install into the environment.

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] Use ptyhon -s as default shbang for system python executables/daemons

[Cameron Simpson]

On 23Mar2015 21:58, Gregory P. Smith  wrote:

While people sometimes suggest virtualenv as a solution for this. It isn't
really the same thing. It isn't a hermetic clone of the original
interpreter.  It copies the main binary but symlinks back to much of the
stdlib.


Oh.

I had thought a non-standalone venv arranged sys.path to fall back to the 
source interpreter.  Clearly I have not paid attention.


Cheers,
Cameron Simpson 

Yes, sometimes Perl looks like line-noise to the uninitiated, but to the
seasoned Perl programmer, it looks like checksummed line-noise with a mission
in life.- The Llama Book
___
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] cpython: #23657 Don't explicitly do an isinstance check for str in zipapp

[Serhiy Storchaka]

On 22.03.15 17:33, paul.moore wrote:

https://hg.python.org/cpython/rev/0b2993742650
changeset:   95126:0b2993742650
user:Paul Moore 
date:Sun Mar 22 15:32:36 2015 +
summary:
   #23657 Don't explicitly do an isinstance check for str in zipapp

As a result, explicitly support pathlib.Path objects as arguments.
Also added tests for the CLI interface.


Congratulate with your first commit 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] cpython: #23657 Don't explicitly do an isinstance check for str in zipapp

[Paul Moore]

On 23 March 2015 at 22:29, Serhiy Storchaka  wrote:
>> As a result, explicitly support pathlib.Path objects as arguments.
>> Also added tests for the CLI interface.
>
> Congratulate with your first commit Paul!

Thanks :-)
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] super() does not work during class initialization

[Greg Ewing]

Martin Teichmann wrote:

maybe
we could just change the compiler to leave the order in which things are defined
in a class in the class namespace, say as a member __order__? Then we could
use plain-old dicts for the class namespace, and we would not slow down class
creation (not that it matters much), as determining the order would happen at
compile time.


I don't think the compiler can determine the order in
all cases. Consider:

  class Spam:

if moon_is_full:
  alpha = 1
  beta = 2
else:
  beta = 2
  alpha = 1

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