[Python-Dev] Re: os.scandir bug in Windows?

[Mats Wichmann]

On 10/19/20 9:52 AM, Gregory P. Smith wrote:
> 
> 
> On Mon, Oct 19, 2020 at 6:28 AM Ivan Pozdeev via Python-Dev
> mailto:python-dev@python.org>> wrote:
> 
> 
> On 19.10.2020 14:47, Steve Dower wrote:
> > On 19Oct2020 1242, Steve Dower wrote:
> >> On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
> >>> TLDR: In os.scandir directory entries, atime is always a copy of
> mtime rather than the actual access time.
> >>
> >> Correction - os.stat() updates the access time to _now_, while
> os.scandir() returns the last access time without updating it.
> >
> > Let me correct myself first :)
> >
> > *Windows* has decided not to update file access time metadata *in
> directory entries* on reads. os.stat() always[1] looks at the file
> entry
> > metadata, while os.scandir() always looks at the directory entry
> metadata.
> 
> Is this behavior documented somewhere?
> 
> Such weirdness certaintly something that needs to be documented but
> I really don't like describing such quirks that are out of our control
> and may be subject to change in Python documentation. So we should
> only consider doing so if there are no other options.
> 
> 
> I'm sure this is covered in MSDN.  Linking to that if it has it in a
> concise explanation would make sense from a note in our docs.
> 
> If I'm understanding Steve correctly this is due to Windows/NTFS storing
> the access time potentially redundantly in two different places. One
> within the directory entry itself and one with the file's own metadata. 
> Those of us with a traditional posix filesystem background may raise
> eyeballs at this duplication, seeing a directory as a place that merely
> maps names to inodes with the inode structure (equiv: file entry
> metadata) being the sole source of truth.  Which ones get updated when
> and by what actions is up to the OS.
> 
> So yes, just document the "quirk" as an intended OS behavior.  This is
> one reason scandir() can return additional information on windows vs
> what it can return on posix.  The entire point of scandir() is to return
> as much as possible from the directory without triggering reads of the
> inodes/file-entry-metadata. :)
> 
> -gps

depending on atimes isn't a consistently reliable mechanism anyway,
since filesystems on Linux et. al. are allowed to be mounted so as to
not independently update access times.

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

[Python-Dev] Re: Who is target reader of tutorial?

[Mats Wichmann]

On 11/6/20 9:07 AM, Marco Sulla wrote:
I started to learn Python with the tutorial, and two things come into my 
mind:
1. The class section seems quite difficult and intimidating for a novel, 
while classes in Python are really more simple than in other OO languages


Indeed - we got some complaints about the class chapter at the 
webmas...@python.org alias a while back. The introductory section 
repeatedly mentions Modula-3 and Smalltalk, languages which more 
recently minted programmers aren't very likely to be familiar with, 
which makes it a bit of a daunting beginning - this is the one chapter 
that could really use a bit of rework, IMO.


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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Mats Wichmann]

On 11/9/20 12:46 PM, Mike Miller wrote:


On 2020-11-09 10:44, Simon Cross wrote:

That's quite subjective. Personally I prefer a more complete tutorial
which explains many details so that I don't immediately run into
fundamentals I don't understand when I start using what I've learned.
K&R was very popular, so I don't think I'm alone in this.



Indeed.  A common problem with a lot of platform documentation I've 
experienced is that tutorials are "fluff" for absolute beginners, 
complemented with terse, dense reference material for experts.  There is 
too often very little in-between to get you to the intermediate level.


That's why the current tutorial is fantastic, imho.  It doesn't skip the 
all-important middle part of the journey, and gets you to 
near-intermediate within a few hours if you've programed before.


Perhaps the first step is too high, however.  How about a new Section 0: 
Absolute beginners guide, for those new to programming?


Just 2 cents' worth, the difficulty this discussion exposes is things In 
The Wrong Place (subjective), and maybe not all of the required places 
actually complete.  I thought the following was a pretty good discussion 
of the overall problem of documenting a complex ecosystem:


https://documentation.divio.com/

