As a simple user, pathlib simplifies playing with paths. A lot of things
are easy to do. For example, Pathlib / "subfile" is so useful.
I also have a subclass of pathlib.Path on github that makes easy seeking
for files and directories.
So keep alive pathlib !
Le 6 avr. 2016 13:06, "Paul Moore" <p.f.moore(a)gmail.com> a écrit :
On 6 April 2016 at 00:45, Guido van Rossum <guido(a)python.org> wrote:
> This does sound like it's the crucial issue, and it is worth writing
> up clearly the pros and cons. Let's draft those lists in a thread
> (this one's fine) and then add them to the PEP. We can then decide to:
>
> - keep the status quo
> - change PurePath to inherit from str
> - decide it's never going to be settled and kill pathlib.py
>
> (And yes, I'm dead serious about the latter, rather Solomonic option.)
By the way, even if there's no solution that satisfies everyone to the
"inherit from str" question, I'd still be unhappy if pathlib
disappeared from the stdlib. It's useful for quick admin scripts that
don't justify an external dependency. Those typically do quite a bit
of path manipulation, and as such benefit from the improved API of
pathlib over os.path.
+1 on making (and documenting) a final decision on the "inherit from
str" question
-1 on removing pathlib just because that decision might not satisfy everyone
Paul
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/projetmbc%40gmail.com
On Apr 6, 2016 1:26 AM, "Chris Angelico" <rosuav(a)gmail.com> wrote:
>
> On Wed, Apr 6, 2016 at 3:37 PM, Stephen J. Turnbull <stephen(a)xemacs.org>
wrote:
> > Chris Angelico writes:
> >
> > > Outside of deliberate tests, we don't create files on our disks
> > > whose names are strings of random bytes;
> >
> > Wishful thinking. First, names made of control characters have often
> > been deliberately used by miscreants to conceal their warez. Second,
> > in some systems it's all too easy to create paths with components in
> > different locales (the place I've seen it most frequently is in NFS
> > mounts). I think that's much less true today, but perhaps that's only
> > because my employer figured out that it was much less pain if system
> > paths were pure ASCII so that it mostly didn't matter what encoding
> > users chose for their subtrees.
>
> Control characters are still characters, though. You can take a
> bytestring consisting of byte values less than 32, decode it as UTF-8,
> and have a series of codepoints to work with.
>
> If your employer has "solved" the problem by restricting system paths
> to ASCII, that's a fine solution for a single system with a single
> ASCII-compatible encoding; a better solution is to mandate UTF-8 as
> the file system encoding, as that's what most people are expecting
> anyway.
>
> > It remains important to be able to handle nearly arbitrary bytestrings
> > in file names as far as I can see. Please note that 100 million
> > Japanese and 1 billion Chinese by and large still prefer their
> > homegrown encodings (plural!!) to Unicode, while many systems are now
> > defaulting filenames to UTF-8. There's plenty of room remaining for
> > copying bytestrings to arguments of open and friends.
>
> Why exactly do they prefer these other encodings? Are they
> representing characters that Unicode doesn't contain? If so, we have a
> fundamental problem (no Python program is going to be able to cope
> with these, without a third party library or some stupid mess of local
> code); if not, you can always represent it as Unicode and encode it as
> UTF-8 when it reaches the file system. Re-encoding is something that's
> easy when you treat something as text, and impossible when you treat
> it as bytes.
>
> So far, you're still actually agreeing with me: paths are *text*, but
> sometimes we don't know the encoding (and that's a problem to be
> solved).
re: bytestring, unicode, encodings after e.g. os.path.split / Path.split:
from "[Python-ideas] Type hints for text/binary data in Python 2+3 code"
https://mail.python.org/pipermail/python-ideas/2016-March/038869.html
>> would/will it be possible to
use Typing.Text as a base class for even-more abstract string types
https://mail.python.org/pipermail/python-ideas/2016-March/039016.html
>> * Text.encoding
>> * Text.lang (urn:ietf:rfc:3066)
... forgot to CC:
>> * https://tools.ietf.org/html/rfc5646
"Tags for Identifying Languages"
urn:ietf:rfc:5646
is this (Path) a narrower case of string types (#strypes), because after
transformations we want to preserve string metadata like e.g encoding?
I'd vote for
* adding DirEntry.__path__ as a proxy to DirEntry.path
* standardizing on __path__ (over .path)
* because this operation *is* fundamentally similar to e.g. __str__
* operator.path pathify, pathifize
>
> ChrisA
> _______________________________________________
> Python-Dev mailing list
> Python-Dev(a)python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
Originally I proposed a pair of macros for safe reference replacing to
reflects the duality of Py_DECREF/Py_XDECREF. [1], [2] The one should
use Py_DECREF and the other should use Py_XDECREF.
But then I got a number of voices for the single name [3], and no one
voice (except mine) for the pair of names. Thus in final patches the
single name Py_SETREF that uses Py_XDECREF is used. Due to adding some
overhead in comparison with using Py_DECREF, this macros is not used in
critical performance code such as PyDict_SetItem().
Now Raymond says that we should have separate Py_SETREF/Py_XSETREF names
to avoid any overhead. [4] And so I'm raising this issue on Python-Dev.
Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF
that uses Py_DECREF?
[1] http://comments.gmane.org/gmane.comp.python.devel/145346
[2] http://comments.gmane.org/gmane.comp.python.devel/145974
[3] http://bugs.python.org/issue26200#msg259784
[4] http://bugs.python.org/issue26200
After digging through obmalloc.c to optimize some memory intensive code, I
put a paper together on the entire private memory heap that may or may not
be a useful addition to docs.
I was hoping someone could review/proof it for errors in content.
Not sure the policy on links but I've uploaded it to google drive:
https://drive.google.com/open?id=0B6IkX5KnPHVLamwxSTNYR3dJYkE
thanks,
jon
Python's exception handling system is currently badly brokeTypeError:
unsupported operand type(s) for +: 'NoneType' and 'NoneType'n. Therefore,
with the recent news of the joyous release of Python 8 (
https://mail.python.org/pipermail/python-dev/2016-March/143603.html), I
have decided to propose a revolutionary idea: safe mock objects.
A "safe" mock object (qualified name
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`;
Java-style naming was adopted for readability purposes; comments are now no
longer necessary) is a magic object that supports everything and returns
itself. Since examples speak more words than are in the Python source code,
here are some (examples, not words in the Python source code):
a = 1
b = None
c = a + b # Returns a
_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8
print(c) # Prints the empty string.
d = c+1 # All operations on
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`'s
return a new one.
e = d.xyz(1, 2, 3) # `e` is now a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
def f():
assert 0 # Causes the function to return a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
raise 123 # Does the same thing.
print(L) # L is undefined, so it becomes a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
Safe mock objects are obviously the Next Error Handling Revolution ™.
Unicode
errors now simply disappear and return more
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`s.
As for `try` and `catch` (protest the naming of `except`!!) statements,
they will
be completely ignored. The `try`, `except`, and `finally` bodies will all be
executed in sequence, except that printing and returning values with an
`except`
statement does nothing:
try:
xyz = None.a # `xyz` becomes a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
except:
print(123) # Does nothing.
return None # Does nothing.
finally:
return xyz # Returns a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
Aggressive error handling (as shown in PanicSort [https://xkcd.com/1185/])
that does destructive actions (such as `rm -rf /`) will always execute the
destructive code, encouraging more honest development.
In addition, due to errors simply being ignored, nothing can ever quite go
wrong.
All discussions about a safe navigation operator can now be immediately
halted,
since any undefined attributes will simply return a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
Although I have not yet destroy--I mean, improved CPython to allow for this
amazing idea, I have created a primitive implementation of the
`_frozensafemockobjectimplementation` module:
https://github.com/kirbyfan64/_frozensafemockobjectimplementation
I hope you will all realize that this new idea is a drastic improvement
over current technologies and therefore support it, because we can Make
Python Great Again™.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
Summary: There are two prospective Google Summer of Code (GSOC) students
applying to work on writing a gui interface to the basic pip functions
needed by beginners. I expect Google to accept their proposals. Before
I commit to mentoring a student (sometime in April), I would like to be
sure, by addressing any objections now, that I will be able to commit
the code when ready (August or before).
Long version:
In February 2015, Raymond Hettinger opened tracker issue
"IDLE to provide menu options for using PIP"
https://bugs.python.org/issue23551#msg236906
The menu options would presumably open dialog boxes defined in a new
module such as idlelib.pipgui. Raymond gave a list of 9 features he
thought would be useful to pip beginners.
Donald Stufft (pip maintainer) answered that he already wanted someone
to write a pip gui, to be put somewhere, and that he would give advice
on interfacing (which he has).
I answered that I had also had a vague idea of a pip gui, and thought it
should be a stand-alone window invoked by a single IDLE menu item, just
as turtledemo can be now. Instead of multiple dialogs (for multiple
IDLE menu items), there could be, for instance, multiple tabs in a
ttk.Notebook. Some pages might implement more than 1 of the features on
Raymond's list.
Last September, I did some proof-of-concept experiments and changed the
title to "IDLE to provide menu link to PIP gui". In January, when Terri
Oda requested Core Python GSOC project ideas, I suggested the pip gui
project. I believe Raymond's list can easily be programmed in the time
alloted. I also volunteered to help mentor.
Since then, two students have submitted competent prototypes (on the
tracker issue above) that show that they can write a basic tkinter app
and revise in response to reviews.
My current plan is to add idlelib/pipgui.py (or perhaps pip.py) to 3.5
and 3.6. The file will be structured so that it can either be run as a
separate process ('python -m idlelib.pipgui' either at a console or in a
subprocess call) or imported into a running process. IDLE would
currently use a subprocess call, but if IDLE is restructured into a
single-window, multi-tab application, it might switch to using an import.
I would document the new IDLE menu entry in the current IDLE page.
Separately from the pip gui project, I plan, at some point, to add a new
'idlelib' section that documents public entry points to generally useful
idlelib components. If I do that before next August, I would add an
entry for pipgui (which would say that details of the GUI are subject to
change).
Possible objections:
1. One might argue that if pipgui is written so as to not depend on
IDLE, then it, like turtledemo, should be located elsewhere, possibly in
Tools/scrips. I would answer that managing packages, unlike running
turtle demos, *is* an IDE function.
2. One might argue that adding a new module with a public entry point,
in a maintenance release, somehow abuses the license granted by PEP434,
in a way that declaring a public interface in an existing module would
not. If this is sustained, I could not document the new module for 3.5.
Thoughts?
--
Terry Jan Reedy