Am 19.10.2013 14:54, schrieb Antoine Pitrou:
> On Sat, 19 Oct 2013 14:25:28 +0200 (CEST)
> christian.heimes wrote:
>>
>> - .. note:: A fast implementation of *pbkdf2_hmac* is only available with
>> - OpenSSL 1.0 and newer. The Python implementation uses an inline
>> - version of :mod
Am 19.10.2013 16:14, schrieb Nick Coghlan:
> At the very least, it would be good if you and/or MAL could review
> the cert verification in pip. PEP 453 makes that kinda important
> :)
Where can I find the code for PEP 453?
___
Python-Dev mailing list
Py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 19.10.2013 16:59, schrieb Nick Coghlan:
> It's the cert verification in pip that's relevant - the PEP was
> updated so that ensurepip itself never talks to the internet. So I
> guess that would mean checking the cert verification in pip's
> vend
Am 19.10.2013 17:15, schrieb Nick Coghlan:
>> +c_hashlib = import_fresh_module('hashlib', fresh=['_hashlib'])
>
> Looks like this import is failing on at least some platforms:
>
> http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/6535/steps/test/logs/stdio
> http://buildbot
Am 19.10.2013 16:59, schrieb Antoine Pitrou:
> But that's a fringe situation. Any normal build of Python should be
> compiled with OpenSSL support (and any decent binary build is). I think
> the mention in the docs is distracting and will create pointless
> uncertainty in the reader.
HMAC_CTX_copy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 19.10.2013 20:04, schrieb Victor Stinner:
> Does Python officially support opsenssl < 1.0? Which OS uses such
> old version?
>
> On Windows, Python embeds its own copy of openssl for example.
Mac OS X has only OpenSSL 0.9.8 and will not receive
Am 23.10.2013 23:37, schrieb Charles-François Natali:
> Hi,
>
> What's the current status of pathlib? Is it targeted for 3.4?
>
> It would be a really nice addition, and AFAICT it has already been
> maturing a while on pypi, and discussed several times here.
> If I remember correctly, the only re
Am 24.10.2013 11:26, schrieb Georg Brandl:
> Am 24.10.2013 11:11, schrieb Ned Deily:
>
>> I don't know where any other potential 2.7.6 or 3.3.3 issues stand at this
>> point. But I'd like Benjamin and Georg to propose an aggressive schedule so
>> we can get these fixes out there.
>>
>
> We've
Am 24.10.2013 13:36, schrieb Victor Stinner:
> IMO the best place to fix the bug is in OpenSSL directly: RAND_bytes()
> function of OpenSSL can detect a fork using getpid() and add more
> entropy (in the child or maybe in the parent process). OpenSSL has
> access to entropy sources and knows all mu
Am 26.10.2013 20:58, schrieb benjamin.peterson:
> http://hg.python.org/cpython/rev/4913d0e9be30
> changeset: 86665:4913d0e9be30
> branch: 2.7
> tag: v2.7.6rc1
> user:Benjamin Peterson
> date:Sat Oct 26 14:57:21 2013 -0400
> summary:
> 2.7.6rc1
We need to solve htt
Am 31.10.2013 15:48, schrieb MRAB:
> Has anybody here heard about this, and, if so, is it anything we should
> be thinking about:
>
> How your compiler may be compromising application security
> http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security
http
Am 31.10.2013 15:48, schrieb MRAB:
> Has anybody here heard about this, and, if so, is it anything we should
> be thinking about:
>
> How your compiler may be compromising application security
> http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security
>
I
Good news everybody!
A while ago John Kelsey has presented NIST's plans to change SHA-3 [1]
in order to make it faster but also weaker. Last Friday he posted a mail
on NIST's internal hash-forum mailing list. NIST is planing to drop
these plans and to move forward with the SHA-3 draft in its origi
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5. Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to archive the goal I propose to
- deprecate the key_fi
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
> I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
> quite young.
It's available since 3.3
>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
>>to CERT_REQUIRED.
>
> -0.9. This breaks compatibility and doe
Am 07.11.2013 23:25, schrieb Nick Coghlan:
> Change this to create_default_context() (to make it clearer there is no
> global context object) and I'm generally +1.
Good idea!
> This overlaps confusingly with "verify_mode". Perhaps just offer a
> module level "verify_hostname" API that adapts betw
Am 08.11.2013 00:09, schrieb Barry Warsaw:
> I'm sure you're considering this, but I want to explicitly preserve the
> ability to register self-signed certificates. It's often necessary in
> practice, but very useful for testing purposes.
>
> ssl.SSLContext.load_cert_chain() is the way to do this
Somehow your mail didn't end up on Python-dev
Am 08.11.2013 00:38, schrieb Nick Coghlan:
> In that case, it sounds like you need *two* new options rather than
> one. "verify_hostname", with the None/True/False behaviour and a
> separate postverify hook.
Mmmh, yes, you are making an intriguing poi
Am 08.11.2013 08:42, schrieb Antoine Pitrou:
> 3.2 actually, while many code bases are still 2.x-compatible.
> There's no need to make migration more annoying right now.
There is also no need to hinder and delay future improvements for the
sake of 2.x compatibility. Python 2.7.0 has been released
Am 13.11.2013 01:47, schrieb Glenn Linderman:
> If it is an implementation issue, then perhaps a different
> implementation would help. Or perhaps a "safe compiler".
>
> If it is a language design issue, then a different implementation
> wouldn't help, it would require a new language, or a restric
Am 13.11.2013 23:37, schrieb Eli Bendersky:
> Yeah, it definitely could. There are two problems currently: 1) the
> patches are for 2.7.x and 2) they have some ugly hacks in them. But I
> will talk to the guy who worked on that and hopefully we'll be able to
> have something cleaned up for upstream
Am 15.11.2013 19:07, schrieb jason.coombs:
> http://hg.python.org/cpython/rev/b9c9c4b2effe
> changeset: 87119:b9c9c4b2effe
> user:Andrew Kuchling
> date:Fri Nov 15 13:01:52 2013 -0500
> summary:
> Issue #19544 and Issue #6516: Restore support for --user and --group
> parameter
Am 20.11.2013 11:07, schrieb Nick Coghlan:
> Christian has indicated he now considers PEP 456, which adds an updated
> and configurable hash algorithm ready for pronouncement
> (http://www.python.org/dev/peps/pep-0456/)
>
> I am happy the PEP and the associated implementation represent a
> desirab
Am 20.11.2013 12:41, schrieb Victor Stinner:
> 2013/11/20 Victor Stinner :
>> It looks like dict, set and frozenset representation (repr(...))
>> now depends on the platform (probably 32 bit vs 64 bit), even if
>> PYTHONHASHSEED is set. I don't know if it's an issue or not.
>
> In Python 3.3, rep
Am 21.11.2013 16:12, schrieb Barry Warsaw:
> On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote:
>
>> Oh, this is the misunderstanding. No one is trying to get permission for
>> "CPython 2.8", only "Stackless Python 2.8".
>
> I think this is a very bad idea. We've worked hard to send th
Am 21.11.2013 18:57, schrieb Tim Peters:
> Best to change the failing tests. For example, _they_ can sort the
> dict keys if they rely on a fixed order. Sorting in general is a
> dubious idea because it can be a major expense with no real benefit
> for most uses.
I don't consider repr() as a per
Am 21.11.2013 12:31, schrieb mar...@v.loewis.de:
> That sounds doable. If we provided a "python2.dll", would could make the
> header files using the "restricted API" by default if Python is compiled
> with VS 2010. Extension builders could then regularly compile their
> extensions with VS 2010, or
Hi,
the buildbots are flaky because two repr() tests for userdict and
functools.partial fail every now and then. The test cases depend on a
fixed order of keyword arguments the representation of userdict and
partial instances. The improved hash randomization of PEP 456 shows its
power. I haven't s
Am 28.11.2013 10:53, schrieb Armin Rigo:
> Hi,
>
> On Thu, Nov 28, 2013 at 7:14 AM, V S, Nagendra (Nonstop Filesystems Team)
>> on NonStop "uuid.py" falls throw to random.range() call to generate the
>> random number
>
> And indeed, the random module gets identical results in both parent
> and
Hi,
Larry has granted me a special pardon to add an outstanding fix for SSL,
http://bugs.python.org/issue19509 . Right now most stdlib modules
(ftplib, imaplib, nntplib, poplib, smtplib) neither support server name
indication (SNI) nor check the subject name of the peer's certificate
properly. The
Am 30.11.2013 23:51, schrieb Antoine Pitrou:
> Small nit: what happens if the server_hostname is None (i.e. wasn't
> passed to context.wrap_socket())?
The code will raise an exception. My patch already implements a more
verbose ValueError that explains the cause of the problem. It's flaw in
code,
Am 01.12.2013 12:33, schrieb Nick Coghlan:
> Perhaps a cleaner option would be to make check_hostname read only,
> and add a secure-by-default method that allows all verification
> related settings to be adjusted at once:
>
> def set_verify_mode(mode=ssl.CERT_REQUIRED, check_hostname=True):
>
Am 30.11.2013 23:16, schrieb Guido van Rossum:
> Sounds good.
>
> Is another change for asyncio needed?
Yes, but just a small one. The match_hostname() call in
selector_events is no longer required in 3.4.
Christian
___
Python-Dev mailing list
Python-D
Am 13.12.2013 18:04, schrieb Brett Cannon:
> http://bugs.python.org/issue12837 deals with the single compiler warning
> left on OS X: a tautalogical compare in socketmodule.c that is valid
> under POSIX. I have a solution that uses pragmas to turn off
> tautological compare warnings for the single
Am 30.12.2013 15:02, schrieb Chris Angelico:
> On Tue, Dec 31, 2013 at 12:05 AM, Chris Angelico wrote:
>> On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico wrote:
>>> In another thread it was suggested that a new buildbot running as root
>>> would be of value. I've spun up a virtual machine running
On 06.01.2014 05:12, Donald Stufft wrote:
ensurepip uses —no-index so it shouldn’t be hitting the network at all.
Do you have a test to ensure that ensurepip doesn't try to use network
connections? You could e.g. mock socket.create_connection() and
socket.socket() in a custom socket module. T
On 06.01.2014 08:09, Chris Angelico wrote:
Then further down, several SSL tests attempt:
s.connect_ex(("svn.python.org", 444)))
and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
firewall's delaying things somewhat and it's timing out with a signal;
when I try manually, the co
On 06.01.2014 09:22, Chris Angelico wrote:
No, it's Debian Wheezy inside Debian Wheezy; though the outer system
is a somewhat messy one (I installed Wheezy before it was stable, and
compiled my own ALSA drivers and a few other things).
But it could well be that same issue, as it seems to involve
On 16.01.2014 16:57, Guido van Rossum wrote:
> Because somehow you can't have a slot named __doc__ *and* a docstring
> in the class. Try it. (I tried to work around this but didn't get very
> far.)
That's true for all class attributes. You can't have a slot and a class
attribute at the same time.
On 22.01.2014 12:45, Nick Coghlan wrote:
> We also have to account for the fact that an awful lot of Python
> applications are corporate ones relying on perimeter defence for
> security, or private CAs, or just self-signed certificates that their
> users have already accepted. There are limits to t
On 22.01.2014 14:55, Donald Stufft wrote:
> As an additional side note, anecdotal evidence and what not, but
> *every* time I bring this up somewhere I get at least one reply
> that looks similar to
> https://twitter.com/ojiidotch/status/425986619879866368
Yeah :(
The ssl module documentation h
On 22.01.2014 14:24, Nick Coghlan wrote:
> On 22 January 2014 23:19, Antoine Pitrou wrote:
>> On Wed, 22 Jan 2014 05:30:40 -0500
>> Donald Stufft wrote:
>>> I would like to propose that a backwards incompatible change be
>>> made to Python to make verification of hostname and certificate
>>> chai
On 22.01.2014 13:43, Jesse Noller wrote:
> I have to concur with Donald here - in the case of security, especially
> language security which directly impacts the implicit security of downstream
> applications, I should not have to opt in to the most secure defaults.
>
> Yes; this potentially bre
On 22.01.2014 15:12, Jesse Noller wrote:
> And no one reads it. I can't count the number of times I've gotten called
> into a managers office when they find out python doesn't do cert validation
> by default (and in 2, it's not been trivial) and gotten told to fix it, or we
> move off of python.
On 22.01.2014 15:36, Donald Stufft wrote:
> Last time I tried the reasoning was that Python couldn’t ship root certs
> and we couldn’t get to the OS certs everywhere. Thanks to you this
> is fixed now, so “once more unto the breach”.
The Windows situation is still not perfect, though. I'd love to
On 22.01.2014 23:20, Nick Coghlan wrote:
> However, now we have access to the system cert stores on all major
> platforms, I *do* think it's a good idea to eventually change the
> default settings to include host verification.
Somebody has revise the situation on OSX for Python 3.5 and possible
cr
On 25.01.2014 10:58, serhiy.storchaka wrote:
> http://hg.python.org/cpython/rev/d4099b8a7d0f
> changeset: 88687:d4099b8a7d0f
> user:Serhiy Storchaka
> date:Sat Jan 25 11:57:59 2014 +0200
> summary:
> Issue #20133: The audioop module now uses Argument Clinic.
>
> files:
> Mod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
this looks pretty serious -- and it caught me off guard, too. :(
https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/
Next time please inform the Python Security Response Team about any
and all issues tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 25.02.2014 15:41, Benjamin Peterson wrote:
> I'm not sure why you think it wasn't sent to security@
> https://mail.python.org/mailman/private/psrt/2014-January/001297.html
Because
>
I can't find the mail in my inbox. Perhaps it fell victim to
p
On 11.03.2014 13:18, Victor Stinner wrote:
> Hi,
>
> Thanks David! I added a summary of security improvements:
> http://docs.python.org/dev/whatsnew/3.4.html#summary-release-highlights
>
> Can someone please review it? Don't hesitate to modify the text
> directly. Check also if the summary is com
On 18.03.2014 17:46, Michael Foord wrote:
>
> On 18/03/14 16:44, Antoine Pitrou wrote:
>>
>> Hello Xavier,
>>
>> It is not obvious your message is appropriate for python-dev. It looks
>> like mere advertising; if it is not, please explain.
>>
>> To clarify what this mailing-list is about: "On this
On 23.03.2014 01:01, Antoine Pitrou wrote:
> This is a bit limited. There are remotely-exploitable security issues
> which are still open on the bug tracker; they are not
> cryptography-related, but that shouldn't make a difference.
>
> (for example the dreaded XML issues have never been properly
On 23.03.2014 02:33, Brett Cannon wrote:
> Now I have been reading this thread on my phone and I only have cursory
> understanding of what failure ssl has had as of late, so this might be
> stupid, but what if in Python 3.5 we made it so people passed in an
> explicit SSL object into the relevant A
On 24.03.2014 23:51, Andrew M. Hettinger wrote:
> I thought I'd wait until the 3.4 release before I bothered asking about
> this: http://bugs.python.org/issue20469
>
> I don't think I'm qualified to actually be writing code for the ssl
> module, but is there anything else that I can do to help?
>
On 10.04.2014 04:16, Guido van Rossum wrote:
> Yeah, this was mentioned a few times. I quipped to Nick that Red Hat's
> biggest contribution might be to take over the Windows Installer, but
> didn't bite. :-)
>
> But there's always the PSF. We may try to find some folks we trust with
> relevant ex
On 16.04.2014 04:35, Guido van Rossum wrote:
> Well, that's the part that does "import site". Anything that speeds up
> the code in Lib/site.py might help. :-)
Antoine, Victor and me have implemented a couple of speed ups for
"import site" already. I removed several unnecessary imports by
rearrang
On 2018-08-01 13:58, Michael wrote:
> a) I am looking at getting spwd integrated from AIX
>
> b) only the parameter sp_pwdp is my concern - as AIX really does not
> want to reveal the encrypted password. Rather, AIX will say '!' (meaning
> there is, or should be a shadow password, or '*' - no user
Hi,
I have some exciting news. RFC 8446 [1] for TLS 1.3 was finalized a
couple of days ago. The new TLS standard comes with several major
improvements, but also with major changes.
First some good news:
Python's ssl module not compiles with OpenSSL 1.1.1-pre. It's also able
to negotiate and estab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Argh, typo! Thanks for pointing that out, Miro. I meant to write "now
compiles with OpenSSL 1.1.1-pre".
On 2018-08-16 15:27, Christian Heimes wrote:
> First some good news: Python's ssl module not compiles with OpenSSL
> 1.1.
On 2018-09-04 16:37, 大野隆弘 wrote:
> Dear all,
>
> Have we tried cipher implementation includes AES as a standard library
> in the past?
> https://docs.python.org/3.6/library/crypto.html
>
> if possible I want to try to implement AES because famous 3rd party
> library is not maintained and general
On 2018-09-05 11:56, Victor Stinner wrote:
> Hi,
>
> Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1
> scheduled. I wanted to reply when I saw that it was scheduled for 2
> months ago:
>
> "3.7.1: 2018-07-xx"
> https://www.python.org/dev/peps/pep-0537/#maintenance-releases
>
On 2018-09-05 16:01, 大野隆弘 wrote:
> Christian, really appreciated the details. I understood.
>
> Is wrapper library like ssl module with openssl on platform also not
> good idea?
> My intention is not re-invention but single standard way as standard
> library.
>
> If I can read past discussion so
On 2018-09-06 17:03, Guido van Rossum wrote:
> FWIW I'm with Antoine here -- XML is still important and I'd like us to
> go the extra mile here, not just give up because the issues have been
> inactive for a long time. We can't control what PyYAML does, but for the
> stdlib XML code, the buck stops
On 2018-09-07 17:46, Victor Stinner wrote:
> Le ven. 7 sept. 2018 à 17:02, PMS PMS a écrit :
>> XML support in Python is critical and desired for many sectors like banking
>> or telecoms,
>> and code base based on XML is still on rise in such world.
>
> Would it be possible to send money to the
are existing and working
> counter-measures:
>
>https://docs.python.org/dev/library/xml.html
>
> Note: Christian Heimes, author of these 2 packages, told me that these
> modules may not work on Python 3.7, he didn't have time to maintain
> them recently. Maybe som
On 19/09/2018 23.12, Ned Deily wrote:
> Update: not surprisingly, there have been a number of issues that have popped
> up during and since the sprint that we would like to ensure are addressed in
> 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the
> releases. I think we
On 21/09/2018 16.26, Guido van Rossum wrote:
>> What about the small integers cache?
>
> I believe the small integers cache is only used to reduce the number of
> objects -- I don't think there's any code (in CPython itself) that just
> *assumes* that because an int is small it must be in the cach
On 30/10/2018 04.04, Ned Deily wrote:
> https://discuss.python.org/t/julien-palard-joins-the-python-release-team-as-documentation-expert/313
Welcome on board, Julien!
Thank you very much for helping out.
___
Python-Dev mailing list
Python-Dev@python.or
On 29/11/2018 17.25, Steve Dower wrote:
> On 29Nov2018 0254, Antoine Pitrou wrote:
>> I'd like to point the discussion is asymmetric here.
>>
>> On the one hand, people who don't have access to PyPI would _really_
>> benefit from a larger stdlib with more batteries included.
>>
>> On the other hand
On 29/11/2018 17.32, Antoine Pitrou wrote:
> We may ask ourselves if there is really a large difference between a
> "standard distribution" and a "standard library". The primary
> difference seems to be that the distribution is modular, while the
> stdlib is not.
Yes, there is a huge difference b
On 29/11/2018 18.23, Antoine Pitrou wrote:
>
> Le 29/11/2018 à 18:17, Christian Heimes a écrit :
>>
>> If we would keep the standard distribution of Python as it is and just
>> have a Python SIG offer an additional extended distribution on
>> python.org, then
On 29/11/2018 22.08, Nathaniel Smith wrote:
> On Thu, Nov 29, 2018 at 10:11 AM Christian Heimes
> wrote:
>> You are assuming that you can convince or force upstream developers to
>> change their project and development style. Speaking from personal
>> experience, that
On 09/01/2019 17.52, Guido van Rossum wrote:
> Hi Brian,
>
> I am glad that this is happening!
>
> I don't think you need a PEP to motivate your request -- however you
> need to submit the upstream patches, work with the CPython buildbot
> managers (Victor?) to connect your buildbots, and work wi
On 19/01/2019 11.12, Serhiy Storchaka wrote:
> I have virtually completely lost the sight of my right eye (and the loss
> is quickly progresses) and the sight of my left eye is weak. That is why
> my activity as a core developer was decreased significantly at recent
> time. My apologies to those wh
On 06/02/2019 02.09, Paul Monson via Python-Dev wrote:
> Updating OpenSSL and libffi are independent of ARM support but need to
> be done as prerequisites. OpenSSL 1.1.0 doesn't have support for ARM32
> on Windows but OpenSSL 1.1.1 does.
>
>
>
> I have OpenSSL 1.1.1a ready to check in to maste
On 07/02/2019 00.41, Ned Deily wrote:
> On Feb 6, 2019, at 18:28, Steve Dower wrote:
>> On 06Feb2019 1423, Christian Heimes wrote:
>>> Do you want to update Python 3.8 (master) only or also 3.7? I'm not
>>> strictly against updating 3.7. However we have traditiona
Hi,
today's OpenSSL release of 1.0.2r and 1.1.1b reminded me of OpenSSL's
release strategy [1]. OpenSSL 1.0.2 will reach EOL on 2019-12-31, 1.1.0
will reach EOL on 2019-09-11 (one year after release of OpenSSL 1.1.1).
First the good news: There is no need to take any action for 2.7 to 3.6.
As of
On 26/02/2019 21.31, Wes Turner wrote:
>> IMHO it's
> fine to ship the last 2.7 build with an OpenSSL version that was EOLed
> just 24h earlier.
>
> Is this a time / cost issue or a branch policy issue?
>
> If someone was to back port the forthcoming 1.1.1 to 2.7 significantly
> before the EOL da
On 29/03/2019 01.02, Victor Stinner wrote:
> Hi,
>
> I read quickly the PEP, I'm not sure that I understood it correctly,
> so here are some early questions more about the usage of the PEP, than
> its implementation.
>
>> This is not sandboxing, as this proposal does not attempt to prevent
>> mal
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 Python
> runtime or standard lib
On 28/03/2019 23.35, 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
> submit to the Steering Council.
>
> The formatted text is at https://www.python.org/dev/peps/pep-0578/
On 29/03/2019 21.10, Steve Dower wrote:
>> For example how does the importhook work in regarding of alternative
>> importers like zipimport? What does the import hook 'see' for an import
>> from a zipfile?
>
> Yes, good point. I think opening the zip file with open_for_import() is
> the right plac
On 04/04/2019 13.51, Jeroen Demeyer wrote:
> During my investigations related to low-level function/method classes, I
> came across the "instance method" class. There is a C API for it:
> https://docs.python.org/3.7/c-api/method.html
> However, it's not used/exposed anywhere in CPython, except as
>
On 05/04/2019 17.46, Guido van Rossum wrote:
> Let's stop here. This API is doing no harm, it's not a maintenance
> burden, clearly *some* folks have a use for it. Let's just keep it,
> okay? There are bigger fish to fry.
Sounds good to me. My code is 12 years ago and I can't remember any
complain
On 11/04/2019 11.45, Xin, Peixing wrote:
> Hi, Math experts:
>
> Looking at the codes below, for many math operations, CPython is checking
> errno to determine the error status even though the math function returns
> normal value back. Is it a safe solution? From the description here
> http://m
On 28/03/2019 23.35, 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
> submit to the Steering Council.
>
> The formatted text is at https://www.python.org/dev/peps/pep-0578/
On 15/04/2019 23.17, Steve Dower wrote:
> 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 som
feedback
from some Linux Kernel security engineers first.
On 01/04/2019 18.31, Steve Dower wrote:
> On 31Mar2019 0538, Christian Heimes wrote:
>> I don't like the fact that the PEP requires users to learn and use an
>> additional layer to handle native code. Although we cannot provi
On 16/04/2019 14.57, Victor Stinner wrote:
> Le mar. 16 avr. 2019 à 14:35, Christian Heimes a écrit
> :
>> * Linux: readlink("/proc/self/fd/%i")
>
> That doens't work if /proc is not mounted, which can occur in a
> container (where /proc is not mounted nor
Hi,
Steve and I worked on the final touch of the PEP during PyCon. PEP 578
[1] is now ready. As the BDFL delegate I'm honoured to accept Steve's PEP.
There is a very slim possibility that the PEP implementation might need
adjustment for Linux. I haven't got feedback from a Red Hat engineer
that w
On 15/05/2019 10.55, Ivan Pozdeev via Python-Dev wrote:
> On 15.05.2019 11:48, Antoine Pitrou wrote:
>> On Tue, 14 May 2019 18:11:14 -0700
>> Barry Warsaw wrote:
>>
>>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
>>> the rest of the Steering Council, I hereby Accept this PE
stian
PEP: 594
Title: Removing dead batteries from the standard library
Author: Christian Heimes
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 20-May-2019
Post-History:
Abstract
This PEP proposed a list of standard library modules to be re
On 20/05/2019 23.12, Andrew Svetlov wrote:
> socketserver.py is also questionable
I briefly though about the module, but didn't consider it for removal. The
http.server, xmlrpc.server, and logging configuration server are implemented on
top of the socketserver. I don't want to remove the sockets
On 20/05/2019 23.27, Antoine Pitrou wrote:
> NNTP is still quite used (often through GMane, but probably not only) so
> I'd question the removal of nntplib.
Is NNTP support important enough to keep the module in the standard library?
> cgitb used to be used by some Web frameworks in order to form
On 21/05/2019 00.13, Antoine Pitrou wrote:
> On Tue, 21 May 2019 00:06:35 +0200
> Christian Heimes wrote:
>> On 20/05/2019 23.27, Antoine Pitrou wrote:
>>> NNTP is still quite used (often through GMane, but probably not only) so
>>> I'd question the removal
On 16/05/2019 23.12, Pablo Galindo Salgado wrote:
> Hi everyone,
>
> TLDR
> =
>
> I propose to remove the current parser module and expose pgen2 as a standard
> library module.
I like to add this to PEP 594, see https://github.com/python/peps/pull/1063
Terry, thanks for connecting my PEP w
On 21/05/2019 01.06, Terry Reedy wrote:
> On 5/20/2019 6:06 PM, Christian Heimes wrote:
>
>>> Removing the crypt module would remove support for system-standard
>>> password files. I don't understand the rationale.
>>
>> Applications *must* not access sy
On 21/05/2019 02.16, Inada Naoki wrote:
> I use fileinput for several times per year.
>
> fileinput is handy tool to write single script file to analyze log files.
>
> * In such tools, I don't need real argument parser.
> * Some log files are compressed and some are not.
> It seems argparse doe
On 21/05/2019 11.49, Nathaniel Smith wrote:
> On Tue, May 21, 2019 at 2:40 AM Walter Dörwald wrote:
>>
>> On 20 May 2019, at 22:15, Christian Heimes wrote:
>>
>>> Hi,
>>>
>>> here is the first version of my PEP 594 to deprecate and eventually
>&
On 21/05/2019 12.19, Giampaolo Rodola' wrote:
> I find this one useful and would be a bit sad to see it go. FWIW I use it in
> pyftpdlib and I suppose there are other apps out there relying on UNIX
> password db for authentication. The fact that it’s a C module is also an
> incentive to leave it
101 - 200 of 1039 matches
Mail list logo