If people think that model is reasonable, we sort of have most of it - 
we have Reference; HowTos and Explanations (mixed together in 
https://docs.python.org/3/howto/index.html); and Tutorial.  _Some_ 
people think the tutorial has too much stuff that belongs in the HowTos 
and Explanations buckets, and that's probably where things should be 
built up.  e.g. @raymondh has been working on the Descriptor Howto, 
which is a good example of more detailed material not getting stuffed in 
the tutorial :)


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

[Python-Dev] nanosecond stat fields, but not os.path methods ?

[Mats Wichmann]

there are stat fields now for ns precision, e.g. st_mtime now has an 
analogue st_mtime_ns.  But os.path didn't grow corresponding methods - 
there's an os.path.getmtime but not _ms. Was that intentional?  The 
wrappers in genericpath.py are trivial and arguably aren't particularly 
needed, but still curious...

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

[Python-Dev] 3.10 change (?) for __bool__

[Mats Wichmann]

Someone reported a testsuite break on stuff I work on (scons) with 
3.10a4, and it looks similar to this which appears in the changelog at


https://docs.python.org/3.10/whatsnew/changelog.html#changelog

bpo-23898: Fix inspect.classify_class_attrs() to support attributes with 
overloaded __eq__ and __bool__. Patch by Mike Bayer.


Except when I go look at that BPO issue, it's old - closed 2015.  Is 
this appearing in the 3.10 changelog in error?  Sorry - confused !!!


The test in question does indeed touch a class which overrides __bool_ 
in order to raise an exception (to say "don't do that"), and in the test 
run the (expected) exception is not raised.

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

[Python-Dev] Re: 3.10 change (?) for __bool__

[Mats Wichmann]

On 1/8/21 4:31 PM, Mats Wichmann wrote:



Someone reported a testsuite break on stuff I work on (scons) with 
3.10a4, and it looks similar to this which appears in the changelog at


https://docs.python.org/3.10/whatsnew/changelog.html#changelog

bpo-23898: Fix inspect.classify_class_attrs() to support attributes with 
overloaded __eq__ and __bool__. Patch by Mike Bayer.


Except when I go look at that BPO issue, it's old - closed 2015.  Is 
this appearing in the 3.10 changelog in error?  Sorry - confused !!!


okay, that was silly, I didn't realize the changelog was cumulative over 
many versions, so that entry was not for 3.10 at all (teach me to do 
searching in browser window, where it just flies right past any section 
headings so I miss it was for a different version :) ).


The test in question does indeed touch a class which overrides __bool_ 
in order to raise an exception (to say "don't do that"), and in the test 
run the (expected) exception is not raised.


So updated information: the test in question is checking if a class (A) 
has an attribute using a truth test, where the attribute's value is an 
instance of another class (B) and expecting that that will cause the 
__bool__ method to be called. [aside: this test is done to validate that 
a class which really doesn't want this kind of test indeed rejects it] 
That apparently no longer happens, if it's wrapped in a try block ??? 
Distilled down to simple case:


class A:
pass

class B:
def __bool__(self):
raise AttributeError("don't do that!")

a = A()
b = B()
a.b = b
# expect this to cause b.__bool__ to be called
if a.b:
print("Found it!")

and it raises the exception.  But when protected:

try:
if a.b:
pass
except AttributeError:
print("Got expected exception")
else:
print("Missed expected exception")

it won't trigger. But if I add a "real" statement in the block following 
the "if", then it's back to the pre-3.10 behavior of calling __bool__:


 try:
if a.b:
dummy = True
except AttributeError:
print("Got expected exception")
else:
print("Missed expected exception")


Any thoughts on this?
___
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/VC6VRTL7LKE4PVFQBYJW4HYJX6D6TJVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.10 change (?) for __bool__

[Mats Wichmann]

On 1/11/21 1:00 PM, Guido van Rossum wrote:
All that said (I agree it's surprising that 3.10 seems backwards 
incompatible here) I would personally not raise AttributeError but 
TypeError in the `__bool__()` method.


eh, that was just me picking a cheap something to demo it.  the program 
raises an application-specific error that I didn't feel like defining to 
keep the repro as short as possible.

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

[Python-Dev] Re: Python standardization

[Mats Wichmann]

On 2/12/21 5:19 PM, Guido van Rossum wrote:
 From talking to people who at various times have participated in a 
language standardization process, I've learned that it's not a panacea, 
it's an enormous amount of work, it doesn't guarantee a good outcome, 
and plenty of languages do just fine without it. Also, it costs real 
money. A lot. I have no interest in going that route, and I don't think 
any other core devs are interested either.


Having been through ISO standardization several times, a couple of notes.

The first time doesn't have to be particularly expensive - there's a 
route where an established organization can register to submit an 
already available standard (and I'd argue the Python language docment is 
that).  However, once you've had the one free hit, you then have to 
follow the ISO standards maintenance and development rules going 
forward. And that is comparatively expensive.


Is there value?  Every healthy project has a "three pillars" approach, 
whether stated as such or not, where there is specification, one or more 
implementations, and test. It's just that the right balance of those has 
to be determined each time (and often evolves over time, as maturity may 
change the equation).  The specification can be as formal as being 
blessed by and under control of a formal body like ISO (though it's 
still edited by practitioners), or as informal as "the comments in the 
code".  An implementation can drive the process ("reference 
implementation", where modulo bugs, the implementation determines the 
answer if something turns out to be unclear or wrong in the 
specification); or an implementation can be relatively obscure, just 
used to show "yes, we can indeed implement this".  Similarly, tests can 
be at the level of checking the implementation, or it can be as formal 
as a test suite that is administered by an accredited testing agency, 
and passing it (for a fee) is mandatory to be able to use a trademark.


