[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()

[Barney Gale]

Hi Brett,

Per your PR review feedback [0] I left a comment on the bug [1] asking when
the link_to() method should be scheduled for removal. It didn't elicit a
great deal of feedback, so I'm raising this again here!

The proposed deprecation warning in the docs currently reads:

> This method is deprecated in favor of :meth:`Path.hardlink_to`, as its
argument order does not match that of :meth:`Path.symlink_to`.

My view is that the removal does not need to happen soon. Any existing code
will be written by people who have already figured out the argument
reversal, so the current situation doesn't seem dangerous. That said, a
speedy deprecation and replacement will remove a guaranteed headache for
people creating hardlinks in pathlib.

Apologies if replying to an old thread is bad form - I'm not well versed in
mailing list etiquette.

Best,

Barney

[0] https://github.com/python/cpython/pull/18909#discussion_r392416154
[1] https://bugs.python.org/issue39950#msg365275

On Wed, 11 Mar 2020 at 17:31, Brett Cannon  wrote:

> Antoine Pitrou wrote:
> > On Wed, 11 Mar 2020 11:17:22 +
> > Barney Gale barney.g...@gmail.com wrote:
> > > Hi,
> > > Pathlib's symlink_to() and link_to() methods have different argument
> > > orders, so:
> > > a.symlink_to(b)  # Creates a symlink from A to B
> > > a.link_to(b)  # Creates a hard link from B to A
> > >
> > > I don't think link_to() was intended to be implemented this way, as the
> > > docs say "Create a hard link pointing to a path named target.". It's
> also
> > > inconsistent with everything else in pathlib, most obviously
> symlink_to().
> > > Bug report here: https://bugs.python.org/issue39291
> > > This /really/ irks me. Apparently it's too late to fix link_to(), so
> I'd
> > > like to suggest we add a new hardlink_to() method that matches the
> > > symlink_to() argument order. link_to() then becomes
> deprecated/undocumented.
> > > I think that's a good idea.
>
> +1 from me as well; new method and deprecate the old one.
>
> > Regards
> > Antoine.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/EID35RFJJQBHL4WKSO5DM36O7DDVDEKP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3MCTZLLCZ2WGVPDW6R5RK7YNL7WK52D6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Request for reviewers: pathlib improvements

[Barney Gale]

I’m working towards supporting subclassing pathlib.Path for things like
zip/tar archives, iso files, S3, etc. This was first brought up a few years
ago in bpo-24132  and discussed further
on the python-ideas forum
.

Before I can approach the meat of the issue, I'd like to land a handful of
backwards-compatible patches that tidy up the pathlib internals. These are:

   - #19220  / bpo-39924
   : Handle missing os functions more
   consistently in pathlib
   - #18838  / bpo-39895
   : Move pathlib.Path.touch()
   implementation into the path accessor
   - #19342  / bpo-40038
   : Remove partial support for
   preserving accessor when modifying a path
   - #18841  / bpo-39899
   : Make pathlib use
   os.path.expanduser() to expand home directories
   - #18834  / bpo-39659
   : Route calls from pathlib.Path to
   os.getcwd() via the path accessor
   - #18864  / bpo-39906
   : Add follow_symlinks parameter to
   pathlib.Path.stat() and chmod()
   - #24294  / bpo-42999
   : Expand and clarify
   pathlib.Path.link_to() documentation

Could I please request review of these patches? A couple may already be
ready to land.

(I appreciate they’re a little dry. This is all prep work for the
introduction of a shiny new class, tentatively named ‘AbstractPath’).

Thanks!

Barney
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6J53VWCZWO4SKSS7BIDBEGF6YWAJV5KY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Help to Resolve issues with Pull request 25220

[Barney Gale]

Hi Anthony,

It looks like you’ve incorporated several other changes into your commit by
mistake. The simplest thing to do might be to re-create your git branch and
PR from scratch.

If conflicting changes land while your PR is still open, you’ll need to do
something called a “rebase”. The git book
 explains this well.

Barney

On Wed, 7 Apr 2021 at 11:22, anthony.flury via Python-Dev <
python-dev@python.org> wrote:

> All,
>
> Can someone better than me (i.e anyone) help me resolve the issues with
> Pull Request 25220.
>
> I followed the dev guide, but I assume that between me taking my fork of
> the cpython repository, and building my pull request, another pull request
> was merged into master.
>
> It also appears that the Documentation build is failing with an rst
> reference tag error on part of the document I never changed.
>
> I am finding it difficult to drive github to understand how to resolve the
> conflict (i.e how to retain both sets of changes) - so any help would be
> appreciated.
>
> Regards,
> --
> Anthony Flury
> *Moble*: +44 07743 282707
> *Home*: +44 (0)1206 391294
> *email*: anthony.fl...@btinternet.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/EPLT4DTJCTOJZ26YNMBORTL77WFLMKGD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N6U63WJGFNAXBSIUUSPZ2D67P7CNQBPX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for reviewers: pathlib improvements

[Barney Gale]

Thanks so much to everyone who discussed and reviewed the code and made
suggestions.

The bulk of these patches have now landed. For those following along at
home, here’s a summary of the remaining PRs/bugs :

   - #18909 <https://github.com/python/cpython/pull/18909> / bpo-39950
   <https://bugs.python.org/issue39950>: Add Path.hardlink_to() method that
   supersedes link_to()
  - Note: already under core review
   - #25271 <https://github.com/python/cpython/pull/25271> / bpo-42998
   <https://bugs.python.org/issue42998>: Add ‘user’ parameter to Path.home()
   - #25240 <https://github.com/python/cpython/pull/25240> / bpo-40107
   <https://bugs.python.org/issue40107>: Stop using os.open() to implement
   Path.open()
   - #25264 <https://github.com/python/cpython/pull/25264> / bpo-43757
   <https://bugs.python.org/issue43757>: Make Path.resolve() use
   os.path.realpath() to resolve all symlinks in a path
  - Note: changes realpath() behaviour when symlink loops are
  encountered (!), and adds a keyword-only 'strict' param.
   - #25277 <https://github.com/python/cpython/pull/25277> / bpo-39899
   <https://bugs.python.org/issue39899>: Follow-up fix for oversight in
   #18841 <https://github.com/python/cpython/pull/18841>

I believe this is a complete account of the outstanding prep work. Once
these land, pathlib’s *path*, *flavour* and *accessor* abstractions will be
less leaky, which allows work on pathlib.AbstractPath to proceed.

Thanks again to Antoine Pitrou, Brett Cannon, Serhiy Storchaka, Steve Dower
and Eryk Sun for their invaluable contributions.

Barney

On Sat, 3 Apr 2021 at 03:02, Barney Gale  wrote:

> I’m working towards supporting subclassing pathlib.Path for things like
> zip/tar archives, iso files, S3, etc. This was first brought up a few years
> ago in bpo-24132 <https://bugs.python.org/issue24132> and discussed
> further on the python-ideas forum
> <https://discuss.python.org/t/make-pathlib-extensible/3428>.
>
> Before I can approach the meat of the issue, I'd like to land a handful of
> backwards-compatible patches that tidy up the pathlib internals. These are:
>
>- #19220 <https://github.com/python/cpython/pull/19220> / bpo-39924
><https://bugs.python.org/issue39924>: Handle missing os functions more
>consistently in pathlib
>- #18838 <https://github.com/python/cpython/pull/18838> / bpo-39895
><https://bugs.python.org/issue39895>: Move pathlib.Path.touch()
>implementation into the path accessor
>- #19342 <https://github.com/python/cpython/pull/19342> / bpo-40038
><https://bugs.python.org/issue40038>: Remove partial support for
>preserving accessor when modifying a path
>- #18841 <https://github.com/python/cpython/pull/18841> / bpo-39899
><https://bugs.python.org/issue39899>: Make pathlib use
>os.path.expanduser() to expand home directories
>- #18834 <https://github.com/python/cpython/pull/18834> / bpo-39659
><https://bugs.python.org/issue39659>: Route calls from pathlib.Path to
>os.getcwd() via the path accessor
>- #18864 <https://github.com/python/cpython/pull/18864> / bpo-39906
><https://bugs.python.org/issue39906>: Add follow_symlinks parameter to
>pathlib.Path.stat() and chmod()
>- #24294 <https://github.com/python/cpython/pull/24294> / bpo-42999
><https://bugs.python.org/issue42999>: Expand and clarify
>pathlib.Path.link_to() documentation
>
> Could I please request review of these patches? A couple may already be
> ready to land.
>
> (I appreciate they’re a little dry. This is all prep work for the
> introduction of a shiny new class, tentatively named ‘AbstractPath’).
>
> Thanks!
>
> Barney
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XTXOUBCTLFO6AQBL66AM37QAVTXJ4YND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Barney Gale]

> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison

To add to this, comparing tuples doesn't always work well for projects
where multiple release lines are maintained simultaneously, e.g.
user-facing changes introduced in minor/point releases across several major
versions. People use version numbers in wildly different ways.

Barney

On Wed, 14 Apr 2021 at 13:26, Victor Stinner  wrote:

> On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker 
> wrote:
> > So what do you'all think? After thirteen years, it would be nice to put
> this to bed.
>
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
> https://packaging.pypa.io/en/latest/version.html
>
> Many C libraries provide the version as a number of as 3 numbers
> (major, minor, micro). In its C API, Python provides all of them:
>
> * PY_VERSION_HEX: single number
> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
> * PY_VERSION: string
>
> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison: version_a <= version_b. Example:
>
> VERSION = (2, 2, 1)
> __version__ = '.'.join(map(str, VERSION))
>
> The tuple might contain strings like "beta" or "rc", as soon as
> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
> part is the major version? How to format it as a string?
>
> Good luck with trying to standardize that ;-)
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MBBYB5AWX76O3TOUFATRKSU2QND2TPKS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4XWIWIKDJJRWVKNGIOENJ2ZJVQR4PP23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for reviewers: pathlib improvements

[Barney Gale]

Hi all,

I hope I’m not in danger of abusing this mailing list - please let me know
if this is too much noise.

I’m very happy to share that 3 more pathlib PRs have landed - #18909
<https://github.com/python/cpython/pull/18909>, #25240
<https://github.com/python/cpython/pull/25240> and #25277
<https://github.com/python/cpython/pull/25277>. Thanks for the reviews - I
appreciate reviewer time is scarce!

I may be pushing my luck here, but there are *just two* PRs outstanding
before work on AbstractPath can begin in earnest.

I would love for these to land before the 3.10 feature freeze so that we
can spend the entire 3.11 development cycle getting the
design/implementation of AbstractPath exactly right. The PRs are:

   - #25271 <https://github.com/python/cpython/pull/25271> / bpo-42998
   <https://bugs.python.org/issue42998> - Add ‘user’ parameter to
   Path.home()
  - A simple patch. No reviewers yet
   - #25264 <https://github.com/python/cpython/pull/25264> / bpo-43757
   <https://bugs.python.org/issue43757> - Make Path.resolve() use
   os.path.realpath() to resolve all symlinks in a path
  - A more complex patch with several contributions from reviewers
  - Adds keyword-only ‘strict’ param to realpath()
  - Now backwards compatible! No longer changes default realpath()
  behaviour

If anyone can spare the time over the next week to help get these patches
over the line, I would really appreciate it!

A quick elevator pitch for why AbstractPath is an important future feature:

   - pathlib is a wonderful library that beautifully shows off Python’s
   “everything is an object” approach. It’s rightly front-and-centre of many
   Python beginner tutorials. If we can extend that “everything” to include
   files in tarballs, zip files, disc images, FTP servers, S3, etc, it allows
   Python users to easily apply their pathlib knowledge to new (and common!)
   tasks.
   - In DevOps it’s common to deal with remote or embedded filesystems.
   There’s a need for pathlib-like interfaces, and that need is already met in
   popular third-party packages either by *emulating* Path APIs (often with
   subtle differences) or *hackily extending* Path/_Accessor/_Flavour
   (which is brittle and totally unsupported). Even in the standard library,
   zipfile.Path is a mostly-compatible emulation of pathlib.Path. Providing a
   supported route for extending an AbstractPath saves a bunch of heartache
   and makes the wider pathlib ecosystem more robust.

