[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: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Guido van Rossum]

On Fri, Apr 2, 2021 at 12:43 PM Brandt Bucher 
wrote:

> Mark Shannon wrote:
> > On 02/04/2021 7:19 am, Brandt Bucher wrote:
> > > I agree that self-matching classes should absolutely allow keyword
> matches. I had no idea the PEP forbade it.
> > PEP 634 allows it.
>
> PEP 634 says:
>
> > For a number of built-in types (specified below), a single positional
> subpattern is accepted which will match the entire subject; for these types
> no keyword patterns are accepted.
>
> (https://www.python.org/dev/peps/pep-0634/#class-patterns)
>

But that's not what the implementation does. It still supports keyword
patterns for these types -- and (as I've said earlier in this thread) I
think the implementation is correct.


> > Most checks are cheap though.
> > Checking for duplicates in `__match_args__` can be done at class
> creation time, and checking for duplicates in the pattern can be done at
> compile time.
>
> I assume the compile-time check only works for named keyword attributes.
> The current implementation already does this.
>
> -1 on checking `__match_args__` anywhere other than the match block itself.
>

Agreed.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/S45E7DCDXU2LTBSNYYXSIDH6CL7CVDIK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Brandt Bucher]

Mark Shannon wrote:
> On 02/04/2021 7:19 am, Brandt Bucher wrote:
> > I agree that self-matching classes should absolutely allow keyword matches. 
> > I had no idea the PEP forbade it.
> PEP 634 allows it.

PEP 634 says:

> For a number of built-in types (specified below), a single positional 
> subpattern is accepted which will match the entire subject; for these types 
> no keyword patterns are accepted.

(https://www.python.org/dev/peps/pep-0634/#class-patterns)

> Most checks are cheap though.
> Checking for duplicates in `__match_args__` can be done at class creation 
> time, and checking for duplicates in the pattern can be done at compile time.

I assume the compile-time check only works for named keyword attributes. The 
current implementation already does this.

-1 on checking `__match_args__` anywhere other than the match block itself.

Guido van Rossum wrote:
> On Fri, Apr 2, 2021 at 3:38 AM Mark Shannon m...@hotpy.org wrote:
> > Are there are any use-cases? 
> > The test-case `int(real=0+0j, imag=0-0j)` is contrived, but I'm struggling 
> > to come up with less contrived examples for any of float, list, dict, 
> > tuple, str.
> There could be a subclass that adds an attribute. That's still contrived  
> though.

I could see the case for something like `case defaultdict({"Spam": s}, 
default_factory=f)`. I certainly don't think it should be forbidden.
___
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/L2RB6WYAOSLZECG4N2JTYMAAQX3U64GA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-03-26 - 2021-04-02)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7505 ( +7)
  closed 47938 (+67)
  total  55443 (+74)

Open issues with patches: 2984 


Issues opened (53)
==

#37368: test_asyncio: test_create_server_ssl_match_failed() failed on 
https://bugs.python.org/issue37368  reopened by nascheme

#43510: PEP 597: Implemente encoding="locale" option and EncodingWarni
https://bugs.python.org/issue43510  reopened by methane

#43634: Extensions build does not respect --jobs setting
https://bugs.python.org/issue43634  opened by JustAnotherArchivist

#43635: Documentation needs to declare CalledProcessError as potential
https://bugs.python.org/issue43635  opened by jennievh

#43636: test_descr fails randomly when executed with -R :
https://bugs.python.org/issue43636  opened by pablogsal

#43638: MacOS os.statvfs() has rollover for >4TB disks at each 4TB (32
https://bugs.python.org/issue43638  opened by sanderjo

#43639: Do not raise AttributeError on instance attribute update/delet
https://bugs.python.org/issue43639  opened by maggyero

#43640: Add warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 do
https://bugs.python.org/issue43640  opened by illia-v

#43641: Update `ssl.PROTOCOL_TLSv1_2` docs since it is not the newest 
https://bugs.python.org/issue43641  opened by illia-v

#43642: ctypes.util.find_library can't find the lib on Alpine
https://bugs.python.org/issue43642  opened by An1c0de

#43643: importlib.readers.MultiplexedPath.name is not a property
https://bugs.python.org/issue43643  opened by ap--

#43646: ForwardRef name conflict during evaluation
https://bugs.python.org/issue43646  opened by tefra

#43649: time.strftime('%z') doesn't return UTC offset in the form ??HH
https://bugs.python.org/issue43649  opened by ede123

#43650: MemoryError on zip.read in shutil._unpack_zipfile
https://bugs.python.org/issue43650  opened by igorvoltaic

#43651: PEP 597: Fix EncodingWarning warnings in the Python stdlib
https://bugs.python.org/issue43651  opened by methane

#43652: Upgrade Windows tcl/tk to 8.6.11
https://bugs.python.org/issue43652  opened by terry.reedy

#43654: IDLE: Applying settings disables tab completion
https://bugs.python.org/issue43654  opened by terry.reedy

#43655: Tkinter: Not setting _NET_WM_WINDOW_TYPE on FileDialog
https://bugs.python.org/issue43655  opened by patrickmelix

#43656: StackSummary.format fails if str(value) fails
https://bugs.python.org/issue43656  opened by moi90

#43658: implementations of the deprecated load_module import loader AP
https://bugs.python.org/issue43658  opened by kale-smoothie

#43659: AIX: test_curses crashes buildbot
https://bugs.python.org/issue43659  opened by Michael.Felt

#43661: api-ms-win-core-path-l1-1.0.dll, redux of 40740 (which has sin
https://bugs.python.org/issue43661  opened by tkacvinsky

#43663: Python interpreter works abnormally after interrupting logging
https://bugs.python.org/issue43663  opened by xxm

#43664: Long computations in pdb.run() lead to segfault
https://bugs.python.org/issue43664  opened by xxm

#43666: AIX: Lib/_aix_support.py may break in a WPAR environment
https://bugs.python.org/issue43666  opened by Michael.Felt

#43667: Solaris: Fix broken Unicode encoding in non-UTF locales
https://bugs.python.org/issue43667  opened by kulikjak

#43668: Segfault with for fresh ubuntu 20.04 install
https://bugs.python.org/issue43668  opened by axel_1234

#43669: PEP 644: Require OpenSSL 1.1.1 or newer
https://bugs.python.org/issue43669  opened by christian.heimes

#43671: segfault when using tkinter + pygame for ~5 minutes
https://bugs.python.org/issue43671  opened by Pycryptor10

#43672: Raise ImportWarning when calling find_loader()
https://bugs.python.org/issue43672  opened by brett.cannon

#43676: Doctest ELLIPSIS explanation hard to follow when they're missi
https://bugs.python.org/issue43676  opened by Tim.Hatch

#43678: TypeError: get() got an unexpected keyword argument 'vars'
https://bugs.python.org/issue43678  opened by cis-muzahid

#43679: ttk.Sizegrip disappears under Windows 10 UI Scaling, with dpiA
https://bugs.python.org/issue43679  opened by msmith

#43680: Remove undocumented io.OpenWrapper and _pyio.OpenWrapper
https://bugs.python.org/issue43680  opened by vstinner

#43681: doctest forgets previous imports
https://bugs.python.org/issue43681  opened by ethan.furman

#43682: Make static methods created by @staticmethod callable
https://bugs.python.org/issue43682  opened by vstinner

#43683: Handle generator (and coroutine) state in the bytecode.
https://bugs.python.org/issue43683  opened by Mark.Shannon

#43684: Add combined opcodes
https://bugs.python.org/issue43684  opened by gvanrossum

#43686: re.match appears to hang with certain combinations of pattern 
https://bugs.python.org/issue43686  opened by alegrigoriev

#43688: [C

[Python-Dev] [RELEASE] Python 3.9.3 and 3.8.9 are now available

[Łukasz Langa]

Those are expedited security releases, recommended to all users. Get them here:

https://www.python.org/downloads/release/python-393/ 


https://www.python.org/downloads/release/python-389/ 

Security Content

bpo-43631 : high-severity CVE-2021-3449 and 
CVE-2021-3450 were published for OpenSSL, it’s been upgraded to 1.1.1k in CI, 
and macOS and Windows installers.
bpo-42988 : CVE-2021-3426: Remove the 
getfile feature of the pydoc module which could be abused to read arbitrary 
files on the disk (directory traversal vulnerability). Moreover, even source 
code of Python modules can contain sensitive data like passwords. Vulnerability 
reported by David Schwörer.
bpo-43285 : ftplib no longer trusts the IP 
address value returned from the server in response to the PASV command by 
default. This prevents a malicious FTP server from using the response to probe 
IPv4 address and port combinations on the client network. Code that requires 
the former vulnerable behavior may set a trust_server_pasv_ipv4_address 
attribute on their ftplib.FTP instances to True to re-enable it.
bpo-43439 : Add audit hooks for 
gc.get_objects(), gc.get_referrers() and gc.get_referents(). Patch by Pablo 
Galindo.
 
Release
 Calendar

Due to the security fixes, those releases are made a month sooner than planned. 
I decided to keep the release calendar intact, meaning that the last full 
regular maintenance release of Python 3.8 is still planned for May 3rd 2021, 
after which it will shift to source releases only for security bug fixes only. 
Maintenance releases for the 3.9 series will continue at regular bi-monthly 
intervals, with 3.9.3 planned for May 3rd 2021 as well.

 
What’s
 new?

The Python 3.9 series contains many new features and optimizations over 3.8. 
See the “What’s New in Python 3.9  
” document for more information 
about features included in the 3.9 series. We also have a detailed change log 
for 3.9.3  
specifically.

Detailed information about all changes made in version 3.8.9 can be found in 
its respective changelog 
.

 
We
 hope you enjoy those new releases!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
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/JQZZT5TEDHUCDWYUEC2PRVBT4RR7267F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Guido van Rossum]