With all that said: Python has all three of the pillars in place: spec, 
main implementation, several other implementations of the language, and 
a solid test suite.  Would changing the balances of those make anything 
better than it is now?  I'm not a core dev but I fail to see how.


What's the problem that is not being solved now that could be improved? 
Is it the recent fairly rate of change?



Postscript: I once participated in "standardizing" Python on a very 
limited basis.  The Linux Standard Base included a lightweight 
description of Python 2.4, with a reference to that version of the 
language spec, and a curated list of standard library modules which had 
to be provided.  The concept was that the user of any LSB-conforming 
system would know it was possible to install "LSB Python" and 
applications coded to that would then work in the expected way - the 
distributions didn't have to provide that as their main Python, just had 
to make that "known" version available.  Interesting exercise, but in 
the end I'm nearly 100% sure that the exercise added no value to the 
Python ecosystem which has done just fine for the nearly 20 years since 
that bit of work, which has since faded away into obscurity.


Cheers,

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

[Python-Dev] Re: Python 0.9.1

[Mats Wichmann]

On 2/16/21 3:44 PM, Guido van Rossum wrote:

Awesome, Skip!

Was there a date somewhere? I can't recall if this would have been the
first open source release (from just about 30 years ago, sometime in
February 1991) or some time later in the same year?


Guido van Rossum
unread,
Python 0.9.1 part 01/21
XThis is Python, an extensible interpreted programming language that 
Xcombines remarkable power with very clear syntax. X XThis is version 
0.9 (the first beta release), patchlevel

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

[Python-Dev] Re: Security releases of CPython

[Mats Wichmann]

On 2/19/21 11:55 PM, Steve Holden wrote:


The PSF needs needs sufficient money to hire a couple of people, so the
PSF can turn release management and security maintenance from unpaid
volunteers into paid fulltime jobs.


Oh, is that all? Sustainability of the PSF, as has been shown over its 
20 years of existence, is not an easy thing to achieve. It was hit by 
the financial crisis in 2008 and again by the coronavirus crisis last 
year, both things that affected all foundations.


If you plan to bring this kind of money in and rely on it, you have to 
ensure it comes from sources that can't just be switched off when 
budgets tighten. It could be done, but "easy" sounds like exaggeration 
to me. Unless your suggestions were joking, but I saw no smiley ...


Steve's comments probably need no reinforcement, but I can speak as 
someone who's been funded by fees collected from motivated companies, 
and had the tap turn off.  In my cases (more than one) they were 
consortia where the members committed a set fee yearly, and then one 
year: we've decided not to renew, from one or more... It's actually 
easier to raise funds for a one-time campaign than one that is committed 
to last for several years, in my limited experience on the fund-raising 
side.

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

[Python-Dev] Re: Speeding up CPython

[Mats Wichmann]