Thanks again to everyone who has contributed their time and expertise up to
this point.

Cheers

Barney

On Fri, 9 Apr 2021 at 01:17, Barney Gale  wrote:

> Thanks so much to everyone who discussed and reviewed the code and made
> suggestions.
>
> The bulk of these patches have now landed. For those following along at
> home, here’s a summary of the remaining PRs/bugs :
>
>- #18909 <https://github.com/python/cpython/pull/18909> / bpo-39950
><https://bugs.python.org/issue39950>: Add Path.hardlink_to() method
>that supersedes link_to()
>   - Note: already under core review
>- #25271 <https://github.com/python/cpython/pull/25271> / bpo-42998
><https://bugs.python.org/issue42998>: Add ‘user’ parameter to
>Path.home()
>- #25240 <https://github.com/python/cpython/pull/25240> / bpo-40107
><https://bugs.python.org/issue40107>: Stop using os.open() to
>implement Path.open()
>- #25264 <https://github.com/python/cpython/pull/25264> / bpo-43757
><https://bugs.python.org/issue43757>: Make Path.resolve() use
>os.path.realpath() to resolve all symlinks in a path
>   - Note: changes realpath() behaviour when symlink loops are
>   encountered (!), and adds a keyword-only 'strict' param.
>- #25277 <https://github.com/python/cpython/pull/25277> / bpo-39899
><https://bugs.python.org/issue39899>: Follow-up fix for oversight in
>#18841 <https://github.com/python/cpython/pull/18841>
>
> I believe this is a complete account of the outstanding prep work. Once
> these land, pathlib’s *path*, *flavour* and *accessor* abstractions will
> be less leaky, which allows work on pathlib.AbstractPath to proceed.
>
> Thanks again to Antoine Pitrou, Brett Cannon, Serhiy Storchaka, Steve
> Dower and Eryk Sun for their invaluable contributions.
>
> Barney
>
> On Sat, 3 Apr 2021 at 03:02, Barney Gale  wrote:
>
>> I’m working towards supporting subclassing pathlib.Path for things like
>> zip/tar archives, iso files, S3, etc. This was first brought up a few years
>> ago in bpo-24132 <https://bugs.python.org/issue24132> and discussed
>> further on the python-ideas forum
>> <https://discuss.python.org/t/make-pathlib-extensible/3428>.
>>
>> Before I can ap

[Python-Dev] expanduser('~other') reliability and future

[Barney Gale]

There’s been a bit of discussion on the reliability of getting other users'
home directories via os.path.expanduser(), mostly on issue42998
.

In msg390503 , Serhiy
Storchaka pointed out that ntpath only makes an educated guess of other
user’s home directories.

In msg390535 , Eryk Sun
supplied an improved ntpath implementation that makes use of winreg and
ctypes.

In msg391970 , Steve Dower
pointed out that, if retrieving another user’s home directory on Windows is
unlikely to be made reliable, we should look at deprecating this
functionality in expanduser()

>From a bit of googling, Python seems to be an outlier in having a function
to retrieve another user’s home directory. I am encouraged by Eryk’s patch,
but a little out of my depth with Windows stuff.

Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If
not, should we deprecate this functionality? Or something else?

Barney
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BBLJXDRQ6WIG42AIOWTL43JEZUJF5TTY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Barney Gale]

+1 on 'complete'.

If 'enum.unique()' means 'every value has at most one name', then perhaps
`enum.complete()` can mean 'every value has at least one name'? Or is that
not accurate?

Other suggestions: 'occupied', 'full', 'exhaustive'.

Barney

On Mon, 31 May 2021 at 00:02, Jeff Allen  wrote:

> On 28/05/2021 04:24, Ethan Furman wrote:
>
>
> The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE
> are aliases for certain flag combinations.  But what if we have something
> like:
>
> class Color(Flag):
> RED = 1# 0001
> BLUE = 4   # 0100
> WHITE = 7  # 0111
>
> ...
>
> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator to verify that a Flag has no
> missing aliased values that can be used when the programmer thinks it's
> appropriate... but I have no idea what to call it.
>
> Any nominations?
>
> The propery you are looking for IIUC is that if a bit position is 1 in any
> member, then there is a member with only that bit set. I am seeing these
> members as sets of elements (bit positions) and therefore you want
> optionally to ensure that your enumeration has a name for every singleton
> set, into which any member could be analysed.
>
> Words like "basis", "complete", "analytic", or "indicator" (as in
> indicator function) come to mind. I find "singletonian" attractive, but
> no-one will know what it means, and I just made it up.
>
> Jeff
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7VN5Z5FSN3CH33KKQELX63L7JW6WEB2L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O5LBIFIBVAYDKBDKBXE5HDY4TA6SAUFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for reviewers: pathlib improvements

[Barney Gale]

Hi everyone,

It’s been a fairly quiet couple of months in pathlib work from myself -
just a couple of forum posts. Kevin Follstad has been beavering away on a PR
<https://github.com/python/cpython/pull/26906> to address bpo-24132
<https://bugs.python.org/issue24132>, I’ve promised him a review, though
I’m already late!

I’d like to request core review of 2 PRs, having already bumped the bugs /
forum threads and waited the statuatory 5 weeks. They are:

   - PR 26153 <https://github.com/python/cpython/pull/26153> - document and
   test pathlib.Path.absolute()
   - PR 25701 <https://github.com/python/cpython/pull/25701> - remove
   pathlib._Accessor

The first introduces documentation and tests for a feature that has long
existed and is in widespread use.

The second removes an internal indirection layer that complicates the code
(and therefore work on other pathlib tickets).

Very appreciate to any core dev who might be able to find the time for
these.

Thank you!

Barney

On Sat, 24 Apr 2021 at 23:16, Barney Gale  wrote:

> Hi all,
>
> I hope I’m not in danger of abusing this mailing list - please let me know
> if this is too much noise.
>
> I’m very happy to share that 3 more pathlib PRs have landed - #18909
> <https://github.com/python/cpython/pull/18909>, #25240
> <https://github.com/python/cpython/pull/25240> and #25277
> <https://github.com/python/cpython/pull/25277>. Thanks for the reviews -
> I appreciate reviewer time is scarce!
>
> I may be pushing my luck here, but there are *just two* PRs outstanding
> before work on AbstractPath can begin in earnest.
>
> I would love for these to land before the 3.10 feature freeze so that we
> can spend the entire 3.11 development cycle getting the
> design/implementation of AbstractPath exactly right. The PRs are:
>
>- #25271 <https://github.com/python/cpython/pull/25271> / bpo-42998
><https://bugs.python.org/issue42998> - Add ‘user’ parameter to
>Path.home()
>   - A simple patch. No reviewers yet
>- #25264 <https://github.com/python/cpython/pull/25264> / bpo-43757
><https://bugs.python.org/issue43757> - Make Path.resolve() use
>os.path.realpath() to resolve all symlinks in a path
>   - A more complex patch with several contributions from reviewers
>   - Adds keyword-only ‘strict’ param to realpath()
>   - Now backwards compatible! No longer changes default realpath()
>   behaviour
>
> If anyone can spare the time over the next week to help get these patches
> over the line, I would really appreciate it!
>
> A quick elevator pitch for why AbstractPath is an important future feature:
>
>- pathlib is a wonderful library that beautifully shows off Python’s
>“everything is an object” approach. It’s rightly front-and-centre of many
>Python beginner tutorials. If we can extend that “everything” to include
>files in tarballs, zip files, disc images, FTP servers, S3, etc, it allows
>Python users to easily apply their pathlib knowledge to new (and common!)
>tasks.
>- In DevOps it’s common to deal with remote or embedded filesystems.
>There’s a need for pathlib-like interfaces, and that need is already met in
>popular third-party packages either by *emulating* Path APIs (often
>with subtle differences) or *hackily extending*
>Path/_Accessor/_Flavour (which is brittle and totally unsupported). Even in
>the standard library, zipfile.Path is a mostly-compatible emulation of
>pathlib.Path. Providing a supported route for extending an AbstractPath
>saves a bunch of heartache and makes the wider pathlib ecosystem more
>robust.
>
> Thanks again to everyone who has contributed their time and expertise up
> to this point.
>
> Cheers
>
> Barney
>
> On Fri, 9 Apr 2021 at 01:17, Barney Gale  wrote:
>
>> Thanks so much to everyone who discussed and reviewed the code and made
>> suggestions.
>>
>> The bulk of these patches have now landed. For those following along at
>> home, here’s a summary of the remaining PRs/bugs :
>>
>>- #18909 <https://github.com/python/cpython/pull/18909> / bpo-39950
>><https://bugs.python.org/issue39950>: Add Path.hardlink_to() method
>>that supersedes link_to()
>>   - Note: already under core review
>>- #25271 <https://github.com/python/cpython/pull/25271> / bpo-42998
>><https://bugs.python.org/issue42998>: Add ‘user’ parameter to
>>Path.home()
>>- #25240 <https://github.com/python/cpython/pull/25240> / bpo-40107
>><https://bugs.python.org/issue40107>: Stop using os.open() to
>>implement Path.open()
>>- #25264 <https:

[Python-Dev] Re: Problems with dict subclassing performance

[Barney Gale]

Can someone please ban Marco? Temp ban would work fine.

Thanks

Barney

On Thu, 19 Aug 2021 at 21:24, Marco Sulla 
wrote:

> Anyway, Cannon, don't take it personal. I accuse the entire system,
> the whole CoC council.
>
> Indeed I was also fired some times ago from the python-ideas list:
>
> https://mail.python.org/archives/list/python-id...@python.org/message/KV4K4KS4MYTP5T5W5XKZYENGHCJYWOFR/
>
> The reasons?
>
>
> https://mail.python.org/archives/list/python-id...@python.org/message/VJMO4HOZGFCAKY2WA2RACHITPECFDKQ7/
>
> Because I responded to "Apparently you didn't read the post" with
> "Apparently you don't know Python". A bit too sarcastic, I admit, but
> enough to ban a person? Furthermore, I ended the post with "KISSes".
> This was considered a **rude** joke. From when KISS is considered
> rude???
>
> Another problematic post:
>
> https://mail.python.org/archives/list/python-id...@python.org/message/GKBF4NKVBASKUN7YJS6GDIMUUSAY7T2A/
>
> Because I wanted to be respectful and I didn't know about this stupid
> rule here that "mister" is considered an insult X-D
>
> Another:
> https://mail.python.org/archives/list/python-id...@python.org/message/X3SGPDEFJHKSNYXIW66AWJOW3PAKCOGQ/
>
> Because I said that first() is sexy. Sexualized language. Every
> serious programmer knows that "sexy" is another way to say "syntactic
> sugar".
>
> Another one:
> https://mail.python.org/archives/list/python-id...@python.org/message/QSMZKLQI47MZXDNXZ4HDOMDHEQLFUJYL/
> because I said "I can change my mind, I'm not a member of Daesh." Odd
> reference to an extremist organization. This is so ridiculous that I
> won't comment.
>
> I tried to defend myself by posting to conduct...@python.org . They
> never responded to me. So don't take it personal, Cannon.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RUDKUEJJSNXPV5PMWMNI7VEUQCMLW6HS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WZJA3X7ZDKTN52XGB5FWDNGQ7SCWP5KC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Barney Gale]

tox and pytest look at PY_COLORS:

https://github.com/tox-dev/tox/blob/9cc692d85c9ce84344ea7fee4b127755c6099a32/src/tox/session/commands/help.py
https://docs.pytest.org/en/6.2.x/reference.html#envvar-PY_COLORS

On Tue, 18 Jan 2022 at 21:17, Ethan Furman  wrote:

> On 1/18/22 11:59 AM, Pablo Galindo Salgado wrote:
>
>  > We considered using colours and other markers such as bold text, but
> that opens a considerable can of worms with
>  > detecting in all systems and configurations if that can be done. I have
> been told that some of these situations are
>  > quite tricky and is not as easy as checking for tty support.
>
> Maybe use an environment variable?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TRI25YRCTJSDQKERZM2DHCWOMGXHQA3M/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TH5HN7SKS6FV4QGB44IBN66VNHLLDMQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Barney Gale]