On Fri, Apr 2, 2021 at 3:38 AM Mark Shannon  wrote:

> Hi Brandt,
>
> On 02/04/2021 7:19 am, Brandt Bucher wrote:
> > Guido van Rossum wrote:
> >> Well, now I have egg on my face, because the current implementation
> does reject multiple occurrences of the same identifier in __match_args__.
> We generate an error like "TypeError: C() got multiple sub-patterns for
> attribute 'a'". However, I cannot find this uniqueness requirement in PEP
> 634, so I think it was a mistake to implement it.
> >>
> >> Researching this led me to find another issue where PEP 634 and the
> implementation differ, but this time it's the other way around: PEP 634
> says about types which accept a single positional subpattern (int(x),
> str(x) etc.) "for these types no keyword patterns are accepted." Mark's
> example `case int(real=0, imag=0):` makes me think this requirement is
> wrong and I would like to amend PEP 634 to strike this requirement.
> Fortunately, this is not what is implemented. E.g. `case int(1, real=1):`
> is accepted and works, as does `case int(real=0):`.
> >>
> >> Calling out Brandt to get his opinion. And thanks to Mark for finding
> these!
> >
> > The current implementation will reject any attribute being looked up
> more than once, by position *or* keyword. It's actually a bit tricky to do,
> which is why the `MATCH_CLASS` op is such a beast... it needs to look up
> positional and keyword attributes all in one go, keeping track of
> everything it's seen and checking for duplicates.
> >
> > I believe this behavior is a holdover from PEP 622:
> >
> >> The interpreter will check that two match items are not targeting the
> same attribute, for example `Point2d(1, 2, y=3)` is an error.
> >
> > (https://www.python.org/dev/peps/pep-0622/#overlapping-sub-patterns)
> >
> > PEP 634 explicitly disallows duplicate keywords, but as far as I can
> tell it says nothing about duplicate `__match_args__` or keywords that also
> appear in `__match_args__`. It looks like an accidental omission during the
> 622 -> 634 rewrite.
> >
> > (I guess I figured that if somebody matches `Spam(foo, y=bar)`, where
> `Spam.__match_args__` is `("y",)`, that's probably a bug in the user's
> code. Ditto for `Spam(y=foo, y=bar)` and `Spam(foo, bar)` where
> `Spam.__match_args__` is `("y", "y")` But it's not a hill I'm willing to
> die on.)
>
> Repeated keywords do seem likely to be a bug.
>

Agreed. But as I sketched in a previous email I think duplicates ought to
be acceptable in __match_args__. At the very least we should align the PEP
and the implementation here, by adjusting one or the other.

Most checks are cheap though.
> Checking for duplicates in `__match_args__` can be done at class
> creation time,


Hm, what about dynamic updates to __match_args__? I've done that in the
REPL.


> and checking for duplicates in the pattern can be done at
> compile time.
>

I'd prefer not to do that check at all.


> So how about explicitly disallowing those, but not checking that the
> intersection of `__match_args__` and keywords is empty?
> We would get most of the error checking without the performance impact.
>

+1 on the latter (not checking the intersection).

>
> >
> > I agree that self-matching classes should absolutely allow keyword
> matches. I had no idea the PEP forbade it.
>
> PEP 634 allows it. PEP 653 currently forbids it, mainly for consistency
> reasons.
> The purpose of self-matching is to prevent deconstruction, so it seems
> inconsistent to allow it for keyword arguments.
>

The purpose of self-matching is user convenience. It should be seen as a
shorthand for the code fragment in PEP 634 showing how to do this for any
class.


> Are there are any use-cases?
> The test-case `int(real=0+0j, imag=0-0j)` is contrived,
> but I'm struggling to come up with less contrived examples for any of
> float, list, dict, tuple, str.
>

There could be a subclass that adds an attribute. That's still contrived
though. But if we start supporting this for *general* classes we should
allow combining it with keywords/attributes.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/EWAO6PEFCNT3AXL6IKOIPYMWT3KHD7ZL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

[Nick Coghlan]

On Wed, 31 Mar 2021 at 11:01, Barry Warsaw  wrote:
>
> Kind of :)
>
> PEP 648 would definitely allow us to deprecate the executable part of pth 
> files.  I let my own biases leak in to my response because I would like to 
> find a way to replace the sys.path feature of pth with something much more 
> auditable and discoverable.  To me that means deprecating pth files and 
> finding something better, but maybe not.

