Re: [Python-Dev] Proposing PEP 386 for addition
More English language fixes:
-In Python there are no real restriction yet on how a project should
+In Python there are no real restrictions yet on how a project should
-Furthermore, this will make OS packagers work easier when repackaging standards
-compliant distributions, as of now it can be difficult to decide how two
+Furthermore, this will make OS packagers' work easier when repackaging
standards
+compliant distributions, because as of now it can be difficult to decide how
two
-to support many or all existing versioning schemas.
+to support all or even most of existing versioning schemas.
-reasons and we cannot expect that to change. +reasons
that we cannot expect to change.
-version schemas and is a preferable alternative than supporting
+version schemas and is a preferable alternative to supporting
-there should be possible to express more than one versioning level
+it should be possible to express more than one versioning level
-The problem with this is that while it allows expressing requisite any
-nesting level it doesn't allow to express special meaning versions
-(pre and post-releases as well as development versions), as expressed in +The
problem with this is that while it allows expressing any
+nesting level it doesn't allow giving special meaning to versions
+(pre- and post-releases as well as development versions) as expressed in
-Also, notice that Distutils version classes are not really used in the
+Also, note that Distutils version classes are not really used in the
-which does not enforce any rule for the version, but
+which does not enforce any rules for the version, but
-Setuptools function is quite spread because it's used by tools
+Setuptools function is quite widespread because it's used by tools
-post-releases -- which apparently is used by a number of projects
+post-releases -- which apparently are used by a number of projects
This one is particularly critical to your intended meaning as I read it:
-before a .post345
marker.
+before a .post456
marker.
Technical question:
I don't know what notation this versioning schema was trying for, especially in
regards to what the +'s mean:
N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
Am I missing something here? You could maybe explain what the pluses mean in
the PEP, and why some are inside the [] and others are outside.
Or a regular expression version like this might be more specific.
N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)?
Or an linux help version like this may be more readible.
N.N[.N][{abc}N[.N]][.postN][.devN]
Cheers,
Michael Mysinger
(longtime python-dev lurker)
___
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
Re: [Python-Dev] Proposing PEP 386 for addition
Floris Bruynooghe gmail.com> writes:
> On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> > I don't know what notation this versioning schema was trying for, especially
in regards to what the +'s mean:
> > N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> >
> The full regex (stripped from named groups) is the rather unreadable:
> \d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?
The ()? around the combination of post and dev is not needed. I also think
[abc]? should just be [abc], as one letter is required to proceed the digit in
that case, and the full regular expression does help to distinguish exactly
which of those two is required by the PEP.
> So the '+' in the pseudo notation above roughly means "one or more"
> with the brackets meaning "zero or one" so plus and brackets combined
> result into "zero or more". But even then it's might be missing
> square brackets around the whole of "[abc]N[.N]+".
What is confusing about the +'s is that they are not consistent. If your regular
expression with my modifications above is right, then using the substitions 'N
for \d+', '{} for []', '[] for ()?' and '+ for *' leaves:
N.N[.N]+[{abc}N[.N]+][.postN][.devN]
Notice that the last two +'s are gone, and overall I think this is more
consistent psuedo-code.
> Note that the meaning of the contents of the brackets changes too
> ("abc" is a choice, .postN+ is the recursive notation) so it'll
> probably never work exactly. So maybe the PEP should also include the
> full regex for exactness.
>
> Regards
> Floris
Yes, it probably should have the full regex for absolute clarity, and it can
still have some type of psuedo-code for easier reading, but inconsistent
psuedo-code just adds confusion instead of simplification.
Cheers,
Michael
___
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
Re: [Python-Dev] pathlib - current status of discussions
Ethan Furman stoneleaf.us> writes: > Do we allow bytes to be returned from os.fspath()? If yes, then do we > allow bytes from __fspath__()? De-lurking. Especially since the ultimate goal is better interoperability, I feel like an implementation that people can play with would help guide the few remaining decisions. To help test the various options you could temporarily add a _allow_bytes=GLOBAL_CONFIG_OPTION default argument to both pathlib.__fspath__() and os.fspath(), with distinct configurable defaults for each. In the spirit of Python 3 I feel like bytes might not be needed in practice, but something like this with defaults of False will allow people to easily test all the various options. ___ 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] pathlib - current status of discussions
Brett Cannon python.org> writes: > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I originally proposed). > Thanks Brett, it is definitely a start! Maybe I am just more unimaginative than most, but since interoperability is the goal, I would ideally be able to play with a full implementation where all the stdlib functions Nick originally mentioned accepted these "rich path" objects. However, for concrete example purposes, maybe it is sufficient to start with your fspath function, a toy RichPath class implementing __fspath__, and something like os.path.join, which is a meaty enough example to test some of the functionality. I posted a gist of a string only example at https://gist.github.com/mmysinger/0b5ae2cfb866f7013c387a2683c7fc39 After playing with and considering the 4 possibilities, anything where __fspath__ can return bytes seems like insanity that flies in the face of everything Python 3 is trying to accomplish. In particular, one RichPath class might return bytes and another str, or even worse the same class might sometimes return bytes and sometimes str. When will os.path.join blow up due to mixing bytes and str and when will it work in those situations? So for me that eliminates #3 and #4. Also the version #2 accepting bytes in os.fspath felt like it could be a very minor convenience, but even the str only version #1 is just requires one isinstance check in the rare case you need to also deal with bytes (see the os.path.join example in the gist above). So I lean toward the str only #1 version. In any case I would start with the strict str only full implementation and loosen it either in 3.6 or 3.7 depending on what people think after actually using it. ___ 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] pathlib - current status of discussions
Ethan Furman stoneleaf.us> writes: > On 04/14/2016 12:03 AM, Michael Mysinger via Python-Dev wrote: > > In particular, one RichPath > > class might return bytes and another str, or even worse the same class might > > sometimes return bytes and sometimes str. When will os.path.join blow up due > > to mixing bytes and str and when will it work in those situations? > > What are you asking here? ... Meaning allowing os.fspath() > and __fspath__ to return either bytes or str will never cause the > combination of bytes and str to work. Said another way: if you are > using os.path.join then all the pieces have be str or all the pieces > have to be bytes. I am saying that if os.path.join now accepts RichPath objects, and those objects can return either str or bytes, then its much harder to reason about when I have all bytes or all strings. In essence, you will force me to pre- wrap all RichPath objects in either os.fsencode(os.fspath(path)) or os.fsdecode(os.fspath(path)), just so I can reason about the type. And if I have to always do that wrapping then os.path.join doesn't need to accept RichPath objects and call fspath at all. ___ 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] pathlib - current status of discussions
Donald Stufft stufft.io> writes: > > On Apr 14, 2016, at 11:59 AM, Michael Mysinger via Python-Dev python.org> wrote: > > > > In essence, you will force me to pre- > > wrap all RichPath objects in either os.fsencode(os.fspath(path)) or > > os.fsdecode(os.fspath(path)), just so I can reason about the type. > > This is only the case if you have a singular RichPath object that can represent both bytes and str (which is > what DirEntry does, which I agree makes it harder… but that’s already the case with DirEntry.path). > However that’s not the case if you have a bRichPath and uRichPath. And you might even be able to retain your sanity if you enforce any particular class to be either bRichPath or uRichPath. But if you do that, then that still leaves DirEntry out in the cold, likely converting to str in its __fspath__. Which leaves me in the camp that bRichPath falls under YAGNI, and RichPath should be str only. ___ 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