On Mon, 31 Jan 2022 at 23:29, Greg Ewing 
wrote:

> Or they may just feel that it's better to organise their changes into
> a number of small, independent commits rather than one large one. I
> wouldn't be too quick to jump to conclusions about people's motives
> here.


I've found that highly targeted PRs stand the best chance of getting
eyeballs/approvals/merges. It's not just preference - it's good sense.

And if folks want to "game" GitHub by spamming commits to an open source
project, CPython is a pretty poor choice! My occasional contributions can
take weeks or months to land due to the thorough review process and
peaks/troughs of core dev time for reviews.

Barney
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VMBMUZUHTGBSIZY45YDHPULMRA6IY7TT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Request for feedback: pathlib.AbstractPath prototype

[Barney Gale]

Over the last couple of years I've been tidying up the pathlib internals,
with a view towards adding an AbstractPath class to the hierarchy. Users
would be able to subclass AbstractPath to implement other kinds of
filesystems: s3, google cloud storage, pandas, ftp, git, zip and tar files,
etc. By implementing some abstract methods (stat(), iterdir(), open(), etc)
they'd benefit from a number of derived methods (is_dir(), glob(),
read_text(), etc). There's already a healthy ecosystem of PyPI packages
attempting this, but there's presently no officially-supported route.

I've now submitted a PR that adds an initial underscore-prefixed
implementation of this class: https://github.com/python/cpython/pull/31085.
The implementation is simple: wherever Path calls functions in os, io, pwd,
etc, AbstractPath instead raises NotImplementedError. The Path class
becomes an implementation of AbstractPath.

These methods directly raise NotImplementedError: cwd(), stat(), iterdir(),
readlink(), resolve(), expanduser(), owner(), group(), open(), touch(),
mkdir(), symlink_to(), hardlink_to(), rename(), replace(), chmod(),
unlink(), rmdir()

These methods call through to the above methods: absolute(), lstat(),
exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(),
is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(),
glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(),
lchmod(), link_to()

Some methods aren't applicable to some kinds of filesystems, e.g. zip files
don't support symlinks, working directories or home directories. In these
cases I think it's reasonable to raise NotImplementedError. Indeed,
pathlib.Path methods already raise NotImplementedError when certain local
filesystem features aren't available (readlink(), group(), etc).

If any readers of this list have previously tried to extend pathlib to
other domains, or are otherwise interested in pathlib development, please
could you let me know what you think of the proposed API?

Many thanks
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JB7QGDNI2CNXFX7LQQ2X2WPOZ7DWVNQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Barney Gale]

On Wed, 9 Feb 2022 at 15:46, Ethan Furman  wrote:

> On 2/9/22 6:59 AM, Barney Gale wrote:
>
>  > I've now submitted a PR that adds an initial underscore-prefixed
> implementation of this class:
>
> Why the iniitial underscore?  What could change between now and the future?
>

A few things:

Firstly, I'd like to give PyPI package maintainers the opportunity to play
with the underscore-prefixed API and submit feedback, prior to us freezing
the interface. They're already doing naughty things subclassing the
(internal, recently removed) pathlib._Accessor class. I think this feedback
might identify the need for new OSError subclass representing EINVAL for
readlink() implementations, or a new user-friendly os.stat_result
constructor for use in stat(). Or perhaps not :-)

Secondly, there's still a couple of rough edges in the PurePath
implementation, particularly around certain operations being delegated to a
mix-in class (the "flavour"). I'd like to bring those into PurePath before
we unleash this on the world, but it can be worked around for the time
being.

Thirdly, I've yet to address the problem of how we supply things like
sockets or zipfile.ZipFile objects, and persist them to child objects
generated by iterdir() etc. It can be done already by creating a further
subclass with the state assigned as a class attribute, but that's a bit
weird I think!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QOIDZYXZXQE27NG3J7UFHB6HQQKYIF4V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Barney Gale]

Penny for your thoughts on those questions, Brett? Protocols are new to me.
I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
read now.

I reckon only stat(), open() and iterdir() would be essential for users to
implement.

On Wed, 9 Feb 2022 at 19:02, Brett Cannon  wrote:

> One thing to discuss (and which has been brought up on the PR), is whether
> this should be an ABC to force people to explicitly raise
> `NotImplementedError`?
>
> The next question is whether any of this should be a (very wide) protocol
> instead of an ABC?
>
> On Wed, Feb 9, 2022 at 7:05 AM Barney Gale  wrote:
>
>> Over the last couple of years I've been tidying up the pathlib internals,
>> with a view towards adding an AbstractPath class to the hierarchy. Users
>> would be able to subclass AbstractPath to implement other kinds of
>> filesystems: s3, google cloud storage, pandas, ftp, git, zip and tar files,
>> etc. By implementing some abstract methods (stat(), iterdir(), open(), etc)
>> they'd benefit from a number of derived methods (is_dir(), glob(),
>> read_text(), etc). There's already a healthy ecosystem of PyPI packages
>> attempting this, but there's presently no officially-supported route.
>>
>> I've now submitted a PR that adds an initial underscore-prefixed
>> implementation of this class:
>> https://github.com/python/cpython/pull/31085. The implementation is
>> simple: wherever Path calls functions in os, io, pwd, etc, AbstractPath
>> instead raises NotImplementedError. The Path class becomes an
>> implementation of AbstractPath.
>>
>> These methods directly raise NotImplementedError: cwd(), stat(),
>> iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(),
>> touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(),
>> chmod(), unlink(), rmdir()
>>
>> These methods call through to the above methods: absolute(), lstat(),
>> exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(),
>> is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(),
>> glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(),
>> lchmod(), link_to()
>>
>> Some methods aren't applicable to some kinds of filesystems, e.g. zip
>> files don't support symlinks, working directories or home directories. In
>> these cases I think it's reasonable to raise NotImplementedError. Indeed,
>> pathlib.Path methods already raise NotImplementedError when certain local
>> filesystem features aren't available (readlink(), group(), etc).
>>
>> If any readers of this list have previously tried to extend pathlib to
>> other domains, or are otherwise interested in pathlib development, please
>> could you let me know what you think of the proposed API?
>>
>> Many thanks
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/JB7QGDNI2CNXFX7LQQ2X2WPOZ7DWVNQL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FMAN7TQA7LU4PYWW7NKA54ZWNWC6ARMU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

