erShell. In the absence of
> confirmation that 4-letter extensions work reliably in such cases, it seems
> wise to abbreviate the Windows GUI application extension as .pzw.
>
> I've also cc'ed Steve Dower, since investigation of this kind of Windows
> behavioural question i
s\System32 or C:\Windows\SysWOW64 for python27.dll)
should also make this work. VS will always look next to the executable file.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Could the same result be achieved by hooking the MRO that super uses and
returning a list of proxy objects? And then wouldn't you only really need a
__getattribute__ that doesn't recurse (__getlocalattribute__)? The end result
may be conceptually simpler, but you've thought through the edge case
e proxy objects idea was a red herring, sorry :) )
Steve
Sent from my Windows Phone
From: Ronald Oussoren<mailto:ronaldousso...@mac.com>
Sent: 7/7/2013 12:37
To: Steve Dower<mailto:steve.do...@microsoft.com>
Cc: python-dev@python.org<mailto:python-
> From: Ronald Oussoren [mailto:ronaldousso...@mac.com]
> Sent: Monday, July 8, 2013 0858
>
> On 8 Jul, 2013, at 17:19, Steve Dower wrote:
>
> > The only real advantage is a simpler signature and more easily explained
> use (assuming the person you're expl
XP support it can't really be taken out
for 3.4.1. Since 3.4.1 is almost certainly going to be after the end of
extended support, better to drop it for .0
Steve
> From: Christian Heimes
> Subject: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL
>
> Hi,
>
>
> (Though updating project files to that is almost certainly a bigger project
> than the gcc update.)
No idea what the gcc update involved, but this is only accurate if it took less
than two minutes :-) I've upgraded the CPython projects before and everything
worked fine.
Steve
__
o, it should include .pyw, .pyz and whatever was decided instead of .pywz
(.pwz, I think?).
Steve
(Apologies for the top post.)
Sent from my Windows Phone
From: Paul Moore<mailto:p.f.mo...@gmail.com>
Sent: 7/27/2013 1:13
To: Martin v. Löwis<mailto:mar.
haven't checked, but this could
seriously hurt performance of anything that uses PATHEXT to search PATH for
anything ending in this extension. I hope that cmd.exe and PowerShell check for
duplicate extensions, but I wouldn't be betting any money that they do.
Steve
___
f.mo...@gmail.com>
Sent: 7/28/2013 1:00
To: Steve Dower<mailto:steve.do...@microsoft.com>
Cc: Martin v. Löwis<mailto:mar...@v.loewis.de>; Python
Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows
On 28 July 2013 00:30, S
What about __getlocalattribute__ or __getattributenorecurse__? Long, but this
isn't going to be used often.
Putting "type" or "class" in the name would be misleading. It's an instance
method (that is most useful when implemented on a metaclass).
(Apologies for the top post.)
Sent from my Windo
ne of those.
Cheers,
Steve
Sent from my Windows Phone
From: Steven D'Aprano<mailto:st...@pearwood.info>
Sent: 9/12/2013 21:00
To: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__
O
From: Steven D'Aprano
> On Fri, Sep 13, 2013 at 04:26:06AM +0000, Steve Dower wrote:
>
>> Last I checked, looking up in the instance dict us exactly what it
>> does. Even the example you posted is doing that.
>
> The example from the PEP shows:
>
> retur
(fat fingered the send button, picking up where I left off)
If the pattern is really going to be the hasattr check you posted earlier, can
we just do it for people and save them writing code that won't work on
different OSs?
Cheers,
Steve
Top-posted from my Windows Phone
-Ori
Can we get any new function on all platforms, deferring to urandom() if
getrandom() isn't there?
If the pattern is really going to be the hasattr check you posted earlier
Top-posted from my Windows Phone
-Original Message-
From: "Larry Hastings"
Sent: 6/10/2016 8:50
To: "python-dev@
It's not just security discussions. The same thing happened with fspath,
tzinfo, and many others that I have erased from my own memory. distutils-sig
sees them often as well.
The whole thing seems like a limitation of written communication. There's no
way to indicate or define whether something
com if you
have concerns.
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
e and post on
http://bugs.python.org/issue27417.
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
s.
Probably no better opportunity to make such a fundamental change as we move to
a new VCS...
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Guido van Rossum"
Sent: 7/3/2016 7:42
To: "Python-Dev"
Cc: "Nick Coghlan"
Subject: Re: [
re ability to
patch their own stdlib after install.
(FWIW, we use a system similar to this at Microsoft for building Visual Studio,
so I can vouch that it works on much more complicated software than Python.)
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "
ostly for
the versioning benefits - I doubt we could ever release Python without
them, but it'd be great to be able to update distutils, ctypes or ssl in
place with a simple pip/package mgr command.)
Cheers,
Steve
___
Python-Dev mailing li
The shorter the cycle between finding a need and
committing the patch, and the more often issues are found *before*
commit, the more frequently we can do releases.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
Hi Peter,
While the humble webmasters can do little about this it's possible the
developers can, so I am forwarding your email to their mailing list.
regards
Steve
Steve Holden
On Tue, Jul 5, 2016 at 3:30 AM, Peter via Webmaster
wrote:
> Hi
> I'm a heavy user of Python
On 04Jul2016 2241, Steve Holden wrote:
Hi Peter,
While the humble webmasters can do little about this it's possible the
developers can, so I am forwarding your email to their mailing list.
regards
Steve
Steve Holden
On Tue, Jul 5, 2016 at 3:30 AM, Peter via Webmaster
mailto:w
ead being tied to, for example, a specific asyncio version
that can be brought into a range of supported Python versions).
Batteries included is a big deal.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
On 05Jul2016 1028, Barry Warsaw wrote:
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
A rough count of how I'd break up the current 3.5 Lib folder (which I
happened to have handy) suggests no more than 50 repos.
A concern with a highly split stdlib is local testing. I'm not wor
versioning, they are:
1. Break the stdlib out from CPython and have it be a stand-alone repo
2. Break the stdlib up into a bunch of independent repos that when
viewed together make up the stdlib (Steve Dower did some
back-of-envelope grouping and pegged the # of repos at ~50)
Actually, I was
hich keeps Windows
Smartscreen happy and is the only way we can indicate that it's
trustworthy. If Norton requires different criteria then that is on them
and not something we can fix.
Cheers,
Steve
___
Python-Dev mailing list
Python-D
I think the wsgiref issue was that it wasn't in site-packages and so couldn't
be removed or upgraded. Having the dist-info available and putting them in
site-packages (or a new directory?) lets us handle querying/replacing/removing
using the existing tools we use for distribution.
Also, I think
e is about community/user expectations (I have not
been proposing to remove stdlib modules at any point).
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Petr Viktorin"
Sent: 7/6/2016 2:04
To: "Steven D'Aprano" ; "Python-Dev&q
om: "Paul Moore"
Sent: 7/6/2016 7:10
To: "Steve Dower"
Cc: "Petr Viktorin" ; "Python-Dev"
Subject: Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)
On 6 July 2016 at 14:55, Steve Dower wrote:
> I think the wsgiref issue was that it wasn&#
On 06Jul2016 0753, Steve Dower wrote:
Thrashing out details should go on the workflow SIG, and I guess I'm the
obvious candidate to push it asking. But given my own time constraints
right now, I'm not going to dive into details if the high level concept
(stdlib packages can be in
a possibility, and it may even be
possible to manage these packages directly in Lib/, which would result
in basically no visible impact for anyone who doesn't care to update
individual parts.
Cheers,
Steve
Cheers,
-Barry
___
Python-Dev mailing
to Guido first, unless he wants to delegate to one of
the other Windows contributors?
Cheers,
Steve
URL: https://www.python.org/dev/peps/pep-0514/
Full text
---
PEP: 514
Title: Python registration in the Windows registry
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower
Sta
e would be my
first choice.
Otherwise Zach still has the obligation that comes with being labelled a
Windows expert in the dev guide ;)
On Fri, Jul 15, 2016 at 3:20 PM, Steve Dower wrote:
Hi all
I'd like to get this PEP approved (status changed to Active, IIUC).
So far (to my knowl
Good catch, thanks.
Top-posted from my Windows Phone
-Original Message-
From: "Nick Coghlan"
Sent: 7/15/2016 23:53
To: "Steve Dower"
Cc: "Python Dev"
Subject: Re: [Python-Dev] PEP 514: Python registration in the Windows registry
On 16 July 201
On 16Jul2016 1254, Paul Moore wrote:
On 15 July 2016 at 23:20, Steve Dower wrote:
Hi all
I'd like to get this PEP approved (status changed to Active, IIUC).
Some comments below.
Awesome, thanks! Posted a pull request at
https://github.com/python/peps/pull/59 for ease of diff reading
estly, I don't expect many tools written in
Python to be scanning the registry (since once you're in Python you
probably don't need to find it), but hopefully they'll help clarify the
PEP for people who prefer code.
Full text below.
Cheers,
Steve
--
PEP: 514
Titl
ml thing rather than a VCS thing?).
I'll definitely update BDFL-Delegate, Post-History, Status and
Resolution tags for the final PR.
Thanks,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
Thanks Paul.
I'll update the headers on the PEP later today.
Top-posted from my Windows Phone
-Original Message-
From: "Paul Moore"
Sent: 7/24/2016 0:45
To: "Guido van Rossum"
Cc: "Steve Dower" ; "Python Dev"
Subject: Re: [Python-Dev
From: "Barry Scott"
Sent: 7/28/2016 10:19
To: "Steve Dower"
Cc: "Python Dev"
Subject: Re: [Python-Dev] PEP 514: Python registration in the Windows registry
Why do you need SysArchitecture? Surely the 32bit pythons are registered in the
32bit registry and the 64
ren't also in C++.
I'd settle for saying that all header files must be C++ compatible so that
embedders and extenders have the option of C or C++, even if we allow the
obscure parts of C99 inside our code.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
On 19Aug2016 0910, Chris Angelico wrote:
On Sat, Aug 20, 2016 at 1:26 AM, Steve Dower wrote:
Check any .pth files you can find. I suspect mpl_toolkits has some magic in
it to make the namespace package work on 2.7.
$ cat /usr/local/lib/python3.6/site-packages/matplotlib-1.5.1-py3.6-nspkg.pth
s at play here. I suspect this will
eventually become a PEP, but it's presented here as a summary of a
discussion and not a PEP.
Cheers,
Steve
Summary
===
Representing file system paths on Windows as bytes may result in data
loss due to the way Windows encodes/decodes strings via its b
ter and get away with it.
At least with utf-8 you encounter multi-byte sequences often enough that
you basically are forced to deal with them.)
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
mport site
site.addpackage = lambda *a: None
site.main()
# rest of the test
Then that should do it. This will cut out all .pth processing, but
shouldn't affect any of the other steps.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@p
To help, I could add an extra info page to the prerelease installer
announcing some specific new changes and explicitly asking for feedback
to bugs.p.o - the ask is already there, but we could beg more in
prereleases.
Cheers,
Steve
___
Python-De
On 22Aug2016 0247, Stephen J. Turnbull wrote:
Nick Coghlan writes:
> On 21 August 2016 at 06:31, Steve Dower wrote:
> > My biggest concern is that it then falls onto users to know how
> > to start Python with that flag.
The users I'm most worried about belong to
a cross-platform compatible way.
The biggest difference from the file system encoding is that the
encoding for file contents is entirely the business of the application
(and whichever other applications it talks to), while the OS is the main
recipient of file system encoded text and so it ge
On 23Aug2016 2150, Stephen J. Turnbull wrote:
Steve Dower writes:
> * Stephen sees "no reason not to change locale.getpreferredencoding()"
> (default encoding for open()) at the same time with the same switches,
> while I'm not quite as confident. Do users gener
it obviously isn't written to use the
> other two, so might as well shut them all off.
Since Steve is thinking about three separate PEPs (among other things,
they might be implemented on different timelines), that's not really
possible (placing the features under control of one switc
t going to see dropping byte support completely as a
hostile action, I'd much rather go that way.
But let's definitely take note that platform-specific deprecation
warnings are probably not a good idea for cross-platform functionality.
What Steve is proposing here is essentially a w
ing I'm quite happy to back out of. It's
already easy enough for the developer to specify the encoding when opening a
file, or to wrap open() and change their own default. But developers cannot
change the encoding used by the os module, which is why we need to do it.
Cheers,
Steve
On 30Aug2016 0806, Victor Stinner wrote:
2016-08-30 16:31 GMT+02:00 Steve Dower :
It's the
random user on Windows who installed their library that has the problem.
They don't know the fix, and may not know how to apply it (e.g. if it's
their Jupyter notebook that won't fin
wait for 3.7. I think the technical
implications are fairly clear, it's just the risk of
surprising/upsetting users that is not.
Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
On 30Aug2016 1611, Victor Stinner wrote:
2016-08-30 23:51 GMT+02:00 Victor Stinner :
As I already wrote once, my problem is also tjat I simply have no idea how
much Python 3 code uses bytes filename. For example, does it concern more
than 25% of py3 modules on PyPi, or less than 5%?
I made a v
t point is exactly why I think this is important. Any arguments
against making Windows behave more like Linux (i.e. bytes paths are
reliable) need to be clear as to why this doesn't matter or is less
important than other concerns.
Cheers,
Steve
_
flights, but it's in
pretty good shape right now.
Cheers,
Steve
---
https://github.com/python/peps/blob/master/pep-0528.txt
---
PEP: 528
Title: Change Windows console encoding to UTF-8
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower
Status: Draft
Type: Standards Track
bugs.python.org/issue27781 for the current proposed patch. I
do need to update it in order to merge against default it seems (work
for my upcoming flight).
Cheers,
Steve
---
https://github.com/python/peps/blob/master/pep-0529.txt
---
PEP: 529
Title: Change Windows filesystem encoding to UTF-8
Ver
-Dev] PEP 528: Change Windows console encoding to UTF-8
On Thu, Sep 1, 2016, at 18:28, Steve Dower wrote:
> This is a raw (bytes) IO class that requires text to be passed encoded
> with utf-8, which will be decoded to utf-16-le and passed to the Windows APIs.
> Similarly, bytes read from t
e sure that it's the direction we want the language to go.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Steven D'Aprano"
Sent: 9/2/2016 9:43
To: "python-dev@python.org"
Subject: Re: [Python-Dev] Please reject or postpone PEP 526
ven if specific implementation details
change between now and release.
Cheers,
Steve
---
@@ -21,8 +21,7 @@
This PEP proposes changing the default standard stream implementation
on Windows
to use the Unicode APIs. This will allow users to print and input the
full range
of Unicode characters
necessary changes.
As with PEP 528, I don't think it's possible to predict the impact better than
I already have, and the beta period will be essential to determine whether this
change is completely unworkable. I am fully prepared to back out the change if
necessary prior to RC.
Che
EP 528: Change Windows console encoding to UTF-8
On 5 September 2016 at 10:37, Martin Panter wrote:
> On 5 September 2016 at 09:10, Paul Moore wrote:
>> On 5 September 2016 at 06:54, Steve Dower wrote:
>>> +Using the raw object with small buffers
>>> +---
On 05Sep2016 0941, Paul Moore wrote:
On 5 September 2016 at 14:36, Steve Dower wrote:
The best fix is to use a buffered reader, which will read all the available
bytes and then let you .read(1), even if it happens to be an incomplete
character.
But this is sys.stdin.buffer.raw, we're ta
On 05Sep2016 1110, Paul Moore wrote:
On 5 September 2016 at 18:38, Steve Dower wrote:
Can you provide an example of how I'd rewrite the code that I quoted
previously to follow this advice? Note - this is not theoretical, I
expect to have to provide a PR to fix exactly this code should
ccurs on Linux - I have
a VM running this week for testing this stuff.)
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 05Sep2016 1308, Paul Moore wrote:
On 5 September 2016 at 20:30, Steve Dower wrote:
The only case we can reasonably handle at the raw layer is "n / 4" is zero
but n != 0, in which case we can read and cache up to 4 bytes (one wchar_t)
and then return those in future calls. If we tr
On 07Sep2016 1037, Guido van Rossum wrote:
I'm hijacking this thread to provisionally accept PEP 529. (I'll also
do this for PEP 528, in its own thread.)
I've talked things over with Steve and Victor and we're going to do an
experiment (as now written up in the PEP:
https:
its" or "license" for more information.
>>> 2**1000
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946
nguage and very specific to a particular
installation, support can easily be added at any time. Find my various
write-ups on the embeddable distro for details on the use cases, but none of
them affect regular Python developers.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message--
list, and the release manager may
or may not choose to update the published version.
regards
Steve
Steve Holden
On Fri, Sep 9, 2016 at 3:37 PM, Karen Little <
karen.lit...@whoishostingthismail.com> wrote:
> Hi,
>
> Just wanted to let you know about a link that seems to be broken
ocs as well (even when external links break)
>
Thanks for the note, Nick. I assumed that it would be something like that.
I know the devs go to great lengths to keep the documentation accurate, but
I personally would rather see efforts put towards current
On 11Sep2016 1944, steve.dower wrote:
https://hg.python.org/cpython/rev/7793d34609cb
changeset: 103679:7793d34609cb
user:Steve Dower
date:Sun Sep 11 19:43:51 2016 -0700
summary:
Fixes test_getargs2 to get the buildbots working again.
files:
Lib/test/test_getargs2.py | 2
On 11Sep2016 1959, Martin Panter wrote:
On 12 September 2016 at 02:48, Steve Dower wrote:
Fixes test_getargs2 to get the buildbots working again.
I'm not sure this is the fix we want to keep here, but it was sufficient to
get the test going and unblock all the buildbots.
I'm no
7; to be able to align it, which then
means overriding __format__ in that class later won't have any effect.
>>> '{!s:<100}'.format(F())
'<__main__.F object at 0x02148AFEE240>
'
Having the default __format__ behave like
seems fine for now. There's
also not really anything in the docs about how Linux distributors
package up CPython, so maybe it's best as entirely standalone content.
Cheers,
Steve
(In case anyone is suspicious, I earn no income from my blog and there
are no ads. So I hope I'm not
ring the
prerelease versions is a possibility for anything not in the limited ABI.
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/pytho
, just not ready for general distribution (or for producing wheels for
general distribution).
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Nathaniel Smith"
Sent: 11/16/2016 20:19
To: "Nick Coghlan"
Cc: "Python Dev" ; "St
haven't gone through UA data to figure it out yet, but Chrome has
definitely done this in the past).
Treat the actual numbers with a grain of salt, but overall it looks like
we've had pretty good usage of the prerelease versions of 3.6.
Cheers,
Steve
___
I would much rather keep it in December, as I've already made scheduling
decisions around the planned release date and there are fixes in 2.7.13 that I
was expecting to be available by the end of the year. One month is highly
impactful for me.
Is this schedule change going to remove the month f
On 03Dec2016 1312, Serhiy Storchaka wrote:
On 03.12.16 22:13, steve.dower wrote:
https://hg.python.org/cpython/rev/a60767015bed
changeset: 105436:a60767015bed
user:Steve Dower
date:Sat Dec 03 12:12:23 2016 -0800
summary:
Revert unintended merge
I suppose it should be
On 03Dec2016 1519, Martin Panter wrote:
This change comes from Matthias (Doko), and was originally only in the
3.5 branch:
https://hg.python.org/cpython/rev/14c80065c36e
I presume it was left unmerged until there is a branch for 3.6.1 to
merge into. So Steve, when you did your first 3.5 → 3.6
be undone), which is coming up very soon, so if any of the public
APIs should NOT be stable, please fix them, and if any of the private
APIs SHOULD be stable, they'll probably need version-specific guards
(see moduleobject.h).
Cheers,
Steve
Full list of APIs to be added to pyth
Phone
-Original Message-
From: "Steve Dower"
Sent: 12/20/2016 17:56
To: "Python Dev"
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
For those who aren't aware, the stable API (PEP 384) is broken on
Windows because the exports from python3.dll have not
"Ok, now why should _Py_PrintReferences() function be exported?"
It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is
excluded from the headers (my list was automatically generated).
And ideally, private functions that are deliberately exported would have
comments, or if
ike to fix that without blocking on
getting the right long-term fix (since the immediate fix only affects one file
in the Windows distribution, though it has implications for supportability).
Top-posted from my Windows Phone
-Original Message-
From: "Nathaniel Smith"
Sent: 12/
"Victor Stinner"
Sent: 12/21/2016 8:40
To: "Nathaniel Smith"
Cc: "Steve Dower" ; "Serhiy Storchaka"
; "Python Dev"
Subject: Re: [Python-Dev] Issue #23903 - stable API is incomplete
2016-12-21 17:21 GMT+01:00 Nathaniel Smith :
> It sounds like
d then install the
wheel. You miss out on their post-install steps, but most people don't need
those anyway.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Burkhard Meier"
Sent: 12/28/2016 1:43
To: "Glenn Linderman"
Cc: "Python
n the stable API changes accidentally it'll be
less of an issue.
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
, difflib, random) do use this
technique, but it is far from universal.
So I thought it would be useful to get input from current devs about the
value of this practice, since to me it seems somewhat anti-pythonic. What
advantages does it confer?
regards
Steve Holden
Avoiding header files would be my only request. As Brett says, the C99
requirement should not be enforced on all embedders or extenders, so we should
try and keep the headers they'll use as compatible as possible.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
(and if
that's not true, let's definitely add checks for those cases), I think we can
achieve this without excessive effort.
(And I'm fairly sure MSVC 9.0 in C mode is the most regressive compiler we have
available ;) )
Cheers,
Steve
Top-posted from my Windows Phone
-O
the very clear explanation.
Would an addition to the documentation for 3.6 giving an abbreviated
version help while the devs consider whether any changes are appropriate
for 3.7?
Steve Holden
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
pattern matching. If re has advantages in certain situations someone might
upgrade the 3.x implementation and provide it as a 3rd-party module, though
the effort involved would be significant, so someone would have to be
motivated to keep it.
regards
Steve
Steve Holden
On Sun, Jan 29, 2017 at 4:13
r macOS. (macOS can technically do this when you link
against the system OpenSSL, at the cost of using a catastrophically insecure
version of OpenSSL.)
In theory it is possible for Python and OpenSSL, too. I looked into a
custom X509_LOOKUP_METHOD to locate trust anchors by subject. Ste
rome has done
it?
Top-posted from my Windows Phone
-Original Message-
From: "Cory Benfield"
Sent: 2/1/2017 2:03
To: "Steve Dower"
Cc: "Christian Heimes" ; "David Cournapeau"
; "python-dev"
Subject: Re: [Python-Dev] SSL certificates re
Big +1 here, and an implicit -1 on the other suggestions.
asyncio != async/await
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Nathaniel Smith"
Sent: 2/28/2017 23:19
To: "Nick Coghlan"
Cc: "python-dev@python.org"
Subjec
I just want to emphasize that this is a *very* important release to test, as it
is the first one made after migrating the project to github.
Please spend a bit of time running it through your normal build/installation
steps and let us know at https://bugs.python.org/ if anything seems off.
Top-
will come up with a plan
that leads to a stable and reliable release.
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
601 - 700 of 1536 matches
Mail list logo
