and
retain the release announcements?
Kind regards,
Steve
PS: Your mail triggered a visit to https://www.python.org/community/lists/
- it seems it could use some updates. For example,
comp.lang.python-announce is a news URL, which in this day and age will
baffle most visitors! At the very least
Sounds like you might want the "Python Help" group on https;//
discuss.python.org - the dev conversation migrated there quite a while ago
now, so thighs channel is more or less announcements only.
Good luck with your project!
Kind regards,
Steve
On Thu, 5 Oct 2023 at 16:07, Guent
at you are
managing to approach the same level of performance!
Kind regards,
Steve
On Wed, 2 Aug 2023 at 18:26, Christian Tismer-Sperling
wrote:
> On 02.08.23 18:30, Paul Moore wrote:
> > On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull
> > > <mailto:turnbull.stephen...@u.
.c right now (for py.exe).
Native debuggers usually hook process creation, so they should attach
immediately with no risk of missing anything.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-de
days. You'll likely find more help and
discussion over there.
Cheers,
Steve
On 3/13/2023 3:25 PM, Rokas Kupstys wrote:
Hello!
I am dropping this mail to bring up an issue which cost me three good
evenings of time. Now that i figured it out i believe it is quite a
serious usability pro
it
pieces (such as the headers and libs files), but the embeddable package
is one you can include straight into your project and redistribute. The
binaries are the same, it's just laid out differently.
And yes, discuss.python.org is the best place to ask these days.
#x27;ve missed your point?
Kind regards,
Steve
On Wed, Dec 21, 2022 at 4:15 PM wrote:
> Hello folks, I am Chihiro, a.k.a. Frodo821, and this is my first post to
> this group.
>
> I searched for a way to annotate both class variables and instance
> variables with different types and
'll work for you, that's great. Nobody else should ever
think they're doing the "right thing".
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
h
I don't remember it being mentioned, but much of the traffic recently
migrated from this list to https://discuss.python.org/c/core-dev/23, which
you may wish to keep in touch with.
Kind regards,
Steve
On Tue, Oct 25, 2022 at 7:53 AM Juan Cristóbal Quesada <
rainonthescarecrow
you might also be able to use
PYTHONPYCACHEPREFIX to reference a local directory and avoid issues that
way.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.py
ge specification" from
"Typing specification" would be helpful. (Packaging is already separate,
but doesn't appear in release announcements anyway.)
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe sen
rsions, or
having to set them before knowing what version is being used, seems more
complicated.
Cheers,
Steve
On 5/30/2022 8:26 PM, Brett Cannon wrote:
We discussed having leading underscores for this API tier, and it was decided
that a leading underscore was preferred.
This did start a
On 5/14/2022 8:37 PM, Terry Reedy wrote:
On 5/14/2022 12:40 AM, Guido van Rossum wrote:
Probably "Edit with IDLE" should be changed. I have no idea where that
is defined.
I presume somewhere in PCBuild. Steve Dower knows and is in charge of
the Windows installer.
FTR, the beh
s or tools. There's nothing wrong with
setuptools's functionality, merely the fact that it isn't part of the
CPython repository and we don't like relying on third-party repositories
for a CPython build/test.
Cheers,
Steve
___
Python-
scattered around PC, PCbuild and Tools/msi. Easier to just remove it
from Lib.
Cheers,
Steve
On 5/10/2022 9:24 PM, Victor Stinner wrote:
On Tue, May 10, 2022 at 6:16 PM Steve Dower wrote:
I agree. The internal tools that use it are all in our Tools directory,
so we can move distutils there and
ly on their copy being the "main" one.
Cheers,
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 arc
seful enough, but it could also serve as a deprecation
warning without necessarily putting a timeline on it (and also as
advertising for the new option).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
there. Then the test suite can check whether it was built or not.
Cheers,
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
he biggest issue I see is that the obvious command line options for
"import site" are already used to imply "do not import site". But then,
-P isn't obvious either. Maybe an -X option would suffice?
Cheers,
Steve
___
Python-Dev m
On 4/8/2022 12:51 PM, Daniel Pope wrote:
On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
I've read the rest of the thread so far, and agree strongly that we
can't do this at the language/runtime level.
You mean the hoisting, right?
I don't see any reason why an import exp
7;t need the runtime to do anything differently if the module
isn't really going to be used at that point.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
On 4/5/2022 11:52 PM, Victor Stinner wrote:
On Fri, Apr 1, 2022 at 12:36 PM Steve Dower wrote:
I don't see any additional discussion on the bug, and the prevailing
opinion from actual users of this API is that it probably shouldn't
change,
From what I understood my change basi
ators are redundant in the second example, and without them (thanks to
the parentheses) the literals will be concatenated at compile time. I often
use
(code of some sort)'''\
SELECT foo
FROM bar
WHERE baz = %s"""
to ensure the multiline string literal is correctly alig
On 02Apr2022 0925, Paul Moore wrote:
On Sat, 2 Apr 2022 at 02:30, Christopher Barker wrote:
On Fri, Apr 1, 2022 at 4:06 AM Steve Dower wrote:
The main difference is that 'immutables' offers you a stable/versioned
interface to use it, while the one that's in CPython
change it was an important compromise.)
There are plenty of other things in this same category, and because we
want to keep things as stable as possible while also improving
performance and reliability, we have to keep pretty tight limits on what
we promise will remain stable.
ld help to have outside perspective on this potential change.)
Cheers,
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/
Mess
them well.
Kind regards,
Steve
On Wed, Mar 30, 2022 at 5:24 PM Christopher Barker
wrote:
> > I personally would love for a typing.python.org or equivalent
> subsection of docs.python.org to exist.
>
> +1
>
> There’s a wrinkle here, however. The type specs are Python, bu
tic linking of the Python DLL. Easy enough
things to work around, but they probably need to be explicitly
documented as well if we're going to document public APIs as requiring
Py_BUILD_CORE (and I don't want to have to document that kind of stuff).
Cheers,
Steve
__
On 30Mar2022 1132, Baptiste Carvello wrote:
Le 28/03/2022 à 18:44, Steve Dower a écrit :
I think to most people "batteries included" doesn't necessarily mean
"standard library," with all that implies. It just means "it came with
the first thing that I instal
ould
urlparse("http://[::1]spam:80";) raise? - I have literally no idea :) ),
but feel free to nosy me on issues you think you've figured out and I
can help confirm your logic and do merges. Or if another core dev has
been helping you, keep nosying them.
Cheers,
Steve
want to state explicit support for either keeping the
APIs public and slightly-flexible, or making them internal but stable.
(Public and stable won't work at all for us, and normal internal won't
work at all for you.)
Cheers,
Steve
___
P
On 3/28/2022 7:26 PM, Paul Moore wrote:
To be honest, I feel like I'm just reiterating stuff I've said before
here, and I think the same is true of the points I'm responding to. Is
there actually any new development here, or is it just a repeat of the
same positions people have expressed in the p
ot even care that the batteries just came in the same
package and aren't actually an integral part of the core product.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.or
Time for a __legacy__ package?
Kind regards,
Steve
On Sun, Mar 27, 2022 at 7:06 PM Paul Moore wrote:
> On Sun, 27 Mar 2022 at 17:11, Christopher Barker
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there,
On 3/22/2022 11:28 PM, Victor Stinner wrote:
On Tue, Mar 22, 2022 at 7:33 PM Steve Dower wrote:
After a normal deprecation period, yes?
There is no backward compatibility warranty and no deprecation process
for private APIs.
And yet you're asking the question, which means you know
default because of reliability, but that was a few
years back so maybe they fixed it. So it's likely only being used by the
project that requested it, though I don't think that's enough to justify
skipping normal deprecation.
Cheers,
Steve
_
ome a language-wide backwards
compatibility break, even if it perhaps would've been better to have had
the restriction from the start.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@
We're still working on it. Hopefully it will be today, but we have had
other issues arise that have delayed things by a few days (including new
critical OpenSSL fixes that were just released yesterday).
Cheers,
Steve
On 15Mar2022 1743, Prasad, PCRaghavendra wrote:
Hi Team,
Can so
r bugs are fixed. If
we're going to specify anything about MSVC, I'd prefer it was the v142
label rather than the Visual Studio version (though we can include the
latter as a convenience for the reader, and hopefully clearly enough
that people stop filing bug reports about it
ns about the
VS version for building CPython due to how the wiki and devguide mention
it).
I'm just trying to make sure we don't add more of these, by ensuring
that we properly scope things. In this case *CPython requires IEEE 754
flo
x27;s
the compiler features that seem to have less coverage.
Cheers,
Steve
[1]:
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
ing a brand new language for it. The more
"it's-only-Python-if-it-has-X" restrictions we have, the less appealing
we become.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
e last
30+ years is eventually going to be found to be exploitable. I'd be
quite happy to say "Python gives you what your OS gives you; update the
OS for fixes".
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python
On 2/5/2022 4:09 PM, Guido van Rossum wrote:
On Sat, Feb 5, 2022 at 5:18 AM Steve Dower <mailto:steve.do...@python.org>> wrote:
The gap this has with what I'd like to see is that it will only work
for
compile-time strings. If instead it could work for an arb
ps I'll put something together that does what I'd like and give
us concrete things to discuss.
(Is there a requirement that an Id only contain ASCII characters (i.e.,
7-bit)?)
I don't think it's unreasonable to require that for these inter
ct then we aren't on
the hook for the allocations.
Cheers,
Steve
[1]: https://devblogs.microsoft.com/oldnewthing/20160615-00/?p=93675
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
orm-specific tags in extension modules. These do not support
combining tags as in wheels (and unfortunately do not match wheel tags
at all), but do allow you to have version/platform-specific
.pyd/.dylib/.so files in a single wheel. Again, it's just that none of
the current b
On 1/28/2022 5:15 PM, Barry Warsaw wrote:
On Jan 28, 2022, at 09:00, Steve Dower wrote:
Does HPy have any clear guidance or assistance for their users to keep it up to
date?
I'm concerned that if we simply substitute "support the C API for everyone" with
"support
to manage it okay. I can't remember the last compat issue I
had there that wasn't on our (C-API) side.
Thoughts?
Cheers,
Steve
On 1/28/2022 4:50 PM, Victor Stinner wrote:
Wait, where is the HPy project in that plan? :-) The HPy project
(brand new C API) is a good solution for the long t
There's no
reliable way to detect what's displaying console output, and while many
now support ANSI colours, we can't be assured of it.
Omitting the line of ^ where over x% (75%? 90%?) of characters on the
line would be marked would be fi
rd with the changes, or we admit we don't really need them. With
this amount of time before the release, we can't blame downstream users
for reverting it.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
ler but it's the linker that does most of the
optimisation. Attaching to a running process is what I normally do.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://ma
On Tue, Jan 11, 2022 at 6:24 PM Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format
age during beta for it to be worthwhile, though we
still have the problem of knock-on effects (where e.g. until NumPy
works, nothing that depends on it can even begin testing).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubs
all means, use this tool for checking stuff. But it's not a
substitute for justifying every incompatible change in its own right.
/rant
Cheers,
Steve
On 12/2/2021 11:44 PM, Victor Stinner wrote:
Hi,
I wrote two scripts based on the work of INADA-san's work to (1)
download the so
On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano wrote:
> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> [...]
> Aside: I'm a little disappointed in the way the typing ecosystem has
> developed. What I understood was that we'd get type inference like ML or
> Haskell use, so we would
grams and libraries being annotated, in exchange
for being much lighter on memory use and preprocessing. But it should
stay out of your way on unannotated code if you haven't enabled its more
strict modes.
Cheers,
Steve
___
Python-Dev mailing li
ic discourse on the topics. And this kind of reiteration is easier
when our official documents (PEPs, etc.) state it explicitly.
Cheers,
Steve
[1]: Okay, I will call out the Python Bytes podcast - which I've been on
a couple of times - as one that regularly opines on topics based on very
l
e and the
design or programming languages. It's interesting that the egalitarian wish
to allow use of native "alphabetics" has turned out to be such a viper's
nest.
Particular thanks to Stephen J. Turnbull for his thoughtful and
well-informed contribution above.
Kind regards,
pproach to
asynchronous networking, but I think it's safe to say that world has moved
on in 20 years.
Kind regards,
Steve
On Wed, Nov 17, 2021 at 6:13 AM Kyle Stanley wrote:
> I think it would be fine to wait just one release, until 3.12. Makes no
> substantial maintenance difference and m
Over at
https://discuss.python.org/t/towards-standardizing-cross-compiling/10357/ about
the *only* thing we could agree on is needing a static, cross-platform
way to read config values from a Python build (essentially "python -m
sysconfig" without being able to run Pyth
ed to a rich DBModel subclass that *knows* it is empty.
---
So to summarise my core concern - allowing an API designer to "just use
None" is a cop out, and it lets people write lazy/bad APIs rather than
coming up with good ones.
Cheers,
Steve
a lot of time arguing against those that I believe will not.
Cheers,
Steve
On 10/15/2021 3:08 AM, Doug Swarin wrote:
Steven D'Aprano wrote:
Hello Doug,
On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
I believe strong and valid arguments can be made about the use of None
, virtually any alternative is going to be
more readable.
So enjoy bikeshedding, everyone :) Please don't break any of our code.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
, and "except * E" looks like a binary operator
and/or grit on the screen.
Cheers,
Steve
[1]: Meaning to "give it a different meaning in particular context", not
_literally_ modify in any permanent sense.
___
Python-Dev mai
quot; option is totally
fine (and we'd add one to build.bat for this), but I still think it
needs to be discoverable later whether the frozen modules build option
was used or not, independent of other build options.
Cheers,
Steve
___
Python-Dev m
e? Would that defeat the performance improvement of
freezing? Is it just a terrible idea?
The filesystem access is what hurts the most, so yeah, that check won't
even be considered here without a manual opt-in (which is the option
Eric is dis
nt with #2, there's no reliable way to detect whether
profile-guided optimisations were used on all CPython builds, which
means there'd be no reliable way to detect whether frozen modules are
going to be enabled by default or not. Adding a separate option handles
this case.
to break any existing code, so
safe enough to enable if we can.
Agreed with Eric on the rest.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
I understood that _iterables_ are required to have an __iter__ method, not
iterators.
Therefore, are we simply discussing whether all iterators should be
iterable? At the moment the CPython implementation does't require that
AFAIK.
regards
Steve
On Tue, Sep 14, 2021 at 8:39 PM Guido van R
On 9/13/2021 8:12 PM, Ethan Furman wrote:
On 9/13/21 9:03 AM, Steve Dower wrote:
> You *are* allowed to put some (brief) details in the abstract. No
need to avoid spoilers ;)
>
> As it stands, "it is time" on its own is a really bad reason to
change anything. So you&
t, and this one does not, so I stopped. (Might come back later
when I'm not trying to catch up on my weekend's email though.)
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
I suspect it's the same motivation that makes us comment out a block of
code rather than deleting it, even though we know the VCS will let us
retirive it whenever we want. If I'm wrong it won't be fatal. Or surprising
;-)
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:53 PM Eric
You forgot:
5. When I just don't damned well feel like it.
Kind regards,
Steve
On Wed, Aug 25, 2021 at 8:25 PM Brett Cannon wrote:
> I just wanted to apologize for any angst or noise my replies to Marco
> caused folks. I should have known that correcting Marco on how to address
Your inflated sense of your own significance is unfortunate, since it
appears to prohibit you from considering the possibility you might have
made a rather silly mistake here, and one which is calculated to move you
further away from your stated goals.
Kind regards,
Steve
On Tue, Aug 17, 2021
hey may be
in email/issue archives), but since they exist, presumably they are
useful and viable _despite_ the bytecode varying between releases. This
suggests there's probably a better API we should add at the same time -
possibly some kind of unmarshalling or cloning-with-updates function?
On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings wrote:
> On 8/10/21 11:15 AM, Thomas Grainger wrote:
>
> Although the co_annoations code could intercept the NameError and replace
> return a ForwardRef object instead of the resolved name
>
>
> No, it should raise a NameError, just like any other P
On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum wrote:
> As it happens, I have a working prototype of lazy in marshaling that would
> work well for this.
>
> Nice to see you keep the time machine in working order ...
Kind regards,
Steve
__
On 7/29/2021 6:17 PM, Barry Warsaw wrote:
On Jul 29, 2021, at 05:55, Steve Dower wrote:
Maybe we should have a "Type" other than Standards Track for PEPs that are
documenting implementation designs, rather than requirements for standardisation?
Wouldn’t Informational fill
m
to implement "standard" Python, having an explicit distinction here
would be helpful.
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.
nsible.
There's nothing wrong with the randomness from the function. It'll be
using the new API under the covers. So this is an enhancement, not a
security issue, and should only target 3.11.
Cheers,
Steve
___
Python-Dev mailing list -- python-d
p somehow. They can't, and
it's a little offensive to assume that your perceptions of the project will
somehow be revelatory. You describe real problems, but these problems are
well-known to the development team and you offer no new insights
ourself in a position where you have to justify it to someone
outside of the project (e.g. using work time for open source), hopefully
any core developer you've interacted with a bit will gladly write a
short endorsement for that.
Cheers,
Steve
going to become significantly more attractive than
those two - even IronPython still lives on for embedding because it
works so well).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
seems intentional and not an error.
> >
> > Are you looking for a decorator for the whole Enum, or a way to mark
> individual *values* as masks?
>
> The decorator is for whole enum. The issue is not that some values are
> masks, but whether the absence of named bits
> cov
he importlib module's methods (but your *best* bet overall is to
run separate test suites in their own process so you can avoid the CWD
changes).
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
obvious option), and use the complex
overrides in our own automated systems.
Cheers,
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
an use any version at all to build CPython and/or extension
modules.
Our official releases are always using relatively up-to-date compilers,
but provided the compatibility is maintained on Microsoft's side,
there's no need to worry about the specific versions.
Cheers,
Steve
On
ase.
All the other situations where we want arguments with unspecified
default values can use ..., and the few cases where ... is a valid value
(semantically, for the API, not syntactically) can spend the time
figuring out a different API design.
Cheers,
Steve
_
On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano
wrote:
> Steve
> (one of the other ones)
>
We are all other Steves!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@py
ue that wouldn't also apply to any other kind of shared
sentinel.
Cheers,
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.
rly say what the default
value is, either. So in all cases I have to read the docstring in
addition to the function signature.
Is the term you're looking for?
Perhaps or ?
Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
On Thu, May 13, 2021 at 9:18 AM Mark Shannon wrote:
> Hi Terry,
>
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> >> As alway
On Fri, Apr 16, 2021 at 7:15 PM Denis Kotov wrote:
> Ethan Furman wrote:
> > On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
> > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
> > > or read some articles ... otherwise I will need to spend too many time
> providing evidenc
DEFAULT_TIMESTAMP?
Kind regards,
Steve
On Wed, Apr 14, 2021 at 8:03 PM wrote:
> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> Python-Dev mailing li
The old rule is best: be strict in what you produce and liberal i what you
accept.
Kind regards,
Steve
On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman
wrote:
> On 4/12/2021 6:34 PM, Brett Cannon wrote:
>
> Had the sentences ended at "confusing" or said something like "
On 3/17/2021 7:34 PM, Ivan Pozdeev via Python-Dev wrote:
On 17.03.2021 20:30, Steve Dower wrote:
On 3/17/2021 8:00 AM, Michał Górny wrote:
How about writing paths as bytestrings in the long term? I think this
should eliminate the necessity of knowing the correct encoding for
the filesystem
lly come around to the idea that UTF-8
is the only needed encoding, and I'm sure if it had existed when Windows
decided to support a universal character set, it would have been chosen.
But with what we have now, UTF-16-LE is not a good choice for anything
apart from compatibility with Wind
want.
Cheers,
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/
asier way to patch the location of user site packages?
I also had to do this for the Store install on Windows, and it's a
little bit of a hack... but maybe having an official recommendation
would help encourage distributors to use the mechanism?
Cheers,
Steve
___
1 - 100 of 1536 matches
Mail list logo