On 5/12/21 4:10 PM, Terry Reedy wrote:

On 5/12/2021 5:14 PM, Antoine Pitrou wrote:

On Wed, 12 May 2021 17:05:03 -0400
Terry Reedy  wrote:



Yet you always see it: new people not knowing where to start,
highly skilled contributors drowning and
intermediate contributors moving slowly


I have multiple times strongly recommended that people review issues and
PRs, and sometimes given details, but most won't or don't.


I don't know who "people" are in your sentence, but reviewing issues
and PRs generally requires a high familiarity with a project, and


Much can be done without what I think you mean by 'high familiarity'.

Bug issues:
   bpo: "On macOS with 3.8.3 I see this buggy behavior" If not enough 
info to reproduce, ask for it.  If there is, try to reproduce on lastest 
release or even better, repository build.  Sometimes, trying on a 
different OS is helpful.

   PR: make local PR branch and test whether proposed fix works.

Enhancement issues:
   bpo: if proposal is for core python or a module one has used, does 
proposal seem like an actual improvement?  enough to be worth the likely 
bother?

   PR: does the PR work as promised?  Do you like it?

PR Python code: read it.  See any possible improvements?


In addition, starting by working in other's issues and PRs will build a 
degree of familiarity with how the Python development works - what sorts 
of questions get asked, what changes to a PR tend to get asked for, etc.



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

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

[Mats Wichmann]

On 7/29/21 1:32 PM, Brett Cannon wrote:



On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon > wrote:


Hi everyone,

I would like to repeal PEP 509. We don't really have a process for
repealing a PEP. Presumably I would just write another PEP.


Yeah, it's probably a new PEP explaining why the first PEP turned out to 
not work out since it's undoing a "big" decision. Otherwise it's like 
withdrawing the PEP post-acceptance.



That would allow placing a simple tag in the original, like "Superseded 
by PEP XXX".



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

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

[Mats Wichmann]

On 12/19/21 06:46, aivazian.tig...@gmail.com wrote:
> Hello,
> 
> Being a programmer myself I realise that a report on performance degradation 
> should ideally contain a small test program that clearly reproduces the 
> problem. However, unfortunately, I do not have the time at present to isolate 
> the issue to a small test case. But the good news (or bad news, I suppose) is 
> that the problem appears to be reasonably general, namely it happens with two 
> completely different programs.
> 