Adding pth file auditing to the output of "python -m site" should be
entirely feasible, it just hasn't been done yet.

Even if it just listed the files found, it would make them easier to
audit than they are today.

Declaring the feature impossible to audit when we haven't even really
tried to make it auditable seems premature (the existing site output
doesn't even indicate which paths in sys.path will be considered when
looking for pth files, let alone indicate which of those directories
actually contain any).

Cheers,
Nick.
___
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/L5ZDEXRTR3NJT65BHV4YLEMEYFEQGJ6M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Mark Shannon]

Hi Brandt,

On 02/04/2021 7:19 am, Brandt Bucher wrote:

Guido van Rossum wrote:

Well, now I have egg on my face, because the current implementation does reject multiple 
occurrences of the same identifier in __match_args__. We generate an error like 
"TypeError: C() got multiple sub-patterns for attribute 'a'". However, I cannot 
find this uniqueness requirement in PEP 634, so I think it was a mistake to implement it.

Researching this led me to find another issue where PEP 634 and the implementation 
differ, but this time it's the other way around: PEP 634 says about types which accept a 
single positional subpattern (int(x), str(x) etc.) "for these types no keyword 
patterns are accepted." Mark's example `case int(real=0, imag=0):` makes me think 
this requirement is wrong and I would like to amend PEP 634 to strike this requirement. 
Fortunately, this is not what is implemented. E.g. `case int(1, real=1):` is accepted and 
works, as does `case int(real=0):`.

