[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 09.05.2021 14:22, Larry Hastings wrote: > On 5/9/21 3:00 AM, M.-A. Lemburg wrote: >> BTW: For better readability, I'd also not output the lines >> for every stack level in the traceback, but just the last one, >> since it's usually clear where the call to the next s

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 08.05.2021 23:55, Gregory P. Smith wrote: > Who non-hypothetically cares about a 22% pyc file size increase?  I don't > think > we should be concerned.  I'm in favor of always writing them and the 20% size > increase that results in.  If pyc size is an issue that should be its own > separate

[Python-Dev] Re: Python 0.9.1

On 18.02.2021 09:16, M.-A. Lemburg wrote: > On 18.02.2021 01:45, Brett Cannon wrote: >> If we can get a clean copy of the original sources I think we should put >> them up >> under the Python org on GitHub for posterity. > > There is already a page with Andrew's buil

[Python-Dev] Re: Python 0.9.1

On 18.02.2021 01:45, Brett Cannon wrote: > If we can get a clean copy of the original sources I think we should put them > up > under the Python org on GitHub for posterity. There is already a page with Andrew's build on python.org: https://www.python.org/download/releases/early/ but it's not

[Python-Dev] Re: Python 0.9.1

On 17.02.2021 08:00, Stefan Ring wrote: > On Wed, Feb 17, 2021 at 7:33 AM Steven D'Aprano wrote: >> >> On Tue, Feb 16, 2021 at 05:49:49PM -0600, Skip Montanaro wrote: >> >>> If someone knows how to get the original Usenet messages from what Google >>> published, let me know. >> >> I don't have

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 02.02.2021 00:33, Inada Naoki wrote: > On Tue, Feb 2, 2021 at 12:43 AM M.-A. Lemburg wrote: >> >> Hi Inada-san, >> >> thank you for adding some comments, but they are not really capturing >> what I think is missing: >> >> """

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 01.02.2021 17:51, Victor Stinner wrote: > On Mon, Feb 1, 2021 at 5:39 PM M.-A. Lemburg wrote: >> The C code is already there, but it got hidden away in the >> Python 3.3 change to new internals. > > Well, we are not in agreement and it's ok. Your objection is written &

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 01.02.2021 17:10, Victor Stinner wrote: > On Mon, Feb 1, 2021 at 4:47 PM M.-A. Lemburg wrote: >> At the very least, we should have such APIs for going from wchar_t* >> to a Python object. >> >> The alternatives you provide all require creating an intermediate >&g

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

.01.2021 07:47, Inada Naoki wrote: > Hi, Lemburg. > > I want to send the PEP to SC. > I think I wrote all your points in the PEP. Would you review it? > > Regards, > > On Tue, Aug 4, 2020 at 5:04 PM Inada Naoki wrote: >> >> On Tue, Aug 4, 2020 at 3:31 PM M.

[Python-Dev] Re: [python-committers] Re: Performance benchmarks for 3.9

On 15.10.2020 15:50, Victor Stinner wrote: > Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit : >> unpack-sequence is a micro-benchmark. (...) > > I suggest removing it. > > I removed other similar micro-benchmarks from pyperformance in the > past, since they can easily be misunderstood and

[Python-Dev] Re: [python-committers] Re: Performance benchmarks for 3.9

On 14.10.2020 17:59, Antoine Pitrou wrote: > > Le 14/10/2020 à 17:25, M.-A. Lemburg a écrit : >> >> Well, there's a trend here: >> >> [...] >> >> Those two benchmarks were somewhat faster in Py3.7 and got slower in 3.8 >> and then again in 3.9, so

[Python-Dev] Re: [python-committers] Re: Performance benchmarks for 3.9

On 14.10.2020 16:14, Antoine Pitrou wrote: > Le 14/10/2020 à 15:16, Pablo Galindo Salgado a écrit : >> Hi! >> >> I have updated the branch benchmarks in the pyperformance server and now >> they include 3.9. There are >> some benchmarks that are faster but on the other hand some benchmarks >> are

[Python-Dev] Re: [python-committers] Performance benchmarks for 3.9

ted and it didn't run in a long time :( Make sense. Would it be possible rerun the tests with the current setup for say the last 1000 revisions or perhaps a subset of these (e.g. every 10th revision) to try to binary search for the revision which introduced the change ? > On Wed, 14 Oct

[Python-Dev] Re: [python-committers] Performance benchmarks for 3.9

Hi Pablo, thanks for pointing this out. Would it be possible to get the data for older runs back, so that it's easier to find the changes which caused the slowdown ? Going to the timeline, it seems that the system only has data for Oct 14 (today):

[Python-Dev] Re: [python-committers] Farewell, Python 3.5

Thank you, Larry and the whole release team, for putting so much work into this ! On 01.10.2020 19:49, Larry Hastings wrote: > > At last!  Python 3.5 has now officially reached its end-of-life.  Since there > have been no checkins or PRs since I tagged 3.5.10, 3.5.10 will stand as the > final

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

eering > Council discussion. > Would you like to review the PEP before it? > > Regards, > > > On Thu, Jul 9, 2020 at 8:19 AM Inada Naoki wrote: >> >> On Thu, Jul 9, 2020 at 5:46 AM M.-A. Lemburg wrote: >>> - the fact that the encode APIs encoding from

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

Hi Inada-san, I am currently too busy with EuroPython to participate in longer discussions. FWIW: I intend to continue after EuroPython. In any case, thanks for writing up the PEP. Could you please add my points about: - the fact that the encode APIs encoding from a Unicode buffer to a bytes

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

On 30.06.2020 15:17, Victor Stinner wrote: > Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg a écrit : >>> I would prefer to analyze the list on a case by case basis. I don't >>> think that it's useful to expose every single encoding supported by >>> Python as a C func

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

On 28.06.2020 16:24, Inada Naoki wrote: > Hi, Lamburg. > > Thank you for quick response. > >> >> We can't just remove access to one half of a codec (the decoding >> part) without at least providing an alternative for C extensions >> to use. >> >> Py_UNICODE can be removed from the API, but only

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

On 29.06.2020 11:57, Victor Stinner wrote: > Le dim. 28 juin 2020 à 11:22, M.-A. Lemburg a écrit : >> as you may remember, I wasn't happy with the deprecations of the >> APIs in PEP 393, since there are no C API alternatives for >> the encoding APIs deprecated in the PE

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

Hi Inada-san, as you may remember, I wasn't happy with the deprecations of the APIs in PEP 393, since there are no C API alternatives for the encoding APIs deprecated in the PEP, which allow direct encoding provided by these important codecs. AFAIK, the situation hasn't changed since then. We

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24.06.2020 20:08, Guido van Rossum wrote: > On Wed, Jun 24, 2020 at 7:27 AM M.-A. Lemburg <mailto:m...@egenix.com>> wrote: > > Wow, so 19 years after PEP 275, we are indeed getting a switch > statement. Nice :-) > > > Indeed. Fortunately there are now s

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24.06.2020 16:27, M.-A. Lemburg wrote: > Wow, so 19 years after PEP 275, we are indeed getting a switch > statement. Nice :-) > > Something which struck me as odd when first scanning through the PEP > is the default case compared to other Python block statements: >

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Wow, so 19 years after PEP 275, we are indeed getting a switch statement. Nice :-) Something which struck me as odd when first scanning through the PEP is the default case compared to other Python block statements: match something: case 0 | 1 | 2: print("Small number") case [] |

[Python-Dev] Re: [capi-sig] Re: Removal of _Py_ForgetReference from public header in 3.9 issue

On 15.06.2020 11:02, Petr Viktorin wrote: > On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: >> I maintain an open source Python module in C. I'm trying to verify for >> the first time that the module still works with cpython 3.9. This >> module does *not* use the "limited" C API. >> >> In

Re: [Python-Dev] Adding a tzidx cache to datetime

On 10.05.2019 02:58, Paul Ganssle wrote: > This is only "only" for dateutil in the sense that no one other than > dateutil implements tzinfo with the interface provided. If dateutil were > /not/ already implemented with a list of offsets and their indexes, I > would still propose this, and just

Re: [Python-Dev] Farewell, Python 3.4

Thank you for having been 3.4 release manager, Larry ! On 08.05.2019 17:36, Larry Hastings wrote: > > It's with a note of sadness that I announce the final retirement of > Python 3.4.  The final release was back in March, but I didn't get > around to actually closing and deleting the 3.4 branch

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 19.11.2018 11:53, Antoine Pitrou wrote: > On Mon, 19 Nov 2018 11:28:46 +0100 > Victor Stinner wrote: >> Python internals rely on internals to implement further optimizations, >> than modifying an "immutable" tuple, bytes or str object, because you >> can do that at the C level. But I'm not

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion

Something that may change is the way they treat Github accounts, after all, MS is very much a sales driven company. But then there's always the possibility to move to Gitlab as alternative (hosted or run on PSF VMs), so I would worry too much. Do note, however, that the value in Github is not so

Re: [Python-Dev] Python startup time

On 14.05.2018 18:26, Chris Barker via Python-Dev wrote: > > > On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez > wrote: > > https://refi64.com/uprocd/ > > > very cool -- but *nix only, of course :-( > > But it seems that there is a demand

Re: [Python-Dev] Python initialization and embedded Python

On 18.11.2017 01:01, Victor Stinner wrote: > Hi, > > The CPython internals evolved during Python 3.7 cycle. I would like to > know if we broke the C API or not. > > Nick Coghlan and Eric Snow are working on cleaning up the Python > initialization with the "on going" PEP 432: >

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

On 30.05.2017 13:49, Nick Coghlan wrote: > Here's an alternate wording for the README that would focus on those > considerations without explicitly asking folks not to use the theme: > > "Note that when adopting this theme, you're also borrowing an element > of the trust and credibility

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

I'm -1 on going down the suggested route of Apple et al. for an open source language. We don't need more trademarks to "protect" ourselves against fellow open source projects. I see this whole trademark business that OSS projects are getting into in recent years in a more and more critical

Re: [Python-Dev] Is this a bug or a feature?

Please report such problems on our bug tracker: http://bugs.python.org/ In your case, Python doesn't appear to find the (right) libz shared library, which is a bit odd, but it's better to track this down on the tracker :-) On 16.02.2017 21:33, Patrick Wallinger wrote: > I'm brand new to python

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub

On 10.12.2016 10:05, David Mertz wrote: > I'm forwarding this to the PSF Trademarks committee. If there is a > violation, it's a misuse of trademark, not copyright on the code which has > the Python license stack. > > I'm on that committee and agree this is improper use. Let's see what other >

Re: [Python-Dev] Supported versions of OpenSSL

On 31.08.2016 14:02, Nick Coghlan wrote: > On 31 August 2016 at 20:20, M.-A. Lemburg <m...@egenix.com> wrote: >> ... which would then mean: Python's compatibility roadmap will >> be dictated by OpenSSL. >> >> I won't buy into that, sorry. Crypto is a helper in cer

Re: [Python-Dev] Supported versions of OpenSSL

On 31.08.2016 12:05, Christian Heimes wrote: > This was my last reply to your mails on this topic. It's clear to me > that you are not open to Cory's, Nick's or my arguments and that you > won't change your position. More replies are just a waste of my limited > time. I *am* open to arguments,

Re: [Python-Dev] Supported versions of OpenSSL

On 31.08.2016 10:43, Antoine Pitrou wrote: > On Wed, 31 Aug 2016 10:31:12 +0200 > "M.-A. Lemburg" <m...@egenix.com> wrote: >> >> I am thinking of Python users out there who are running on LTS >> OS releases simply because their IT doesn't let them run an

Re: [Python-Dev] Supported versions of OpenSSL

On 31.08.2016 10:50, Christian Heimes wrote: > On 2016-08-31 10:31, M.-A. Lemburg wrote: >> In all this discussion I have yet to find a compelling security >> relevant argument for using an 1.0.2 API which is so important >> that we cannot make this optional at runtime. &g

Re: [Python-Dev] Supported versions of OpenSSL

On 31.08.2016 01:55, Gregory P. Smith wrote: > On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg <m...@egenix.com> wrote: >>> On 29.08.2016 22:16, Christian Heimes wrote: >>> In my >>> opinion it is more than reasonable to ditch 1.0.1 and earlier. >> >>

Re: [Python-Dev] Supported versions of OpenSSL

On 29.08.2016 22:16, Christian Heimes wrote: > On 2016-08-29 21:31, M.-A. Lemburg wrote: >> On 29.08.2016 18:33, Cory Benfield wrote: >>> >>>> On 29 Aug 2016, at 04:09, M.-A. Lemburg <m...@egenix.com> wrote: >>>> >>>> On 28.08.2016 22:

Re: [Python-Dev] Supported versions of OpenSSL

On 29.08.2016 18:33, Cory Benfield wrote: > >> On 29 Aug 2016, at 04:09, M.-A. Lemburg <m...@egenix.com> wrote: >> >> On 28.08.2016 22:40, Christian Heimes wrote: >>> ... >>> I like to reduce the maintenance burden and list of supported OpenSSL &g

Re: [Python-Dev] Supported versions of OpenSSL

On 28.08.2016 22:40, Christian Heimes wrote: > ... > I like to reduce the maintenance burden and list of supported OpenSSL > versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 > will reach EOL by the end of this year, > https://www.openssl.org/policies/releasestrat.html .

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 10.06.2016 20:55, Donald Stufft wrote: > Ok, so you’re looking for how would you replicate the blocking behavior of > os.urandom that exists in 3.5.0 and 3.5.1? > > In that case, it’s hard. I don’t think linux provides any way to externally > determine if /dev/urandom has been initialized or

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 28.05.2016 23:13, Christian Heimes wrote: > On 2016-05-27 14:41, M.-A. Lemburg wrote: >> On 27.05.2016 22:58, Ryan Gonzalez wrote: >>> On May 27, 2016 3:04 PM, "Victor Stinner" <victor.stin...@gmail.com> wrote: >>>> >>>> Le ven

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 23:46, Donald Stufft wrote: > >> On May 27, 2016, at 5:41 PM, M.-A. Lemburg <m...@egenix.com> wrote: >> >> If we add this now, there should at least be an exit strategy >> to remove the code again, when OpenSSL ships with the same >> code, IMO.

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 22:58, Ryan Gonzalez wrote: > On May 27, 2016 3:04 PM, "Victor Stinner" <victor.stin...@gmail.com> wrote: >> >> Le vendredi 27 mai 2016, M.-A. Lemburg <m...@egenix.com> a écrit : >>> >>> The current patch is 1.2MB for SHA-3

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 18:41, Chris Barker wrote: > On Fri, May 27, 2016 at 9:35 AM, M.-A. Lemburg <m...@egenix.com> wrote: > >>> So if ( and that's a big if) it's possible to anticipate what will be >>> in widespread use in a couple years, getting it in now would be a good

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 17:44, Chris Barker - NOAA Federal wrote: >>> , which aren't in any wide spread use yet and >> probably won't be for quite a few years ahead. > > Anything added to the stdlib now will be in py3.6+, yes? > > Which won't be in widespread use for quite a few years yet, either. > >

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 13:03, Donald Stufft wrote: > >> On May 27, 2016, at 6:54 AM, M.-A. Lemburg <m...@egenix.com> wrote: >> >> IMO, relying on OpenSSL is a better strategy than providing >> (and maintaining) our own compatibility versions. Until OpenSSL >> h

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 27.05.2016 06:54, Raymond Hettinger wrote: > >> On May 25, 2016, at 3:29 AM, Christian Heimes wrote: >> >> I have three hashing-related patches for Python 3.6 that are waiting for >> review. Altogether the three patches add ten new hash algorithms to the >> hashlib

Re: [Python-Dev] What does a double coding cookie mean?

On 17.03.2016 15:02, Serhiy Storchaka wrote: > On 17.03.16 15:14, M.-A. Lemburg wrote: >> On 17.03.2016 01:29, Guido van Rossum wrote: >>> Should we recommend that everyone use tokenize.detect_encoding()? >> >> I'd prefer a separate utility for this somewhere, sin

Re: [Python-Dev] What does a double coding cookie mean?

On 17.03.2016 18:53, Serhiy Storchaka wrote: > On 17.03.16 19:23, M.-A. Lemburg wrote: >> On 17.03.2016 15:02, Serhiy Storchaka wrote: >>> On 17.03.16 15:14, M.-A. Lemburg wrote: >>>> On 17.03.2016 01:29, Guido van Rossum wrote: >>>>> Should we recomme

Re: [Python-Dev] What does a double coding cookie mean?

ple implementation with tests, which works in Python 2.7 and 3. > On Wed, Mar 16, 2016 at 5:05 PM, Guido van Rossum <gu...@python.org> wrote: >> On Wed, Mar 16, 2016 at 12:59 AM, M.-A. Lemburg <m...@egenix.com> wrote: >>> The only reason to read up to two lines w

Re: [Python-Dev] What does a double coding cookie mean?

On 17.03.2016 15:55, Guido van Rossum wrote: > On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka wrote: >>> Should we recommend that everyone use tokenize.detect_encoding()? >> >> Likely. However the interface of tokenize.detect_encoding() is not very >> simple. > > I just

Re: [Python-Dev] What does a double coding cookie mean?

On 16.03.2016 01:28, Guido van Rossum wrote: > I agree that the spirit of the PEP is to stop at the first coding > cookie found. Would it be okay if I updated the PEP to clarify this? > I'll definitely also update the docs. +1 The only reason to read up to two lines was to address the use of the

Re: [Python-Dev] Very old git mirror under github user "python-git"

On 28.02.2016 18:46, Georg Brandl wrote: > On 02/27/2016 11:45 PM, Matthias Bussonnier wrote: >> Hi all, >> >> >>> On Feb 27, 2016, at 14:21, Alexander Walters >> > wrote: >>> >>> Can we even ask github to pull it down and reasonably

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

On 24.02.2016 21:39, Cory Benfield wrote: > >> On 24 Feb 2016, at 12:19, M.-A. Lemburg <m...@egenix.com> wrote: >> >> On 24.02.2016 12:28, Cory Benfield wrote: >>> >>>> On 24 Feb 2016, at 10:32, Nick Coghlan <ncogh...@

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

On 24.02.2016 12:28, Cory Benfield wrote: > >> On 24 Feb 2016, at 10:32, Nick Coghlan wrote: >> >> Security Considerations >> --- >> >> Relative to the behaviour in Python 3.4.3+ and Python 2.7.9->2.7.11, this >> approach does introduce a new downgrade

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

On 12.02.2016 12:18, Victor Stinner wrote: > ping? Sorry, your email must gotten lost in my inbox. > 2016-02-08 15:18 GMT+01:00 Victor Stinner <victor.stin...@gmail.com>: >> 2016-02-04 15:05 GMT+01:00 M.-A. Lemburg <m...@egenix.com>: >>> Sometimes, yes, b

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

On 03.02.2016 22:03, Victor Stinner wrote: > Hi, > > There is an old discussion about the performance of PyMem_Malloc() > memory allocator. CPython is stressing a lot memory allocators. Last > time I made statistics, it was for the PEP 454: > "For example, the Python test suites calls malloc() ,

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

On 04.02.2016 13:29, Victor Stinner wrote: > Hi, > > 2016-02-04 11:17 GMT+01:00 M.-A. Lemburg <m...@egenix.com>: >>> Do you see any drawback of using pymalloc for PyMem_Malloc()? >> >> Yes: You cannot free memory allocated using pymalloc with the &

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

On 04.02.2016 14:25, Victor Stinner wrote: > Thanks for your feedback, you are asking good questions :-) > > 2016-02-04 13:54 GMT+01:00 M.-A. Lemburg <m...@egenix.com>: >>> There are 536 calls to the functions PyMem_Malloc(), PyMem_Realloc() >>> and PyMem_Free().

Re: [Python-Dev] More optimisation ideas

On 30.01.2016 20:15, Steve Dower wrote: > Brett tried freezing the entire stdlib at one point (as we do for parts of > importlib) and reported no significant improvement. Since that rules out code > compilation as well as the OS calls, it'd seem the priority is to execute > less code on

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 19.01.2016 00:20, Brett Cannon wrote: > On Sun, 17 Jan 2016 at 11:10 Brett Cannon wrote: > >> While doing a review of http://bugs.python.org/review/26129/ I asked to >> have curly braces put around all `if` statement bodies. Serhiy pointed out >> that PEP 7 says curly braces

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 18.01.2016 08:00, Victor Stinner wrote: > I like if without braces when the body is only one line, especially when > there is no else block. Same here. Compilers warn about these things today, so I don't think we need to go paranoid ;-) > Victor > > > Le dimanche 17 janvier 2016, Brett

Re: [Python-Dev] Branches in which to fix the SSL tests

On 07.01.2016 04:06, Martin Panter wrote: > Currently some SSL tests in the test suite are broken by a recent > certificate change at https://svn.python.org/; see > for the bug report. The tests are > broken when the test suite is run with the “-unetwork”

Re: [Python-Dev] Do windows 10 users, like windows 7 users need to install a SP before installing Python will work?

On 07.12.2015 21:50, Laura Creighton wrote: > As webmaster, I am dealing with 3 unhappy would-be python users who have > windows 10. > > Right now their first problem is that when they click on the big > yellow button here: https://www.python.org/downloads/ > > instead of getting a download of

Re: [Python-Dev] Python Language Reference has no mention of list comprehensions

On 03.12.2015 14:37, Paul Moore wrote: > On 3 December 2015 at 12:51, Laura Creighton wrote: >> Intentional or Oversight? > > Hard to find :-) > > https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries > > I went via "Atoms" in the

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

On 03.12.2015 17:09, Ryan Gonzalez wrote: > > > On December 3, 2015 8:26:23 AM CST, Laura Creighton wrote: >> In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes: >>> On 3 December 2015 at 12:51, Laura Creighton wrote: Intentional or

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

On 03.12.2015 18:30, Laura Creighton wrote: > What I would like is if it were a lot easier for a person who just > saw a list comprehension for the very first time, and was told what it > is, to have a much, much easier time finding it in the Reference Manual. Such a person should more likely be

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

On 03.12.2015 19:27, Laura Creighton wrote: > So how do we get search to work so that people in the Language > Reference who type in 'List Comprehension' get a hit? It seems that the search index is broken for at least a few documentation file releases: ok:

Re: [Python-Dev] Deleting with setting C API functions

On 02.12.2015 13:29, Serhiy Storchaka wrote: > On 02.12.15 12:06, Victor Stinner wrote: >> 2015-12-02 9:42 GMT+01:00 Serhiy Storchaka : >>> You have enough time to update your projects, and you can update them >>> uniformly for all versions. And may be you will found few weird

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

I think the PEP is a good step forward to compromise between the crypto purists (use whatever technologies makes us more secure even if it breaks things) and those who cannot upgrade their Python 2.7 because of the PEP 476 change, since it causes their applications to fail (e.g. because the

Re: [Python-Dev] Python stdlib ssl.SSLContext is missing mode setting ability

On 19.11.2015 09:14, Cory Benfield wrote: > >> On 19 Nov 2015, at 03:53, Ben Bangert wrote: >> >> In Python 2 and 3, the ssl module's SSLContext object has a way to set >> SSL options, but not to set SSL modes. >> >> The set_mode command and some of the available modes: >>

Re: [Python-Dev] Reading Python source file

On 17.11.2015 16:22, Guido van Rossum wrote: > On Tue, Nov 17, 2015 at 1:59 AM, M.-A. Lemburg <m...@egenix.com> wrote: >>> [moving from read source line by line to reading all in one go] >> We use the same simplification in eGenix PyRun's emulation of >> the

Re: [Python-Dev] Reading Python source file

On 17.11.2015 02:53, Serhiy Storchaka wrote: > I'm working on rewriting Python tokenizer (in particular the part that reads > and decodes Python > source file). The code is complicated. For now there are such cases: > > * Reading from the string in memory. > * Interactive reading from the file.

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

On 14.11.2015 23:56, Victor Stinner wrote: > These encodings are rarely used. I don't think that any text editor use > them. Editors use ascii, latin1, utf8 and... all locale encoding. But I > don't know any OS using UTF-16 as a locale encoding. UTF-32 wastes disk > space. UTF-16 is used a lot

Re: [Python-Dev] Translate Python language

On 11.11.2015 17:20, Donald Stufft wrote: > On November 11, 2015 at 11:19:07 AM, Paul Moore (p.f.mo...@gmail.com) wrote: >> On 11 November 2015 at 15:13, Christophe Bal wrote: >>> Hello. >>> >>> I'm a french teacher and I would like to use Python with young child but >>> I've a big problem. All

Re: [Python-Dev] PEP 0484 - the Numeric Tower

On 14.10.2015 01:37, Raymond Hettinger wrote: > >> On Oct 13, 2015, at 9:16 AM, Random832 wrote: >> >>> ## >>> ## Decimal has all of the methods specified by the Real abc, but it should >>> ## not be registered as a Real because decimals do not

Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

On 16.08.2015 16:08, Guido van Rossum wrote: I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics. I personally don't know what the commands for cherry-picking a revision would be. I also don't know exactly what happens

Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7

On 22.06.2015 19:03, Zachary Ware wrote: Hi, As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project

Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7

On 25.06.2015 17:12, Zachary Ware wrote: On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg m...@egenix.com wrote: On 22.06.2015 19:03, Zachary Ware wrote: Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would

Re: [Python-Dev] speed.python.org

On 23.06.2015 03:58, Zachary Ware wrote: On Thu, Jun 4, 2015 at 10:51 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Thu, Jun 4, 2015 at 4:32 PM, R. David Murray rdmur...@bitdance.com wrote: OK, so what you are saying is that speed.python.org will run a buildbot slave so that when a

Re: [Python-Dev] PEP 490: Chain exceptions at C level

On 20.06.2015 09:30, Victor Stinner wrote: Hi, I didn't get much feedback on this PEP. Since the Python 3.6 branch is open (default), it's probably better to push such change in the beginning of the 3.6 cycle, to catch issues earlier. Are you ok to chain exceptions at C level by default?

Re: [Python-Dev] speed.python.org (was: 2.7 is here until 2020, please don't call it a waste.)

On 04.06.2015 04:08, Tetsuya Morimoto wrote: If someone were to volunteer to set up and run speed.python.org, I think we could add some additional focus on performance regressions. Right now, we don't have any way of reliably and reproducibly testing Python performance. I'm very interested

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

that happen ? Cheers, fijal On Mon, Jun 1, 2015 at 1:14 PM, M.-A. Lemburg m...@egenix.com wrote: On 01.06.2015 12:44, Armin Rigo wrote: Hi Larry, On 31 May 2015 at 01:20, Larry Hastings la...@hastings.org wrote: p.s. Supporting this patch also helps cut into PyPy's reported performance

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On 01.06.2015 12:44, Armin Rigo wrote: Hi Larry, On 31 May 2015 at 01:20, Larry Hastings la...@hastings.org wrote: p.s. Supporting this patch also helps cut into PyPy's reported performance lead--that is, if they ever upgrade speed.pypy.org from comparing against Python *2.7.2*. Right,

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

You might want to have a look at eGenix PyRun, which gives you an almost complete Python runtime in 4-13MB (depending on what startup performance needs you have): http://www.egenix.com/products/python/PyRun/ On 28.05.2015 17:58, Barry Warsaw wrote: On May 28, 2015, at 11:39 AM, Donald Stufft

Re: [Python-Dev] Computed Goto dispatch for Python 2

On 28.05.2015 02:17, Parasa, Srinivas Vamsi wrote: Hi All, This is Vamsi from Server Scripting Languages Optimization team at Intel Corporation. Would like to submit a request to enable the computed goto based dispatch in Python 2.x (which happens to be enabled by default in Python 3

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 05:03, Nick Coghlan wrote: On 12 May 2015 at 04:49, M.-A. Lemburg m...@egenix.com wrote: On 11.05.2015 12:15, Nick Coghlan wrote: By contrast, the configuration file shouldn't provide a new attack vector (or simplify any existing attack vector), as if you have the permissions

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 13:21, Donald Stufft wrote: On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 12:04, Donald Stufft wrote: On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote: In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 12.05.2015 13:19, Nick Coghlan wrote: On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com wrote: Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 11.05.2015 12:47, Nick Coghlan wrote: On 11 May 2015 at 20:23, Donald Stufft don...@stufft.io wrote: On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote: We made the decision when PEP 476 was accepted that this change turned a silent security failure into a noisy one, rather

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 10.05.2015 05:04, Robert Collins wrote: On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote: On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote: By providing a way to intentionally switch off the new default, we do make people aware of the risks and that's good

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 11.05.2015 11:13, Nick Coghlan wrote: On 11 May 2015 at 18:04, M.-A. Lemburg m...@egenix.com wrote: On 10.05.2015 05:04, Robert Collins wrote: On 10 May 2015 at 11:44, Chris Angelico ros...@gmail.com wrote: On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg m...@egenix.com wrote: By providing

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 11.05.2015 12:15, Nick Coghlan wrote: On 11 May 2015 at 19:22, M.-A. Lemburg m...@egenix.com wrote: On 11.05.2015 11:13, Nick Coghlan wrote: I wouldn't be opposed to seeing that as an upstream Python 2.7.x feature, but agreement amongst redistributors on using a file-based approach

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

On 09.05.2015 02:29, Nick Coghlan wrote: On 8 May 2015 8:14 pm, M.-A. Lemburg m...@egenix.com wrote: On 08.05.2015 11:36, Nick Coghlan wrote: On 8 May 2015 6:52 pm, M.-A. Lemburg m...@egenix.com wrote: On 07.05.2015 04:30, Nick Coghlan wrote: Can we please make the monkeypatch a regular

Re: [Python-Dev] PYTHONHTTPSVERIFY env var (was: Clarification of PEP 476 opting out section)

On 07.05.2015 04:30, Nick Coghlan wrote: Can we please make the monkeypatch a regular part of Python's site.py which can enabled via an environment variable, say export PYTHONHTTPSVERIFY=0. See http://bugs.python.org/issue23857 for the discussion. ... I actually do think it would be good to

  1   2   3   4   5   6   7   8   9   10   >