[Barney Gale]

On Thu, 10 Feb 2022 at 21:45, Brett Cannon  wrote:

>
>
> On Wed, Feb 9, 2022 at 11:59 AM Barney Gale  wrote:
>
>> Penny for your thoughts on those questions, Brett? Protocols are new to
>> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
>> read now.
>>
>
> Protocols would let folks rely on a common Path object API w/o having to
> require the object come from pathlib itself or explicitly subclass
> something (which I admit would be rare, but there's no reason to
> artificially constrain this either). Now maybe this is too broad of an API
> for people to care, but since protocols are also ABCs it doesn't inherently
> make things worse, either. So I would say subclassing Protocol makes sense
> while still using abc.abstractmethod for methods people must implement.
>
>

Thanks Brett. My only concern there is that the protocol would be
/extensive/, encompassing all PurePath + Path methods. It's rather
impractical to write a Path-compatible class without subclassing something
from pathlib - and that impracticality is one motivation for this work! PEP
544 seems to make this point:

> Protocol classes should generally not have many method implementations,
as they describe an interface, not an implementation. Most classes have
many method implementations, making them bad protocol classes.

https://www.python.org/dev/peps/pep-0544/#make-every-class-a-protocol-by-default

For now I've made _AbstractPath inherit abc.ABC, but I'm open to consider
it further!

Barney

On Thu, 10 Feb 2022 at 21:45, Brett Cannon  wrote:

>
>
> On Wed, Feb 9, 2022 at 11:59 AM Barney Gale  wrote:
>
>> Penny for your thoughts on those questions, Brett? Protocols are new to
>> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
>> read now.
>>
>
> Protocols would let folks rely on a common Path object API w/o having to
> require the object come from pathlib itself or explicitly subclass
> something (which I admit would be rare, but there's no reason to
> artificially constrain this either). Now maybe this is too broad of an API
> for people to care, but since protocols are also ABCs it doesn't inherently
> make things worse, either. So I would say subclassing Protocol makes sense
> while still using abc.abstractmethod for methods people must implement.
>
>
>>
>> I reckon only stat(), open() and iterdir() would be essential for users
>> to implement.
>>
>
> Seems like a reasonable set to have to implement.
>
> -Brett
>
>
>>
>> On Wed, 9 Feb 2022 at 19:02, Brett Cannon  wrote:
>>
>>> One thing to discuss (and which has been brought up on the PR), is
>>> whether this should be an ABC to force people to explicitly raise
>>> `NotImplementedError`?
>>>
>>> The next question is whether any of this should be a (very wide)
>>> protocol instead of an ABC?
>>>
>>> On Wed, Feb 9, 2022 at 7:05 AM Barney Gale 
>>> wrote:
>>>
>>>> Over the last couple of years I've been tidying up the pathlib
>>>> internals, with a view towards adding an AbstractPath class to the
>>>> hierarchy. Users would be able to subclass AbstractPath to implement other
>>>> kinds of filesystems: s3, google cloud storage, pandas, ftp, git, zip and
>>>> tar files, etc. By implementing some abstract methods (stat(), iterdir(),
>>>> open(), etc) they'd benefit from a number of derived methods (is_dir(),
>>>> glob(), read_text(), etc). There's already a healthy ecosystem of PyPI
>>>> packages attempting this, but there's presently no officially-supported
>>>> route.
>>>>
>>>> I've now submitted a PR that adds an initial underscore-prefixed
>>>> implementation of this class:
>>>> https://github.com/python/cpython/pull/31085. The implementation is
>>>> simple: wherever Path calls functions in os, io, pwd, etc, AbstractPath
>>>> instead raises NotImplementedError. The Path class becomes an
>>>> implementation of AbstractPath.
>>>>
>>>> These methods directly raise NotImplementedError: cwd(), stat(),
>>>> iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(),
>>>> touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(),
>>>> chmod(), unlink(), rmdir()
>>>>
>>>> These methods call through to the above methods: absolute(), lstat(),
>>>> exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(),
>>>> is_char_device(), is_fifo(), is_socket(), home(

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Barney Gale]

On Mon, 28 Mar 2022 at 20:37, Steve Dower  wrote:

> email doesn't fix bugs; maintainers fix bugs. Please let us know
> *publicly* if you want to become the maintainer for a stdlib module and
> then we can support them, but if nobody is willing/able/ready to care
> for them it's irresponsible for us to keep shipping them to users.


I'd like to become a maintainer for the pathlib module, if possible. I know
the code and tests inside-out, and I've been wrestling the internals for
past few Python releases. I check the bugs/PRs at least every week and help
wherever I can.

I can also look after urllib if it would help. I have much less experience
with that module vs pathlib, so I'll need to spend some time familiarizing
myself with the code and the outstanding bug reports. But I do have plenty
of experience with networking, HTTP, URLs, etc :-). I'll spend some time
reading the bug tracker to start.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BRIL545G5KMWYJRJ327YPFOTO4IJONMP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Barney Gale]

On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou  wrote:

> On Wed, 30 Mar 2022 12:03:58 +0100
> Steve Dower  wrote:
> > On 30Mar2022 1124, Barney Gale wrote:
> > > I'd like to become a maintainer for the pathlib module, if possible. I
> > > know the code and tests inside-out, and I've been wrestling the
> > > internals for past few Python releases. I check the bugs/PRs at least
> > > every week and help wherever I can.
> >
> > Antoine is still active, so if he's fine with that, I'm also supportive.
> > You're certainly familiar enough with that module.
>
> I'm entirely supportive. Huge thank you for working on pathlib!
>

Thank you Antoine, Steve. It's humbling to stand on your shoulders and
thrilling to give back to Python. If I'm successful in my application I'll
do my best to take good care of pathlib and hopefully urllib too.

These batteries ain't dead yet! :D