Calling out Brandt to get his opinion. And thanks to Mark for finding these!


The current implementation will reject any attribute being looked up more than 
once, by position *or* keyword. It's actually a bit tricky to do, which is why 
the `MATCH_CLASS` op is such a beast... it needs to look up positional and 
keyword attributes all in one go, keeping track of everything it's seen and 
checking for duplicates.

I believe this behavior is a holdover from PEP 622:


The interpreter will check that two match items are not targeting the same 
attribute, for example `Point2d(1, 2, y=3)` is an error.


(https://www.python.org/dev/peps/pep-0622/#overlapping-sub-patterns)

PEP 634 explicitly disallows duplicate keywords, but as far as I can tell it says 
nothing about duplicate `__match_args__` or keywords that also appear in 
`__match_args__`. It looks like an accidental omission during the 622 -> 634 
rewrite.

(I guess I figured that if somebody matches `Spam(foo, y=bar)`, where `Spam.__match_args__` is 
`("y",)`, that's probably a bug in the user's code. Ditto for `Spam(y=foo, y=bar)` and `Spam(foo, 
bar)` where `Spam.__match_args__` is `("y", "y")` But it's not a hill I'm willing to die 
on.)


Repeated keywords do seem likely to be a bug.
Most checks are cheap though.
Checking for duplicates in `__match_args__` can be done at class 
creation time, and checking for duplicates in the pattern can be done at 
compile time.


So how about explicitly disallowing those, but not checking that the 
intersection of `__match_args__` and keywords is empty?

We would get most of the error checking without the performance impact.



I agree that self-matching classes should absolutely allow keyword matches. I 
had no idea the PEP forbade it.


PEP 634 allows it. PEP 653 currently forbids it, mainly for consistency 
reasons.
The purpose of self-matching is to prevent deconstruction, so it seems 
inconsistent to allow it for keyword arguments.


Are there are any use-cases?
The test-case `int(real=0+0j, imag=0-0j)` is contrived,
but I'm struggling to come up with less contrived examples for any of 
float, list, dict, tuple, str.


Cheers,
Mark.
___
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/L73HXM3QZGJWVPTYRUNF4JZ2ETAMJSGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Mark Shannon]

