Delurking
The path module has a great idea, but it does too much -- it conflates
too many ideas into a single module.
It has methods for dealing with files (open, bytes, read, etc) as well
as methods for dealing with a filesystem tree as a whole (relpath,
abspath, etc). Both of these ideas
One other benefit that I neglected to put into the previous post - I was
able to maintain separate cwd's for each tree.
An example of use:
Each tree has its own context, independent of the context of python:
local, local2 = fs.LocalTree(), fs.LocalTree()
local.pwd
'/home/targoz'
Mario wrote:
USE CASE F:
Van Lindberg is concerned about code submissions from non-core
developers: how can the PSF re-license this code in the future without
talking to each contributor, whether the PSF is safe from litigation
based on copyrights of these contributions and related questions
scripts? If they aren't too
complex, I'd be willing to port to Powershell.
For what its worth, there have been a number of efforts in this direction:
https://bitbucket.org/guillermooo/virtualenvwrapper-powershell
https://bitbucket.org/vanl/virtualenvwrapper-powershell
(Both different
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all platforms should be
as follows:
On 3/13/2012 4:19 PM, Terry Reedy wrote:
What is {base/userbase} actually on a typical machine? It is fixed or
user choice?
It is based upon user choice and on whether it is a system-wide install
(base) or a single-user install (userbase). Typically, though, it is
just where you installed
On 3/13/2012 3:11 PM, Brian Curtin wrote:
I'm familiar with the scripts/bin change. I take it the rest of that
stuff matches *nix? Text later on seems to support this, so I think
I'm on board with it.
Yes, that is correct.
Martin and I spoke on Friday and at least the bin/ folder and Path
On Mar 13, 2012, at 8:37 PM, Martin v. Löwis mar...@v.loewis.de wrote:
1) The layout for the python root directory for all platforms should be
as follows:
stdlib = {base/userbase}/lib/python{py_version_short}
platstdlib = {base/userbase}/lib/python{py_version_short}
purelib =
On 3/13/2012 9:58 PM, Terry Reedy wrote:
Given that we already repeat it, isn't it better to be consistent?
But there is no repetition currently on Windows installations.
I though you were just proposing to switch lib (lower-cased, and scripts
renamed as bin, and pythonxx). So I do not think
On 3/14/2012 9:53 AM, Jim J. Jewett wrote:
In
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:
1) The layout for the python root directory for all platforms should be
as follows:
stdlib =
On 3/14/2012 10:09 AM, Scott Dial wrote:
I think you are confusing two different configuration sections in
sysconfig.cfg:
[nt]
stdlib = {base}/Lib
platstdlib = {base}/Lib
purelib = {base}/Lib/site-packages
platlib = {base}/Lib/site-packages
include = {base}/Include
platinclude = {base}/Include
On 3/14/2012 1:32 AM, Mark Hammond wrote:
As per comments later in the thread, I'm -1 on including
python{py_version_short} in the lib directories for a number of
reasons; one further reason not outlined is that it would potentially
make running Python directly from a built tree difficult. For
On 3/14/2012 10:56 AM, Terry Reedy wrote:
Are you talking about 'install for all users' versus 'install for this
user only'? I have always done the former as I see no point to the
latter on my machine, even if another family member has an account.
Yes, but some people are on corporate machines
On 3/14/2012 5:39 PM, Mark Hammond wrote:
Can you offer any examples of 3rd party tools which could unify code in
this scheme, and particularly, where this scheme would cause them to
have less code, not more?
How about virtualenv:
def path_locations(home_dir):
Return the path locations for
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
The fact is that most code doesn't know about this, only installers or
virtual
On 3/15/2012 6:19 PM, Mark Hammond wrote:
[At least I think that is your proposal - can you confirm that the
directory layouts in your proposal exactly match the directory
layouts in virtual envs on all other platforms? ie, that
inconsistencies like the python{py_version_short} suffix will not
Germane to this discussion, I reached out for feedback. Most people
didn't care about the issue, or were slightly inclined to have it be
uniform across platforms.
As Terry mentioned, I think that long-term uniformity will benefit
everybody down the line, and that is the way to go.
The most
On 3/20/2012 10:52 AM, Martin v. Löwis wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I never understood. On Windows, it's
On 3/20/2012 11:19 AM, Martin v. Löwis wrote:
No - there is an version #3a: 3.a) Get a shell and run the script CD
into the directory, then directly run foo.py, without prefixing it
with python.exe. This doesn't require any changes to the path, and is
shorter in usage than having the path
On 3/20/2012 1:50 PM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanLvan.lindb...@gmail.com wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
On 3/20/2012 1:56 PM, Paul Moore wrote:
This is covered (better, IMO) by PEP 397 - Python Launcher for
Windows. Step 2, just run py. If you prefer a particular version,
run py -2 or py -3 or py -3.2.
Interesting. I haven't played around with that at all, so can't comment.
I will have to
On 3/20/2012 3:15 PM, Paul Moore wrote:
On 20 March 2012 19:35, Lindberg, Vanvan.lindb...@haynesboone.com wrote:
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no
On 3/20/2012 4:49 PM, Mark Hammond wrote:
So I'm assuming that:
* The executable (and DLL) are moved to a bin directory in an
installed Python.
* distutils etc will change to install all scripts (or executables
generated from scripts) into that same directory. IOW, Scripts
would die.
* A
On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
It's worth remembering Éric's point - distutils is frozen and changes
are in theory not allowed. This part of the proposal is not possible
without an exception to that ruling. Personally, I don't see how
making this change could be a
As this has been brought up a couple times in this subthread, I figured
that I would lay out the rationale here.
There are two proposals on the table: 1) Regularize the install layout,
and 2) move the python binary to the binaries directory. This email will
deal with the first, and a second
[PART 2: Moving the python binary]
There are two proposals on the table: 1) Regularize the install layout,
and 2) move the python binary to the binaries directory. This email
deals with the second issue exclusively. This has been the more
contentious issue.
2) Moving the Python exe:
A
Hi Paul,
To start with, I appreciate your comments, and it is worth having both
sides expressed.
On 3/22/2012 12:59 PM, Paul Moore wrote:
I'm repeating myself here after I promised not to. My apologies, but I
don't think this posting captures the debate completely. One reason I
suggested a
Another use case was just pointed out to me: making things consistent with
buildout. Given a similar use case (create repeatable cross platform
environments), they create and use a 'bin' directory for executable files.
___
Python-Dev mailing list
On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
Even if you are using tools that don't use distutils' configuration settings
for these directories, why not simply fix those tools so that they do?
Thats what I do currently - I set things to bin and patch Python and the tools
so that
On Friday, March 23, 2012 at 1:35 PM, PJ Eby wrote:
Tool developers are going meh about your proposal because it doesn't
actually solve any problems for them: they still have to support the old
layout, and if their code already uses distutils' facilities for obtaining
paths, there's
On Mar 23, 2012 10:21 PM, PJ Eby p...@telecommunity.com wrote:
On Mar 23, 2012 4:19 PM, VanL van.lindb...@gmail.com wrote:
Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work
I heard back from Enthought on this part of the proposal. They could
accommodate this change.
1) The layout for the python root directory for all platforms should be
as follows:
stdlib = {base/userbase}/lib/
platstdlib = {base/userbase}/lib/
purelib = {base/userbase}/lib/site-packages
platlib
Brett Cannon wrote:
I was going through our list of email addreses for committers and
realized that I don't have an address for john.benediktsson that
works; his ewtllc.com address is bouncing. Anyone have an up-to-date
one?
Replied privately.
___
Sigurd Torkel Meldgaard wrote:
Hi to all Python developers
For a student project in a course on virtual machines, we are
evaluating the possibility to
experiment with removing the GIL from CPython...
Just an FYI, these two particular students already introduced themselves
on the PyPy list.
VanL wrote:
Just an FYI,
...and the FYI was to no one in particular, just interesting information
from the PyPy list. It is just unfortunate timing that made it look like
a cheeky reply to Guido.
___
Python-Dev mailing list
Python-Dev@python.org
On 7/5/2010 11:47 PM, Antoine Pitrou wrote:
The point of free software licenses, though (as opposed to proprietary
licenses), is not mainly to go to court (to “protect IP”, as the PSF
says - quite naively in my opinion); it is to enable trust among people.
Yes, that is true. Open source
On 7/5/2010 8:03 PM, Steve Holden wrote:
Neil Hodgson wrote:
There have been moves in the past to simplify the license of Python
but this would require agreement from the current rights owners
including CWI and CNRI. IIRC not all of the rights owners are willing
to agree to a change.
That
NB: Posting on behalf of Greg Lindstrom, our tutorial coordinator:
PyCon 2011 will be held March 9th through the 17th, 2011 in Atlanta,
Georgia. (Home of some of the best southern food you can possibly find
on Earth!) The PyCon conference days will be March 11-13, preceded by
two tutorial days
Have you had any bites?
Thanks,
Van
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Do you have a year-end hole in your training budget? Or will the
improved economy let you finally attend a work conference? Come to sunny
and warm Atlanta in February for PyCon 2010. Early bird registration
ends on January 6.
Register: https://us.pycon.org/2010/register/
See the talks:
PyCon is coming! Tomorrow (February 10th) is the last day for
pre-conference rates. You can register for PyCon online at:
https://us.pycon.org/2010/register/
Register while it is still Feb. 10th somewhere in the world and rest
easy in the knowledge that within 10 days you will enjoying the
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to
On 5/7/2010 12:41 PM, Steven D'Aprano wrote:
Now, if I write
def f1(x,y): return x+y
def f2(x,y): return x+y
I don't expect f1==f2 to be True, even though f1 and f2 behave in
exactly the same way, and indeed it is not.
This is not what I am getting after; these (IMO) should
On 5/11/2010 11:54 PM, Cameron Simpson wrote:
I know for functions == and is currently are equivalent, but we should be
really finicky here about intent, especially since a few messages in the
thread is contemplate testing function for equivalence to one degree or
other. At which point == and
Hi all,
I am looking into an issue associated with the wininst-*.exe files in the
distutils/command subdirectory. It looks like these are the executable
stubs used to create self-extracting zips for installation - but I am not
100% sure. It also looks like they include the calls to standard
Thank you all, this gives me what I need. Sorry I missed the source in the
the PC/ directory.
Thanks,
Van
On Thu, Oct 18, 2018 at 9:41 AM Zachary Ware
wrote:
> On Thu, Oct 18, 2018 at 9:09 AM VanL wrote:
> > Hi all,
> >
> > I am looking into an issue associated with th
report applies to 3.5/3.6/3.7.
Thanks,
Van
On Thu, Oct 18, 2018 at 11:26 AM Petr Viktorin wrote:
> On 10/18/18 4:40 PM, Zachary Ware wrote:
> > On Thu, Oct 18, 2018 at 9:09 AM VanL wrote:
> >> Hi all,
> >>
> >> I am looking into an issue ass
Hello everyone,
You all have probably noted that there have been some contentious threads
recently, ultimately ending in a few people being given a time-out from
posting on these lists.
I don't normally get into things on this list, but it has been generally
discouraging to see a bunch of
48 matches
Mail list logo