Best,

Barney
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RWVLBPUYNCLCJUYKFR2GWU3V5IT55UCG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Raw strings ending with a backslash

[Barney Gale]

Personally I'd expect these two lines to do the same thing, whatever that
thing is:

path = 'C:\'
path = ('C:\')

Barney

On Sat, 28 May 2022 at 12:59, Damian Shaw 
wrote:

> That PR seems to make \' and \" not special in general right?
>
> I think this is a more limited proposal, to only change the behavior when
> \ is at the end of a string, so the only behavior difference would never
> receiving the error "SyntaxError: EOL while scanning string literal"
>
> In which case there should be no backwards compatibility issue.
>
> Damian
>
> On Sat, May 28, 2022 at 12:20 PM Serhiy Storchaka 
> wrote:
>
>> 28.05.22 12:22, Steven D'Aprano пише:
>> > Now that we have a new parser for CPython, can we fix the old gotcha
>> > that raw strings cannot end in a backslash?
>> >
>> > Its an FAQ and has come up again on the bug tracker.
>> >
>> > https://docs.python.org/3/faq/design.html#id26
>> >
>> > https://github.com/python/cpython/issues/93314
>>
>> I do not think that we can allow this, and it is not related to parser.
>>
>> Few years ago I experimented with such change:
>> https://github.com/python/cpython/pull/15217
>>
>> You can see that it breaks even some stdlib code, and it will definitely
>> break many third-party packages and examples. Technically we can do
>> this, but the benefit is small in comparison with the cost.
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/WWWRFQK4AG52GD3L6WT6QLRGTY2VQRQ2/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/O3STZ54BRQ3T352PIMNEZWCRBGP6FE2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JWB74TLU5MKSYKCEW52AYYA7MHI2EENU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Barney Gale]

Perspective from a minor Python contributor:

The only thing worse than email or Discourse is email AND Discourse.
Fragmented communities are a nightmare. I don't want to post to multiple
places in order to reach the devs. Its hard enough to build consensus
already. The relative strengths of email vs discourse pale in comparison to
the dangers of fragmentation IMO.

I prefer mailing lists personally, but theyve been losing out to web forums
for 20 years now. In my view, switching solely to Discourse would help
ensure the vitality of the Python community for years to come.

Barney


On Sat, 3 Dec 2022, 21:31 Baptiste Carvello, <
devel2...@baptiste-carvello.net> wrote:

> Le 02/12/2022 à 18:49, Brett Cannon a écrit :
> >
> > Since we are promoting/pushing folks to use discuss.python.org
>
> Until now I've seen more "pushing" (with sticks) than "promoting" (with
> carrots).
>
> Since august I've been looking for a way to follow the discussions on
> discourse without using the heavy and annoying web interface, or
> building a whole stack of filters on my side. It's annoyingly close to
> working with RSS: "posts.rss" would just need to keep entries for a
> longer time, and include category information.
>
> I regret that there seems to be zero interest in fixing those last
> glitches and making RSS really work.
>
> >  it means this mailing list starts to feel
> > like more of a burden/excess.
>
> The "burden" of keeping one additional list on an existing platform is
> moderate. Nobody would be forced to read it, but interesting ideas would
> surely be copied over to discourse at some point.
>
> All the death clamors are way premature, and either relate to the
> "sticks" tactics, or to the usual intolerance of "modern tools" converts.


> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/UT5T4PZ6KEB7EQXLK3ZE6ZK2U6S37AKT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D3HCWJF7NDCANFMGPSNTP4S64RECF4XO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Barney Gale]

Oh brilliant. I'll unsubscribe from this list then. It sounds like the only
people using it will be those folks who think their tooling preferences are
more important than creating a joined-up Python community; I can survive
without their input.


On Sun, 4 Dec 2022, 19:53 Baptiste Carvello, <
devel2...@baptiste-carvello.net> wrote:

> Le 04/12/2022 à 16:55, Barney Gale a écrit :
> >
> > I don't want to post to multiple
> > places in order to reach the devs.
>
> Nobody proposed that. In order to reach the devs, you use discourse (or
> have someone else do it on your behalf).
>
> Just let the "second circle" of the community keep their mailing list,
> as this second circle just won't switch to a specialized, and quite
> unflexible tool.
>
> Yeah, without most core devs, this list might be more akin to
> python-ideas than the old python-dev. But it makes sense to keep the
> bigger following it has grown over the years.
>
> > I prefer mailing lists personally, but theyve been losing out to web
> > forums for 20 years now.
>
> This is historically untrue. In technical communities, web forums have
> been considered second class tools until some 5 years ago, with
> mailing-lists being seen as lighter, more flexible and more capable.
>

Invision Power Board, PHPBB and others supplanted mailing lists in the
early 00s. Programming communities took longer because they
disproportionately attract folks with strong and inflexible preferences.

>
> Then they began loosing to *heavily moderated* web forums because of the
> insistence on moderation. Yeah, smartphones with no capable mail client
> played a role too.
>
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/A2667BXDXYU5TXG535IUSWI6WRC35DIB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/64HZ4CAVBEMIAPHG5ZLQ66ZPQKKONY3E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Barney Gale]

On Mon, 5 Dec 2022 at 01:00, Steven D'Aprano  wrote:

> On Sun, Dec 04, 2022 at 08:20:56PM +, Barney Gale wrote:
>
> > Oh brilliant. I'll unsubscribe from this list then. It sounds like the
> only
> > people using it will be those folks who think their tooling preferences
> are
> > more important than creating a joined-up Python community; I can survive
> > without their input.
>
> My, what a hot take you have there.
>
> Did you consider that we already had "a joined-up Python community"
> until a subset of people decided to split off to use Discuss to satisfy
> *their* tooling preferences?
>

I did; I think it was a mistake to start discourse without a plan for
shutting down this mailing list.

Two wrongs don't make a right, though.


>
> https://www.youtube.com/watch?v=QhaY1hRDYBg
>
> --
> Steve
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GWMRXIWM3FNN2ACUWP3XZFMTGBXIOCU5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] pathlib.Path: inconsistent symlink_to() and link_to()

[Barney Gale]