Hi Guido,

On 02/04/2021 2:38 am, Guido van Rossum wrote:
On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon > wrote:


On 31/03/2021 9:53 pm, Guido van Rossum wrote:
 > On Wed, Mar 31, 2021 at 12:08 PM Mark Shannon mailto:m...@hotpy.org>
 > >> wrote:

[snip]

 >     Apart from that, I think the semantics are so similar once
you've added
 >     __match_seq__/__match_map__  to PEP 634 that is hard to
 >     claim one is better than the other.
 >     My (unfinished) implementation of PEP 653 makes almost no
changes to
 >     the test suite.
 >
 > I'd like to see where those differences are -- then we can talk
about
 > which is better. :-)

Almost all the changes come from requiring __match_args__ to be a tuple
of unique strings.


Ah, *unique* strings. Not sure I care about that. Explicitly checking 
for that seems extra work, and I don't see anything semantically suspect 
in allowing that.


Checking for uniqueness is almost free because __match_args__ is a 
tuple, and therefore immutable, so the check can be done at class 
creation time.




The only other change is that

case int(real=0+0j, imag=0-0j):

fails to match 0, because `int` is `MATCH_SELF` so won't match
attributes.


Oh, but that would be a problem. The intention wasn't that "self" mode 
prevents keyword/attribute matches. (FWIW real and imag should 
attributes should not be complex numbers, so that testcase is weird, but 
it should work.)


I thought matching `int(real=0+0j, imag=0-0j)` was a bit weird too.

The change required to make it work is trivial, but the code seems more 
consistent if `int(real=0+0j, imag=0-0j)` is disallowed, which is why I 
went for that.






https://github.com/python/cpython/compare/master...markshannon:pep-653-implementation?expand=1#diff-490b4f3b911cb4ca281e9ca6ff814bc10d331f0421f6c6971b08d9f29020620b





--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/ 


___
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/2ACKZY2J7OVP4WELBIFLLGR7343AEQA7/
Code of Conduct: http://python.org/psf/codeofconduct/