Just FYI (if you didn't already know), there is long-term tracking of
performance benchmarks which you can see reflected at
https://speed.python.org.  The intent is that things not come as a
surprise, so if there indeed turns out to be a surprise underneath your
issue - and we all know benchmarking of complex workflows is quite
tricky - maybe there's a new check that will want to be added there.


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

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

[Mats Wichmann]

"When printing tracebacks, the interpreter will now point to the exact
expression that caused the error instead of just the line."

I get the motivation for better error messages, but there are scenarios
where you can't provide useful new information.  I've been lax in
getting to testing the project I work on with 3.11, but here's some spew
from one testcase (this is an intentionally triggered error - the
testcase is testing predictable behavior in the face of this error, 3.11
didn't *cause* this, as can be fairly easily seen):

Traceback (most recent call last):
  File "C:\Users\mats\Documents\github\scons\SCons\Script\Main.py", line
1403, in main
_exec_main(parser, values)
^^
  File "C:\Users\mats\Documents\github\scons\SCons\Script\Main.py", line
1366, in _exec_main
_main(parser)
^
  File "C:\Users\mats\Documents\github\scons\SCons\Script\Main.py", line
1034, in _main
SCons.Script._SConscript._SConscript(fs, script)

  File
"C:\Users\mats\Documents\github\scons\SCons\Script\SConscript.py", line
285, in _SConscript
exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
^
  File
"C:\Users\mats\AppData\Local\Temp\testcmd.16164.fpv9xt5b\SConstruct",
line 4, in 
raise InternalError('error inside')
^^^
SCons.Errors.InternalError: error inside


The grump here is all those pointy hats added absolutely zero new
information, because in each case the entire line is underlined.  So the
"benefit" of the change is the traceback went from 12 lines to 17. In
many cases tracebacks are much longer and adding lots of not-useful
lines is not a great thing.

A thought - how about omitting the underline line if the
to-be-underlined part would be the whole line?
___
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/ST3PMOO6JPOYKI2EJAAFL5X2SZL353R6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mats Wichmann]

On 1/30/22 04:45, Inada Naoki wrote:
> On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel  
> wrote:

> Some people may do "approval without review" to make their "Profile"
> page richer, because GitHub counts it as a contribution.
> Creating spam issues or pull requests can be reported as spam very
> easily. But "approve without review" is hard to be reported as spam.
> So approving random issue is the most easy way to earn contributions
> without reported as spam.

Whnever there are metrics, some will find a way to game the system to
make theirs look better - this certainly isn't limited to github, or to
tech, or in any way a recent thing.
___
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/CXMXAYP4JYNCCSDH3ISVMRZLWB7J6CPH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

[Mats Wichmann]

On 5/7/22 21:22, Pablo Galindo Salgado wrote:

> We **strongly encourage** maintainers of third-party Python projects to
> **test with 3.11** during the beta phase and report issues found to [the
> Python bug tracker](https://bugs.python.org )
> as soon as possible. 


Seems like this bit of the template needs an upgrade -> github?


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

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

[Mats Wichmann]

On 7/12/22 00:11, John Belmonte wrote:
> On 1/18/22 10:43 AM, Mats Wichmann wrote:
> 
>> A thought - how about omitting the underline line if the
>> to-be-underlined part would be the whole line?
> 
> I wasn't aware of this thread, but that's exactly what I implemented for
> 3.11.0b4.
> 
> About this thread-- I understand debating solutions, but there was at
> least an agreement here about the problem.  For visibility, it would
> have been better to open an issue than let the topic drop.  (When filing
> the issue, I was wondering "how can I be alone thinking this is a
> problem?"-- then was surprised to see the support come out for the change.)
> 
> Regards,
> --John


Just noticed this change had been made - thanks for taking care of it!!!


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

[Python-Dev] Re: Switching to Discourse

[Mats Wichmann]

On 7/21/22 11:11, Mariatta wrote:
> 
> 
> On Thu, Jul 21, 2022 at 10:05 AM Skip Montanaro
> mailto:skip.montan...@gmail.com>> wrote:
> 
> I have a perhaps stupid question. Is Discord the same as
> discuss.python.org , just by another
> name? I find the similarity in
> names a bit confusing.
> 
>  
> It's not the same. discuss.python.org  is an
> instance of Discourse.
> 
> Discord is something completely something else.
>  Indeed the similarity is confusing.


As the wag said,

"These are only two hard things in computer science, cache invalidation
and naming things".


Add in IP lawyers and I think naming may have advanced to being the hardest.

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

[Python-Dev] Re: Switching to Discourse

[Mats Wichmann]

On 7/21/22 11:16, Skip Montanaro wrote:
>> No, Discord is a different thing; it does text and voice communication
>> channels in real-time. If you're familiar with Slack, it's broadly
>> similar in purpose.
> 
> Thanks (and to the others who replied). It seems like they've tried to
> make it a game, giving me the "opportunity" to buy boosts (or
> whatever). What's up with that?

Discord has grown up in the gaming community, its use as a general chat
platform was possibly not anticipated...   as one who is not at all
affected by gamification of things (e.g. I'm utterly unmotivated by
people trying to award badges for unlocking accomplishments, etc., but I
know it's considered to work for many people) if comes off seeming
silly, but I can just ignore that part.
___
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/KCWFUROCA3PN4RQY6STUZ4I4QJZNXASL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] glob's new include_hidden parameter

[Mats Wichmann]

Just spotted that 3.11 adds an include_hidden.  At the moment a little 
confused because there's an apparent mismatch between docstring and docs.


Lib/glob.py:

If `include_hidden` is true, the patterns '*', '?', '**'  will 
match hidden

directories.


Doc/library/glob.rst:

   If *include_hidden* is true, "``**``" pattern will match hidden 
directories.


,,, with no mention of the other patterns.

Is that just an omission in the rst doc?

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

[Python-Dev] Re: glob's new include_hidden parameter

[Mats Wichmann]

On 9/12/22 19:48, Eryk Sun wrote:

On 9/12/22, Mats Wichmann  wrote:


If `include_hidden` is true, the patterns '*', '?', '**'  will
match hidden directories.


Shouldn't this explain what a "hidden directory" is? For example, a
Windows user may think this means a directory with
FILE_ATTRIBUTE_HIDDEN set, but that's not what's meant here. Also, I
think it should note that enabling include_hidden negates the earlier
claim that "files beginning with a dot (.) can only be matched by
patterns that also start with a dot". For example, glob.glob('*',
include_hidden=True) includes all of the conventionally hidden
directories and hidden files in the current directory.


sounds like a good point to me.
___
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/5T3HINWHN6UIDDRUG72EMFNZJPO4NG4S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

[Mats Wichmann]

On 10/30/19 4:20 PM, Barry Warsaw wrote:

On Oct 30, 2019, at 14:31, Łukasz Langa  wrote:


Yes. This allows for synchronizing the schedule of Python release management 
with Fedora. They've been historically very helpful in early finding 
regressions not only in core Python but also in third-party libraries, helping 
moving the community forward. It seems like a bargain to make a slight 
adjustment of our schedule to help Fedora help us make 3.9 and beyond better 
releases.


It would be really interesting for the major distros to work together, 
coordinating their archive rebuilds with the new/beta releases.  E.g. Ubuntu 
might be ahead of Fedora, or vice versa, for any particular new Python release. 
 Rebuilding the whole archive with the new version as default always uncovered 
interesting issues.  It seems like we have a great untapped resource to find 
good signals as to bugs, breakages, regressions, and other problems during the 
Python beta process.  How can that be leveraged better?


Just slightly off topic (sorry Brett), but I have past experience with 
the effort to try and sync the release cycle of something significant 
with that of major distros - and it's just too hard. (What are major 
"the major distros" anyway?  the enterprise ones are on a completely 
different cycle, and some have gone to rolling releases where there's 
really nothing to sync to). By all means, if it hurts nothing to go for 
a sync now, to take advantage of some synergies, great, but don't try 
enshrine it in a PEP as a requirement going forward, there will only be 
lots of pain as things start to skew. And they will.

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

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion

[Mats Wichmann]

On 8/5/20 10:43 AM, Dominic Davis-Foster wrote:
> Hi Carol,
> 
> I was wondering if you've been able to set up the workgroup yet? I'd 
> certainly be interested in participating the there's an opportunity.
> 
> 
> Stay safe
> 
> Dom

Indeed, I was wondering if there were any updates - I'm also interested
in participating.

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

[Python-Dev] Re: Python 4 FAQ

[Mats Wichmann]

On 9/15/20 8:54 PM, Steven D'Aprano wrote:
> There's still a lot of community angst over the possibility that 
> some hypothetical Python 4 will be like the 2/3 transition. Some people 
> even imagine that the version after 3.9 could be that transition.
> 
> I know we're not responsible for the ravings of people on social media, 
> but do you think we should do a FAQ? Something along the lines of:
> 
> - the version after 3.9 will be 3.10, and in fact it already exists;
> 
> - if there ever is a version 4, the transition from 3 to 4 will be more 
> like that from 1 to 2 rather than 2 to 3.

Seems like a good plan.

Current evidence suggests, however, that no amount of preemptive
documentation will have any impact at all on social media fueled FUD.

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

[Python-Dev] Re: unable to create PR on github

[Mats Wichmann]

On 9/22/20 1:20 AM, Antoine Pitrou wrote:
> On Mon, 21 Sep 2020 20:56:18 -0700
> Ethan Furman  wrote:
>> And even more data:
>>
>> I added a body to the PR I was originally having trouble with:
>>button stayed gray
>>
>> I went away for a while, say 5 - 10 minutes, and when I went back to 
>> that screen the button was green.  I created the PR.
> 
> Recently, I had to add a body text to create a PR (on another repo),
> otherwise the button would be grayed out.  So that seems to be the
> reason.

I've had the same with the title... github has some heuristic about when
a PR is ready to proceed with, which includes certain fields plus maybe
requirements a project may have imposed, and in what's probably a
gigabyte of hairy javascript, it appears to be confusable.

The commandline client (gh pr create ) might avoid some of that mess?

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