Hi,

Pathlib's symlink_to() and link_to() methods have different argument
orders, so:

a.symlink_to(b)  # Creates a symlink from A to B
a.link_to(b)  # Creates a hard link from B to A

I don't think link_to() was intended to be implemented this way, as the
docs say "Create a hard link pointing to a path named target.". It's also
inconsistent with everything else in pathlib, most obviously symlink_to().

Bug report here: https://bugs.python.org/issue39291

This /really/ irks me. Apparently it's too late to fix link_to(), so I'd
like to suggest we add a new hardlink_to() method that matches the
symlink_to() argument order. link_to() then becomes deprecated/undocumented.

Any thoughts?

Barney
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7QPLYW36ZK6QTW4SV4FI6C343KYWCPAT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Barney Gale]

My 2c on the naming:

'start' and 'end' in 'startswith' and 'endswith' are verbs, whereas we're
looking for a noun if we want to cut/strip/trim a string. You can use
'start' and 'end' as nouns for this case but 'prefix' and 'suffix' seems a
more obvious choice in English to me.

Pathlib has `with_suffix()` and `with_name()`, which would give us
something like `without_prefix()` or `without_suffix()` in this case.

I think the name "strip", and the default (no-argument) behaviour of
stripping whitespace implies that the method is used to strip something
down to its bare essentials, like stripping a bed of its covers. Usually
you use strip() to remove whitespace and get to the real important data. I
don't think such an implication holds for removing a *specific*
prefix/suffix.

I also don't much like "strip" as the semantics are quite different - if
i'm understanding correctly, we're removing a *single* instance of a
*single* *multi-character* string. A verb like "trim" or "cut" seems
appropriate to highlight that difference.

Barney



On Fri, 20 Mar 2020 at 18:59, Dennis Sweeney 
wrote:

> Browser Link: https://www.python.org/dev/peps/pep-0616/
>
> PEP: 616
> Title: String methods to remove prefixes and suffixes
> Author: Dennis Sweeney 
> Sponsor: Eric V. Smith 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 19-Mar-2020
> Python-Version: 3.9
> Post-History: 30-Aug-2002
>
>
> Abstract
> 
>
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.  In
> particular, the methods would be added to Unicode ``str`` objects,
> binary ``bytes`` and ``bytearray`` objects, and
> ``collections.UserString``.
>
> If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
> ``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
> been removed.  If ``s`` does not have ``pre`` as a prefix, an
> unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
> is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.
>
> The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
> roughly equivalent to
> ``s[:-len(suf)] if suf and s.endswith(suf) else s``.
>
>
> Rationale
> =
>
> There have been repeated issues [#confusion]_ on the Bug Tracker
> and StackOverflow related to user confusion about the existing
> ``str.lstrip`` and ``str.rstrip`` methods.  These users are typically
> expecting the behavior of ``cutprefix`` and ``cutsuffix``, but they
> are surprised that the parameter for ``lstrip`` is interpreted as a
> set of characters, not a substring.  This repeated issue is evidence
> that these methods are useful, and the new methods allow a cleaner
> redirection of users to the desired behavior.
>
> As another testimonial for the usefulness of these methods, several
> users on Python-Ideas [#pyid]_ reported frequently including similar
> functions in their own code for productivity.  The implementation
> often contained subtle mistakes regarding the handling of the empty
> string (see `Specification`_).
>
>
> Specification
> =
>
> The builtin ``str`` class will gain two new methods with roughly the
> following behavior::
>
> def cutprefix(self: str, pre: str, /) -> str:
> if self.startswith(pre):
> return self[len(pre):]
> return self[:]
>
> def cutsuffix(self: str, suf: str, /) -> str:
> if suf and self.endswith(suf):
> return self[:-len(suf)]
> return self[:]
>
> The only difference between the real implementation and the above is
> that, as with other string methods like ``replace``, the
> methods will raise a ``TypeError`` if any of ``self``, ``pre`` or
> ``suf`` is not an instace of ``str``, and will cast subclasses of
> ``str`` to builtin ``str`` objects.
>
> Note that without the check for the truthyness of ``suf``,
> ``s.cutsuffix('')`` would be mishandled and always return the empty
> string due to the unintended evaluation of ``self[:-0]``.
>
> Methods with the corresponding semantics will be added to the builtin
> ``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
> or ``bytearray`` object, then ``b.cutsuffix()`` and ``b.cutprefix()``
> will accept any bytes-like object as an argument.
>
> Note that the ``bytearray`` methods return a copy of ``self``; they do
> not operate in place.
>
> The following behavior is considered a CPython implementation detail,
> but is not guaranteed by this specification::
>
> >>> x = 'foobar' * 10**6
> >>> x.cutprefix('baz') is x is x.cutsuffix('baz')
> True
> >>> x.cutprefix('') is x is x.cutsuffix('')
> True
>
> That is, for CPython's immutable ``str`` and ``bytes`` objects, the
> methods return the original object when the affix is not found or if
> the affix is empty.  Because these types test for equality using
> shortcuts for identity and length, the following equivalent
> expressions are e

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Barney Gale]

Perhaps you could revert the original commit, then apply the same diff
again with an adjusted message? Would that strike a good balance?

Cheers,

Barney




On Thu, 2 Jul 2020 at 21:36, Henk-Jaap Wagenaar 
wrote:

> On Thu, 2 Jul 2020 at 20:33, Chris Angelico  wrote:
>
>> On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev
>>  wrote:
>> >
>> > If you are talking about rewriting the PEP8 commit, it has proven to
>> cause so much damage that this is warranted despite the inconveniences IMO.
>> >
>>
>> I think I agree. The consequences would be notable, but not untenable.
>>
>
> I disagree that this should be done. When has this been done/requested
> before for a commit message that is already merged?
>
>
>> Formal proposal: Either request a new commit message from the original
>> author, or have someone rewrite it, and we go ahead and make the
>> change.
>>
>
> -1
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DQOPEM6WVVKGB7KHV7XIEWJ5Z7MQMAHW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FTR4YOP4WD6DIOND5HXYB7A223VSXASN/
Code of Conduct: http://python.org/psf/codeofconduct/