bout clicking 'more info'. I don't know the
status of python.org 3.x downloads.
Since Steve Dower put 3.7 on the Windows store, PSF must now be a known
publisher. Perhaps he can help make 2.7 'known'.
SmartScreen should recognize it now that it's been downloade
to go
work on that.
It's not a big ask to have one of the lower level mailing lists look at
your proposal before the council has to make an official decision. You
should *want* the mailing lists to look at your proposal. I certainly
do, because every time they do my proposals get
ort of a PEP as
sufficient to consider it from someone who's otherwise completely
unknown. There are always grey areas in any policy.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
On Tue, Mar 5, 2019 at 9:04 PM Steve Dower wrote:
> On 05Mar2019 1245, Chris Angelico wrote:
> > How much effort does it take to sponsor a PEP? I'm not a core dev, but
> > I can help someone with the work of writing and publishing. So if, in
> > that hypothetical situat
technical term *not
quite right* then we will be found out.
(A few of us core devs chatted with Al afterwards and there's no bad
blood, so don't worry about that.)
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On Thu, Mar 21, 2019 at 11:33 AM Antoine Pitrou wrote:
> [...]
>
> Most users and applications should /never/ care about the order of XML
> attributes.
>
> Regards
>
> Antoine
>
Especially as the standards specifically say that ordering has no semantic
impact.
Byte-by-byte comparison of XML is
On Fri, Mar 22, 2019 at 8:43 AM Victor Stinner wrote:
> Le ven. 22 mars 2019 à 09:16, Inada Naoki a
> écrit :
> > > > We have `socket.error` for long time.
> > >
> > > And it's perfectly fine, no?
> > >
> >
> > Yes. Waiting 10+ years to remove aliases is fine.
>
> [...]
>
> Right now, the main
point of
view. Decoupling it from Py_UNICODE is fine though, since that type will
have no meaning eventually. But the PyUnicode_*WideChar APIs are not
going away, which means that wchar_t still exists and has to have a
known size at compile time.
Cheers,
Steve
___
quot;If the implementation is hard to explain, it's a bad idea." :)
(FWIW, agree with Brett. We can simply stop using it ourselves without
breaking anyone. Of all the things in the stdlib that are hard to
maintain, this is nowhere near the top of the list.)
Cheers,
Steve
__
On 25Mar2019 0812, Martin (gzlist) wrote:
On Fri, 22 Mar 2019 at 16:12, Steve Dower wrote:
On 22Mar2019 0433, Antoine Pitrou wrote:
The question is: why would you use a array.array() with a Windows C API?
I started replying to this with a whole lot of examples, and eventually
convinced
ot;this will probably not survive to the next
major change release, even though we aren't planning to do one yet"
(much like the Py_UNICODE APIs). Ironically, PendingDeprecationWarning
seems a pretty accurate way of indicating this state.
Cheers,
Steve
___
change
isn't big enough to need its own.
(Not trying to devalue the work you've been doing so far, since it's
great! But internal changes are one thing, while updating the public,
documented interfaces deserves a more thorough process.)
Cheers,
Steve
__
we're best to put it off until PyCon at this point.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
om/zooba/cpython/tree/pep-578-3.7/)
is already getting some real use (though this will not be added to 3.7,
unless people *really* want it, so the backport is just for reference).
Cheers,
Steve
=
PEP: 578
Title: Python Runtime Audit Hooks
Version: $Revision$
Last-Modified: $Date$
Author: S
The implementation can be viewed as a PR at
https://github.com/python/cpython/pull/12613
On 28Mar2019 1535, Steve Dower wrote:
Hi all
Time is short, but I'm hoping to get PEP 578 (formerly PEP 551) into
Python 3.8. Here's the current text for review and comment before I
sub
On 29Mar2019 0334, Christian Heimes wrote:
On 28/03/2019 23.35, Steve Dower wrote:
Audit Hook
--
In order to observe actions taken by the runtime (on behalf of the
caller), an API is required to raise messages from within certain
operations. These operations are typically deep within
the functionality - offloading it to the OS just means the OS is
going to suffer the performance penalty, so it really is just moving the
blame elsewhere. I dislike playing that game.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.
r the incredibly diverse user base we have.
This PEP is explicitly only about the API changes.
Cheers,
Steve
On 29Mar2019 1044, Ivan Pozdeev via Python-Dev wrote:
Like in the mktemp thread earlier, I would request a threat model (what
use cases are supposed to be protected (in this case, by repo
On 29Mar2019 1218, Christian Heimes wrote:
On 28/03/2019 23.35, Steve Dower wrote:
The ``importlib.util.open_for_import()`` function is a drop-in
replacement for ``open(str(pathlike), 'rb')``. Its default behaviour is
to open a file for raw, binary access. To change the behaviour a n
her).
To see the other failed PR builds, the full list is at
https://dev.azure.com/Python/cpython/_build?definitionId=9 and most of
the ones from today have failed because of whatever is causing it.
Any help?
Thanks,
Steve
___
Python-Dev mailin
what they say. Normally my internal CPython builds catch
issues in the hosted VMs before they reach public accounts, but this may
have been a hotfix for some other issue.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
on-developers to write code to get their work done, as we already see
with Jupyter (and family). More are coming, but the responsibility is on
us to make it successful. I want to get it right.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python
On 29Mar.2019 1939, Cameron Simpson wrote:
> Can you get a branch into your pipeline? Then you could just hack the
> tarfile test with something quick and dirty like:
>
> pid = os.getpid()
> system("strace -p %d 2>/path/to/strace.out &" % pid)
> time.sleep(2) # get strace heaps of time
On 29Mar.2019 1944, Steve Dower wrote:
> On 29Mar.2019 1939, Cameron Simpson wrote:
>> Can you get a branch into your pipeline? Then you could just hack the
>> tarfile test with something quick and dirty like:
>>
>> pid = os.getpid()
>> system("strac
>
> https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/DTrace-on-Windows/ba-p/362902
See my other reply about this. DTrace on Windows is a very long way from
being suitable for production environments.
Cheers,
Steve
___
Python-
I don't really care that much about the name. I'd
be okay dropping either "executable" or "code" as well - I don't really
have a good sense of which will make people more likely to use this
correctly.
Cheers,
Steve
___
he runtime. That way it's more transparent for users
and more difficult for us to add options that embedders can't access.
The appendix is excellent, by the way. Very useful detail to have
written down.
Cheers,
Steve
> ``PyWideCharList`` is a list of ``wchar_t*`` strings.
I alway
team got back to me and
it seems to be a known issue - the workaround they gave me was to run
"sudo setfacl -Rb /home/vsts" at the start, so I've merged that in for
now (to master and 3.7).
Cheers,
Steve
___
Python-Dev mailing list
P
ly returning the verified content).
- Context is an optional Python object from the caller's context. For
the import system, it could be the loader instance.
I think the audit event covers this, unless you have some way of using
this context in mind that I can't think of?
Cheers,
Steve
On 30Mar2019 0913, Steve Dower wrote:
On 30Mar.2019 0747, Nick Coghlan wrote:
I like this PEP in principle, but the specific "open_for_import" name
bothers me a lot, as it implies that "importing" is the only situation
where a file will be opened for code execution.
If
On 01Apr2019 1535, Cameron Simpson wrote:
On 01Apr2019 09:12, Steve Dower wrote:
On 30Mar2019 1130, Gregory P. Smith wrote:
I wouldn't expect it to be the case in a CI environment but I believe
a umask can be overridden if the filesystem is mounted and configured
with acls set? (oh
gration to improve over time. For now, close/reopen the PR.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/arch
port it in python").
So the main points of discussion right now are "whose problem does this
solve" and "when do we tell people they need a full venv". And that
discussion is mostly happening at
https://discuss.python.org/t/pep-582-python-local-packages-directory/
there another
way to get the same functionality without ABI modifications?
I think it's worthwhile if we can really get to debug and non-debug
builds being ABI compatible. Getting partway there in this case doesn't
seem to offer any benefits.
Che
l the useful context is gone.
Note: I'm not talking about Py_FatalError() here, this one will not
change.
Does this get called as part of initialization? If not, I'm fine with it
not changing.
Cheers,
Steve
___
Python-Dev mailing list
Pyt
On 05Apr2019 0912, Victor Stinner wrote:
About PyPreConfig and encodings.
[...]
* ``PyInitError Py_PreInitialize(const PyPreConfig *config)``
* ``PyInitError Py_PreInitializeFromArgs( const PyPreConfig *config,
int argc, char **argv)``
* ``PyInitError Py_PreInitializeFromWideArgs( const PyPreC
On 05Apr2019 0922, Victor Stinner wrote:
While there are supporters of an "isolated Python" (sometimes called
"system python"), the fact that it doesn't exist in any Linux distribution
nor on any other operating system (Windows, macOS, FreeBSD), whereas it's
already doable in Python 3.6 with Py_I
e that there should be no side effects. I think it's easier to
document as well.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 10Apr2019 0401, Victor Stinner wrote:
Le mar. 9 avr. 2019 à 22:16, Steve Dower a écrit :
What are the other changes that would be required?
I don't know.
And is there another
way to get the same functionality without ABI modifications?
Py_TRACE_REFS is a double linked list of
On 10Apr2019 1109, Steve Dower wrote:
On 10Apr2019 0401, Victor Stinner wrote:
I think it's worthwhile if we can really get to debug and non-debug
builds being ABI compatible. Getting partway there in this case doesn't
seem to offer any benefits.
Disabling Py_TRACE_REFS by defaul
e means you should avoid
making assumptions about users you know nothing about.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
build.)
My question stands: is it worth to keep a feature which "waste"
resources (memory footprint and CPU) and nobody uses it?
You haven't even tried to show that nobody uses it, other than pointing
out that it exposes a crash due to a refcou
debug binaries".)
That box is immediately below one labelled "Download debug symbols", so
hopefully seeing it in context would have set the right expectation.
(And since I have them, there were 1.3 million downloads of the symbol
packag
a "hack" for some reason that we can't figure out anymore.
So if you are a historian of ancient operating systems and know of one
that might have raised signal handlers in a different process from the
one where it was registered, we'd love to hear from you.
Cheers,
Steve
_
On 12Apr.2019 1643, Nathaniel Smith wrote:
> On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
>>
>> On 10Apr2019 1917, Nathaniel Smith wrote:
> I don't know how many people use Py_TRACE_REFS, but if we can't find
> anyone on python-dev who uses it then it mus
On 12Apr2019 1819, Nathaniel Smith wrote:
On Fri, Apr 12, 2019 at 5:05 PM Steve Dower wrote:
On 12Apr.2019 1643, Nathaniel Smith wrote:
On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
The very first question I asked was whether this would let us converge
the ABIs, and the answer was &qu
On 15Apr2019 1344, Christian Heimes wrote:
Hi Steve,
(memory dump before I go to bed)
Steve Grubb from Red Hat security pointed me to some interesting things
[1]. For instance there is some work on a new O_MAYEXEC flag for open().
Steve came to similar conclusions like we, e.g. streaming code
(and
exclusive) handle/descriptor", so this feels like YAGNI.
On 01/04/2019 18.31, Steve Dower wrote:
In each case there should be associated audit events for tracking the
intent (and interrupting at that point if it doesn't like the intended
action), but for the simple case of &quo
27;rm -rf
/')" until it's too late).
Perhaps for the sake of IDEs and static analysers we could make a policy
for standard library modules to include an "if False:" or "TYPE_CHECKING
= False; if TYPE_CHECKING:" block that includes the import st
arts by sharing the keys in the same way
that __dict__ does (including the transformation when necessary) seems
like an okay addition. Maybe copy() could just be enabled for this?
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://
On 22Apr2019 1921, Steve Dower wrote:
On 22Apr2019 1822, Glenn Linderman wrote:
Inada is now proposing a way to allow the coder to suggest a group of
dictionaries that might benefit from the same gains, by preclassifying
non-__dict__ slot dictionaries to do similar sharing.
CSV reader is an
On 22Apr2019 2143, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
Or possibly just "dict(existing_dict).update(new_items)".
Do you mean .update accepts values tuple?
I can't think it's
Not sure what you were going to go on to say here, but why
ge - and keys
lazily - since there are known scenarios where they are not going to be
changed, but we'll pay the cost later if it turns out they are.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
On 23Apr2019 0034, Glenn Linderman wrote:
On 4/22/2019 10:59 PM, Steve Dower wrote:
On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately
obvious, I don't get how either copy or update would achieve the
goal. Perhaps you cou
On 23Apr2019 0008, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote:
On 22Apr2019 2143, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
Or possibly just "dict(existing_dict).update(new_items)".
Do you mean .update accepts values tupl
e layout is
created.
Is it a manual build?
It's semi-automated, but it's only triggered for releases and so it's
not part of the normal CI configuration.
Hope that helps,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
ht
matters at build time, so it's a little more complex to make it work as
an embedded runtime. I'm sure there are people who know how to make it
work though.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
Looks like the failure is due to absence of a News entry. Maybe add a "skip
news" label if this doesn't need to be documented?
Kind regards.
Steve Holden
On Fri, May 3, 2019 at 9:48 AM Srinivas Reddy Thatiparthy <
thatiparthysreeni...@gmail.com> wrote:
> Hi,
>
nks!
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
___
* embedders want to use their own files/libraries
* embedders want to totally override getpath, not augment/configure it
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
it turns
out that other people had different opinions.
Cheers,
Steve
On 13May2019 1452, Victor Stinner wrote:
)Le lun. 13 mai 2019 à 18:28, Steve Dower a écrit :
My take:
* all the examples are trying to be isolated from the system Python
install (except Vim?)
"Isolation" means di
rsion that writes to a buffer?
That would provide a supported workaround for the encoding issues and
unblock people hitting trouble right now, yes?
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
l not end until my death.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
ed that the Steering Council gave it thorough consideration
and that the discussions covered all relevant aspects, so I'm not going
to create too much of a fuss about it. If they want to move us
completely to GitHub, so be it!
Cheers,
Steve
___
Pytho
;s first C
contribution?
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
commit to a new public API. Registering new importers should not have to
be "dirty".
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ve embedding. But we don't get to
totally revise the public API on each release without alienating users,
which is why I would rather hold the public API changes until 3.9,
investigate and design them properly. It does our users a disservice to
make major changes like this without due
#x27;s a lot of configuration
that's split between site.py and initialization, so it's very hard to
understand what will be ready when you leave out site.py. Straightening
this out would help (everyone except virtualenv, probably ;) )
Cheers,
Steve
___
x27;s a good
idea - this is yet another place where it's likely to be dead/dying
already. And what can you do with it? Resurrection seems like a really
bad idea, as does diving into a custom __repr__. There's no useful
recovery mechanism here that I'm aware of, so I&#
On 16May2019 0856, Steve Dower wrote:
On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a
écrit :
For unraisable hook, it's not hard to imagine other useful parameters
that can be passed to the hook to provide more context about the
exception. For ex
On 16May2019 0902, Steve Dower wrote:
Actually, if the default implementation prints the exception message,
how is this different from sys.excepthook? Specifically, from the point
of customizing the hooks.
If I were going to replace unraisablehook to do something on specific
exceptions, I&#
On 16May2019 1404, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit :
I really like this API, and I agree with Victor that we don't really
need more than the exception info. For future expansion, we can pass in
a different exception, no?
Sorry, I don't und
On 16May2019 1441, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit :
You go on to say "pass an error message" and "keep repr(obj) if you
want", but how is this different from creating an exception that
contains the custom message, the repr of the ob
ary. But 3.9 won't be covered by that :)
But I'm in favor of having a proper CST module that matches the version
of Python it's in. It doesn't help people on earlier versions (yet), but
given how closely tied it is to the Python version you're on I think it
makes sense in
y if I set
> multiversion(tornado, 2.2.1) then all modules in that package will use
> tornado 2.2.1 when I import
> tornado.
>
> See a relevant issue on github:
> https://github.com/mitsuhiko/multiversion/issues/1
>
> Thank you!
> Qiang
>
>
> __
ssion that it's not used.
>
> Christian
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40ho
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
___
Good point!
On Tue, May 21, 2019 at 2:01 PM Paul Moore wrote:
> On Tue, 21 May 2019 at 13:50, Steve Holden wrote:
> >
> > That seems entirely reasonable. I wonder if the larger community could
> somehow form an organization (the Dead Parrot SIG?) that would at least
&g
so it's a reflection of the popularity and support for Python that's
growing within Microsoft that we were able to make this happen. That's
due to every contributor, both to the core runtime and the ecosystem. I
hope this will only help us improve the availability
get a prompt next time you double-click a .py
file, but it shouldn't just steal them.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 22May2019 1237, Oscar Benjamin wrote:
On Tue, 21 May 2019 at 21:32, Steve Dower wrote:
In the next Windows 10 update that starts rolling out today, we
(Microsoft) have added "python.exe" and "python3.exe" commands that are
installed on PATH *by default* and will open th
or release of Python -
it's published by whoever the Windows build manager is at the time. Just
to be confusing, it's me right now, but the actual install is not owned
or managed by Microsoft - just endorsed and linked.
Cheers,
Steve
___
Pyt
rprised if most system ones are at least as good for our
needs now. Certainly Windows HeapAlloc has had serious improvements in
that time to help with fragmentation and small allocations.
Cheers,
Steve
[1]:
https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/
so *shrug*).
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ation semantics, etc.).
But until we have a clear vision statement that everyone (or enough) is
behind, there's nothing gained by prematurely causing that much disruption.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
, Anders
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
>
> > The `getopt <https://docs.python.org/3/library/getopt.html>`_ module
> > mimics
> > C's getopt() option parser. Although users are encouraged to use argparse
> > instead, the getopt module is still widely used.
> >
> > Module type
> >
ay
that doesn't involve lots of dev time then perhaps the PSF could be
involved? I presume the Steering Committee are the people to consider
directions like this.
Steve Holden
On Thu, May 23, 2019 at 7:03 PM Barry Warsaw wrote:
> On May 20, 2019, at 13:15, Christian Heimes wrote:
&g
On 24May2019 0220, Baptiste Carvello wrote:
Hello,
Le 21/05/2019 à 22:30, Steve Dower a écrit :
[...]
* the Python 3.7 installed from the store will not auto-update to 3.8,
but when 3.8 is released we (Microsoft) will update the redirect to
point at it
* if you pass arguments to the redirect
n't have to
be so controversial - either the people who are saying "we rely on this"
are also willing to help us maintain them, or they're not. And if
they're not, they clearly don't rely on it (or realize the cost of
relying on volunteer-maintained softwa
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
--
> Richard Damon
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
see asserts coming from core (because they've been optimised out). So if
this is something we're going to detect at runtime regardless of build,
using Py_FatalError/abort or raising a SystemError is preferable.
Otherwise we'll be forcing users to debug a segfault.
Cheers,
Steve
_
Perhaps if PEP 594 is seen to be moving ahead towards a slimmer Python (4?)
stdlib, it might encourage the development of a PEP to take over
maintenance of dead parrots. They might be recruited by the offer of some
way to at least publish a supported bundle via the same (python.org) site
that Pytho
t least we have
an explanation for unmaintained packages too - they still show up in
distros but are not part of the CPython source tree.
Cheers,
Steve
Python-Dev mailing list -- python-dev(a)python.org
To unsubscribe send an email to python-dev-leave(a)python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
d of '='?" Or we could do this on
construction, but that may rule out some interesting uses in the future
if you have a need to delay specifying enum values.
I'm not particularly a fan of how it currently is.
Cheers,
Steve
___
Python-Dev ma
ation (possibly a PEP)
and we can agree to add it.
More likely it's just convenient. The cost of that convenience is that
we can never optimise internals because they are now public API. Better
off never to have leaked the details.
Che
On 13Jun2019 0816, Jeroen Demeyer wrote:
On 2019-06-13 17:11, Steve Dower wrote:
The cost of that convenience is that
we can never optimise internals because they are now public API.
I think that the opposite is true actually: the reason that people
access internals is because there is no
for new contributors.
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.pytho
anyone who relies) on libpython38.a on Windows?
* Are you able to add the two commands above to your build? If not, why not?
Thanks,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
401 - 500 of 1536 matches
Mail list logo
