Re: [Python-ideas] New PyThread_tss_ C-API for CPython

On Fri, 16 Dec 2016 13:07:46 +0100 Erik Bray wrote: > Greetings all, > > I wanted to bring attention to an issue that's been languishing on the > bug tracker since last year, which I think would best be addressed by > changes to CPython's C-API. The original issue is at >

Re: [Python-ideas] Move some regrtest or test.support features into unittest?

On Mon, 18 Sep 2017 12:16:35 +0200 Victor Stinner wrote: > Antoine: > >> * skip a test if it allocates too much memory, command line argument > >> to specify how many memory a test is allowed to allocate (ex: > >> --memlimit=2G for 2 GB of memory) > > > > That would be

Re: [Python-ideas] Move some regrtest or test.support features into unittest?

On Wed, 13 Sep 2017 15:42:56 +0200 Victor Stinner wrote: > I would like to see if and how we can integrate/move some regrtest > features into the unittest module. Example of regrtest features: > > * skip a test if it allocates too much memory, command line argument > to

Re: [Python-ideas] Hexadecimal floating literals

Le 22/09/2017 à 19:15, Tim Peters a écrit : > I've seen plenty of people on StackOverflow who (a) don't understand > hex notation for integers; and/or (b) don't understand scientific > notation for floats. Nothing is self-evident about either; they both > have to be learned at first. Sure.

Re: [Python-ideas] Add pop_callback to deque signature

On Wed, 4 Oct 2017 08:47:46 +0300 Serhiy Storchaka wrote: > 04.10.17 07:58, Nick Coghlan пише: > > For deque specifically, I like Steven D'Aprano's suggestion of a > > "__dropped__" or "__discard__" subclassing API that makes it > > straightforward to change the way that

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

On Sun, 15 Oct 2017 01:46:50 +1000 Nick Coghlan wrote: > > Might it make more sense to have a parallel *module* that works with a > different base data type rather than parallel functions within the existing > API? > > That is, if folks wanted to switch to 64-bit nanosecond

[Python-ideas] Why not picoseconds?

Since new APIs are expensive and we'd like to be future-proof, why not move to picoseconds? That would be safe until clocks reach the THz barrier, which is quite far away from us. Regards Antoine. On Fri, 13 Oct 2017 16:12:39 +0200 Victor Stinner wrote: > Hi, > >

Re: [Python-ideas] Why not picoseconds?

On Sun, 15 Oct 2017 22:00:10 -0700 Guido van Rossum wrote: > On Sun, Oct 15, 2017 at 8:40 PM, Nick Coghlan wrote: > > > Hopefully by the time we decide it's worth worrying about picoseconds in > > "regular" code, compiler support for decimal128 will be

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

On Fri, 13 Oct 2017 16:57:28 +0200 Stefan Behnel wrote: > Victor Stinner schrieb am 13.10.2017 um 16:12: > > I would like to add new functions to return time as a number of > > nanosecond (Python int), especially time.time_ns(). > > I might have missed it while skipping

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

On Sat, 14 Oct 2017 10:49:11 +0300 Serhiy Storchaka wrote: > 13.10.17 17:12, Victor Stinner пише: > > I would like to add new functions to return time as a number of > > nanosecond (Python int), especially time.time_ns(). > > > > It would enhance the time.time() clock

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, 7 Sep 2017 21:08:48 -0700 Nathaniel Smith wrote: > > Awesome, thanks for bringing numbers into my wooly-headed theorizing :-). > > On my laptop I actually get a worse result from your benchmark: 531 ms > for 100 MB == ~200 MB/s round-trip, or 400 MB/s one-way. So yeah, >

Re: [Python-ideas] Changes to the existing optimization levels

On Thu, 28 Sep 2017 12:48:15 -0600 Diana Clarke wrote: > > 2) Added a new command line option N that allows you to specify > any number of individual optimization flags. > > For example: > > python -N nodebug -N noassert -N nodocstring We could

Re: [Python-ideas] Changes to the existing optimization levels

On Fri, 29 Sep 2017 17:33:11 +1000 Nick Coghlan wrote: > > That said, we may also want to consider a couple of other options > related to changing the meaning of *existing* parameters to these > APIs: > > 1. We have the PyCompilerFlags struct that's currently only used to >

Re: [Python-ideas] Add pop_callback to deque signature

On Tue, 3 Oct 2017 22:04:46 +1100 Steven D'Aprano wrote: > > If it were possible to have a lightweight sequence data structure with > fast O(1) random access AND insertion/deletion at the same time, that > would be a candidate to replace both lists and deques in the

Re: [Python-ideas] Changes to the existing optimization levels

On Tue, 3 Oct 2017 09:42:40 -0600 Diana Clarke wrote: > - mixed-bag -X options are less discoverable than just adding a > new command line option (like -N or -OOO) For such a feature, I think being less discoverable is not really a problem. I don't think many

Re: [Python-ideas] Add pop_callback to deque signature

On Tue, 3 Oct 2017 10:13:53 -0600 Chris Barker <chris.bar...@noaa.gov> wrote: > On Tue, Oct 3, 2017 at 5:22 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > Daniel Stutzbach's blist is well-known at this point: > > http://stutzbachenterprises.co

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Mon, 13 Nov 2017 12:32:06 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 13 November 2017 at 04:38, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Sun, 12 Nov 2017 12:20:45 + > > Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Mon, 13 Nov 2017 11:17:54 +0100 Petr Viktorin wrote: > > > > Wow. I had forgotten Debian could be such a user-hostile > > distribution. I'm not sure what the reason would be to use it as a > > basis for a training course in Python programming, then (other than the > >

Re: [Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

On Wed, 22 Nov 2017 17:11:53 +1100 Chris Angelico wrote: > On Wed, Nov 22, 2017 at 3:55 PM, Greg Ewing > wrote: > > Chris Angelico wrote: > >> > >> So the question is more: why, with Python being the way it is, do the > >> heap functions operate

Re: [Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

On Wed, 22 Nov 2017 00:22:00 -0600 Nick Timkovich wrote: > > Functions are great. I'm a big fan of functions. However, > > 1. Once there are several that all have the same thing as an argument: > thing_operation1(thing, arg), thing_operation2(thing, arg)...it's about >

Re: [Python-ideas] Proposal: allow length_hint to specify infinite iterators

On Wed, 29 Nov 2017 09:39:57 +0200 Serhiy Storchaka wrote: > 29.11.17 03:34, Steven D'Aprano пише: > > This wastes the opportunity to fail fast on operations which cannot > > possibly succeed, e.g. list(count()) must eventually fail with > > MemoryError. Or worse: if the OS

[Python-ideas] PEP 505 vs matrix multiplication

On Wed, 29 Nov 2017 18:14:36 +1000 Nick Coghlan wrote: > > As far as utility goes, I put it in a similar category to matrix > multiplication: if you don't need it, you don't need it, but when you > do need it, you need it a *lot*. As someone who appreciates both the matrix

Re: [Python-ideas] a sorting protocol dunder method?

On Mon, 4 Dec 2017 19:37:02 + Barry Scott wrote: > I wondered what the performance would be and tested the following code: > [...] > > it outputs this for my with python 3.6.0 > > 1 > key 0.010628s 1 calls > lt 0.053690s 119886 calls > > It seems that

Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, 14 Nov 2017 12:14:50 +1000 Nick Coghlan wrote: > > > > I don't think Windows ever had python2.exe/python3.exe, but I could be > > wrong. > > Not that I'm aware of in the python.org installers, and I don't think > ActivePython does either. I'm less sure about

Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, 14 Nov 2017 07:45:09 +0100 Michel Desmoulin wrote: > > I think it's wrong to have a different setup on different plateforms. > Python is a portable language. It's also a language you use for quick > scripts and from a lot of non professional devs. > > Unifying

Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, 14 Nov 2017 13:28:20 +0100 Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 14 Nov 2017 12:14:50 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: > > > > > > I don't think Windows ever had python2.exe/python3.exe, but I could be > >

Re: [Python-ideas] Allow additional separator character in variables

On Sun, 19 Nov 2017 09:38:17 +0200 Serhiy Storchaka wrote: > 19.11.17 04:01, Mikhail V пише: > > Python allows underscore character as a separator in variables. > > This is better than nothing, still it does not make the look much better. > > > > **Proposal**: allow

Re: [Python-ideas] Looking for input to help with the pip situation

On Sun, 12 Nov 2017 23:18:26 +1000 Nick Coghlan wrote: > > We haven't forgotten our early years - we've just spent years (both > individually and collectively) working on the problem of helping > people get started with software development, and thus have a very > good idea

[Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Sun, 12 Nov 2017 12:20:45 + Paul Moore wrote: > > > Well, not exactly. Do you do python -m venv, or py -x.x -m venv or > > pythonx -m venv ? Wait, it's not installed by default on debian. > > Seriously? Debian don't provide venv in the standard Python install? >

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

Hi Stephan, Le 12/11/2017 à 20:24, Stephan Houben a écrit : > Hi Antoine, > > The venv module is included, > however the pyvenv script is in a separate package > python3.5-venv . Thanks for the correction. That's definitely a silly decision -- especially as the "pyvenv" script must be very

Re: [Python-ideas] Importance of noticing new signals

On Fri, 3 Nov 2017 17:22:07 +0200 Koos Zevenhoven wrote: > > Maybe you are concerned about whether some nuances and recent changes to > signal handling could lead to harmful change in behavior in some meaningful > edge cases? I can at least say that my PyErr_PROBE_SIGNALS()

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On Fri, 3 Nov 2017 16:04:43 +0100 Stéfane Fermigier wrote: > I use typing quite systematically nowadays, even for projects that don't > use mypy (for historical reasons: bringing an older code base to zero mypy > issues can be quite time-consuming). > > For instance, adding

Re: [Python-ideas] Proposal to change Python version release cycle

Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: > Hello, > > one of my long standing ideas to improve Python is to adjust the > release cycle and version number handling. In short, to simplify it. There has been ample discussion in the past about changing our

Re: [Python-ideas] Proposal to change Python version release cycle

On Sat, 4 Nov 2017 16:10:32 +0100 Wolfgang wrote: > > Another possibility is to change only the versioning > to major.minor instead of major.minor.patch. Then having > a simpler versioning scheme for other Python implementations > as only benefit (and the simplification to

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On Sun, 5 Nov 2017 13:46:59 +1000 Nick Coghlan wrote: > * ensurepip gains the ability to also install bundled wheel files Why? Why wouldn't you put the wheel directly in site-packages on install? Regards Antoine. ___

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

Le 05/11/2017 à 14:30, Paul Moore a écrit : > On 5 November 2017 at 10:48, Antoine Pitrou <solip...@pitrou.net> wrote: >> On Sun, 5 Nov 2017 13:46:59 +1000 >> Nick Coghlan <ncogh...@gmail.com> wrote: >>> * ensurepip gains the ability to also install bundled whe

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On Sun, 5 Nov 2017 18:22:11 + Paul Moore <p.f.mo...@gmail.com> wrote: > On 5 November 2017 at 14:47, Antoine Pitrou <anto...@python.org> wrote: > > > > Le 05/11/2017 à 14:30, Paul Moore a écrit : > >> On 5 November 2017 at 10:48, Antoine Pitrou <solip.

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On Mon, 6 Nov 2017 07:30:35 +0100 Michel Desmoulin wrote: > Le 06/11/2017 à 07:07, Nick Coghlan a écrit : > > > It's the default on Unix as well - you have to do "make install > > ENSUREPIP=no" to avoid getting it. (And some distros also modify their > > Python

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

On Mon, 6 Nov 2017 16:07:56 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 6 November 2017 at 05:00, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 5 November 2017 at 18:40, Antoine Pitrou <solip...@pitrou.net> wrote: > >> I think typing shouldn't r

[Python-ideas] Importance of noticing new signals

On Wed, 1 Nov 2017 20:29:56 +0200 Koos Zevenhoven wrote: > > ​From a correctness point of view, that is absolutely great: if > PyErr_CheckSignals() is called, it is guaranteed to notice a new signal > regardles of how small the number of picoseconds after the `is_tripped` >

Re: [Python-ideas] Importance of noticing new signals

On Thu, 2 Nov 2017 14:57:12 +0200 Koos Zevenhoven wrote: > > Now, is the "sequentially consistent" ordering on is_tripped sufficient > > to guarantee that signals won't be missed on a weak-ordering platform? > > I *think* so, but an expert would need to check that code (or we >

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On Fri, 8 Dec 2017 14:30:00 +0200 Serhiy Storchaka wrote: > > NumPy integers implement __index__. That doesn't help if a function calls e.g. PyLong_AsLongAndOverflow(). Regards Antoine. ___ Python-ideas mailing list

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On Fri, 8 Dec 2017 11:41:10 +0100 Erik Bray wrote: > > I ran into this because I was passing an object that implements > __int__ to the maxlen argument to deque(). On Python 2 this used > PyInt_AsSsize_t which does fall back to calling __int__, whereas > PyLong_AsSsize_t

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On Fri, 8 Dec 2017 13:26:48 +0200 Serhiy Storchaka wrote: > > > Currently the following functions fall back on __int__ where available: > > > > PyLong_AsLong > > PyLong_AsLongAndOverflow > > PyLong_AsLongLong > > PyLong_AsLongLongAndOverflow > > PyLong_AsUnsignedLongMask >

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On Fri, 8 Dec 2017 15:12:30 +0100 Erik Bray <erik.m.b...@gmail.com> wrote: > On Fri, Dec 8, 2017 at 1:52 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Fri, 8 Dec 2017 14:30:00 +0200 > > Serhiy Storchaka <storch...@gmail.com> > > wrote: >

Re: [Python-ideas] a sorting protocol dunder method?

On Mon, 4 Dec 2017 08:45:55 +0200 Serhiy Storchaka wrote: > 04.12.17 01:06, Chris Barker пише: > > So: has this already been brought up and rejected? > > https://bugs.python.org/issue20632 > > > Am I imagining the performance benefits? > > This will add an additional

Re: [Python-ideas] a sorting protocol dunder method?

On Sun, 3 Dec 2017 15:06:02 -0800 Chris Barker wrote: > I can't believe this hasn't been brought up before, but searching the web, > and python-ideas, and all the PEPs has found nothing (could be my lame > google-fu), so here goes: > > Recent python has moved toward a

Re: [Python-ideas] a sorting protocol dunder method?

On Mon, 4 Dec 2017 23:16:11 +1100 Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Dec 04, 2017 at 12:06:38PM +0100, Antoine Pitrou wrote: > > > There are definitely advantages. Sorting calls __lt__ for each > > comparison (that is, O(n log n) times) while __key__

Re: [Python-ideas] a sorting protocol dunder method?

On Mon, 4 Dec 2017 12:19:07 + Paul Moore wrote: > On 4 December 2017 at 11:41, Steven D'Aprano wrote: > > On Sun, Dec 03, 2017 at 10:48:18PM -0800, Carl Meyer wrote: > >> I think this is an interesting idea, and I don't believe that either > >>

Re: [Python-ideas] a sorting protocol dunder method?

On Mon, 4 Dec 2017 15:50:31 +0200 Serhiy Storchaka wrote: > > >> Yes, it is too special-case. I don't see any advantages in comparison > >> with defining the __lt__ method. > > > > There are definitely advantages. Sorting calls __lt__ for each > > comparison (that is,

Re: [Python-ideas] (no subject)

On Tue, 5 Dec 2017 02:52:44 +1100 Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Dec 04, 2017 at 01:52:19PM +0100, Antoine Pitrou wrote: > > On Mon, 4 Dec 2017 23:16:11 +1100 > > Steven D'Aprano <st...@pearwood.info> wrote: > > > On Mon, Dec 04, 2017

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

On Sun, 29 Oct 2017 17:54:22 +1000 Nick Coghlan wrote: > > The underlying problem is that our reasons for omitting these particular > libraries from the standard library relate mainly to publisher side > concerns like the logistics of ongoing bug fixing and support, *not* end

Re: [Python-ideas] install pip packages from Python prompt

On Tue, 31 Oct 2017 01:44:10 +1000 Nick Coghlan wrote: > > A few specific notes here: > > 1. As you say, this sort of already works in notebooks, since instructors > can say to run "!pip install requests" and then restart the language kernel. > 2. We could probably replicate

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

On Sun, 29 Oct 2017 11:44:52 + Paul Moore <p.f.mo...@gmail.com> wrote: > On 29 October 2017 at 09:51, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Sun, 29 Oct 2017 17:54:22 +1000 > > Nick Coghlan <ncogh...@gmail.com> wrote: > >> This means t

Re: [Python-ideas] Thread.__init__ should call super()

On Fri, 27 Oct 2017 13:59:01 -0700 Ilya Kulakov wrote: > Since one of the legit use-cases of using the Thread class is subclassing, > I think it's __init__ should call super() to support cooperative inheritance. Not to derail this thread, but I find it much clearer to use

Re: [Python-ideas] Verbatim names (allowing keywords as names)

On Wed, 16 May 2018 09:13:52 +0100 Paul Moore wrote: > On 16 May 2018 at 01:41, Steven D'Aprano wrote: > > Inspired by Alex Brault's post: > > > > https://mail.python.org/pipermail/python-ideas/2018-May/050750.html > > > > I'd like to suggest we copy

Re: [Python-ideas] String and bytes bitwise operations

Indeed, at this point Numpy sounds like the ideal solution for such use cases. Regards Antoine. On Thu, 17 May 2018 13:06:59 +0200 Stephan Houben wrote: > Seems you want numpy: > > >>> import numpy > >>> numpy.frombuffer(b"Hello", dtype=numpy.uint8) ^ >

Re: [Python-ideas] String and bytes bitwise operations

I agree with Steven. XORing unicode strings doesn't make sense, and is pointless anyway. The only interesting question is whether we want to add bytewise operations to the stdlib. Regards Antoine. On Thu, 17 May 2018 23:13:22 +1000 Steven D'Aprano wrote: > On Thu, May

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

On Tue, 15 May 2018 21:51:20 +1200 Greg Ewing wrote: > Ethan Furman wrote: > > Part of the point of the proposal is to be able to use existing keywords > > (at least, I thought it was). > > Mainly it's so that *new* keywords can be added to the language > without

Re: [Python-ideas] Remember the Vasa

On Mon, 18 Jun 2018 03:49:35 -0700 (PDT) Paddy3118 wrote: > I thought it might be helpful for the Python community to be aware of the > growth issues that the C++ community has/is discussing, at the moment. I am > *not > *saying we have those same issues, but we might know to avoid similar >

Re: [Python-ideas] Approximately equal operator

On Fri, 15 Jun 2018 14:38:22 -0300 Andre Roberge wrote: > > Here's a sample session for demonstration purpose... > > $ python -m experimental > experimental console version 0.9.5. [Python version: 3.6.1] > > ~~> 0.1 + 0.2 > 0.30004 > ~~> 0.1 + 0.2 == 0.3 > False > ~~> from

Re: [Python-ideas] Let try-except check the exception instance

On Thu, 31 May 2018 14:00:24 -0400 Alexander Belopolsky wrote: > > Is this really true? Consider the following simple code > > class E(Exception): > def __init__(self): > print("instantiated") > > try: > raise E > except E: > pass > > Is it truly necessary to instantiate

Re: [Python-ideas] exception instantiation philosophy and practice [was: Let try-except check the exception instance]

On Thu, 31 May 2018 07:49:58 -0700 Ethan Furman wrote: > On 05/31/2018 07:36 AM, Nick Coghlan wrote: > > > The exception machinery deliberately attempts to avoid instantiating > > exception objects whenever it can, but that gets > > significantly more difficult if we always need to create the

Re: [Python-ideas] Correct way for writing Python code without causing interpreter crashes due to parser stack overflow

The OP says "crash" (implying some kind of segfault) but here the snippet raises a mere exception: Python 2.7.12 (default, Dec 4 2017, 14:50:18) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>

Re: [Python-ideas] POPT (Python Ob ject Provider Threads)

On Tue, 19 Jun 2018 16:47:46 +0200 Martin Bammer wrote: > Hello, > > because Python is a very dynamic language the memory management is heavily > used. A lot of time is used for creating (reserve memory and fill object > structure with data) and destroying objects. Do you have numbers about

Re: [Python-ideas] Copy (and/or pickle) generators

On Wed, 20 Jun 2018 12:15:18 -0400 Yury Selivanov wrote: > > > Finally, another comment made the point that there wasn't a strong use case > > given for it. With the data science libraries that have sprung up around > > Python in the intervening years, I believe there now is one. > > As

Re: [Python-ideas] random.sample should work better with iterators

On Tue, 26 Jun 2018 23:52:55 -0500 Tim Peters wrote: > > In Python today, the easiest way to spell Abe's intent is, e.g., > > >>> from heapq import nlargest # or nsmallest - doesn't matter > >>> from random import random > >>> nlargest(4, (i for i in range(10)), key=lambda x: random()) >

Re: [Python-ideas] Have a "j" format option for lists

On Wed, 9 May 2018 09:39:08 -0300 Facundo Batista wrote: > This way, I could do: > > >>> authors = ["John", "Mary", "Estela"] > >>> "Authors: {:, j}".format(authors) > 'Authors: John, Mary, Estela' > > In this case the join can be made in the format yes, but this proposal > would be very

Re: [Python-ideas] Change magic strings to enums

On Thu, 26 Apr 2018 08:38:43 +0100 Ivan Levkivskyi wrote: > On 25 April 2018 at 12:01, Serhiy Storchaka > wrote: > > > 25.04.18 13:15, Ivan Levkivskyi пише: > > > >> Hm, this is what I wanted to know. I think by

Re: [Python-ideas] Objectively Quantifying Readability

Yes, it seems that this study has many limitations which don't make its results very interesting for our community. I think the original point was that readability *can* be studied rationnally and scientifically, though. Regards Antoine. On Tue, 1 May 2018 09:00:44 +0200 Jacco van Dorp

Re: [Python-ideas] A way to subscript a single integer from bytes

Hi Ken, On Tue, 1 May 2018 19:22:52 +0800 Ken Hilton wrote: > > So I'm pretty sure everyone here is familiar with how the "bytes" object > works in Python 3. It acts mostly like a string, with the exception that > 0-dimensional subscripting (var[idx]) returns an integer,

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

On Sat, 30 Dec 2017 00:43:07 +1000 Nick Coghlan wrote: > > > That doesn't change my other point that some > > functions that could previously take non-int arguments can no > > longer--if we agree on that at least then I can set about making a bug > > report and fixing it.

Re: [Python-ideas] Improve ABCs _dump_registry() readability

On Sun, 31 Dec 2017 19:31:06 +0100 Ivan Levkivskyi wrote: > On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas < > python-ideas@python.org> wrote: > > > > > >I guess a PR to fix the registry output would make sense (first file a > > bug on bugs.python.org

Re: [Python-ideas] make Connections iterable

On Tue, 9 Jan 2018 08:39:06 -0800 Nathaniel Smith wrote: > On Jan 9, 2018 04:12, "Random832" wrote: > > On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: > > If you view them as comparable to subprocess pipes, then it can be > > surprising that they're

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Thu, 11 Jan 2018 05:18:43 -0800 Nathaniel Smith wrote: > I'm not an expert here or anything, but from what we've been hearing it > sounds like it must be used by all standard-compliant HTML parsers. I don't > *like* the standard much, but I don't think that the stdlib should

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Wed, 10 Jan 2018 16:24:33 -0800 Chris Barker wrote: > On Wed, Jan 10, 2018 at 11:04 AM, M.-A. Lemburg wrote: > > > I don't believe it's a good strategy to create the confusion that > > WHATWG is introducing by using the same names for non-standard > >

Re: [Python-ideas] make Connections iterable

On Tue, 9 Jan 2018 20:46:35 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 9 January 2018 at 20:07, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Mon, 8 Jan 2018 21:22:56 -0800 > > Nathaniel Smith <n...@pobox.com> wrote: > >> I'm surprised that

Re: [Python-ideas] make Connections iterable

On Mon, 8 Jan 2018 21:22:56 -0800 Nathaniel Smith wrote: > > The only documented error from multiprocessing.Connection.recv is EOFError, > which is basically equivalent to a StopIteration. Actually recv() can raise an OSError corresponding to any system-level error. > I'm

Re: [Python-ideas] Adding str.isascii() ?

On Fri, 26 Jan 2018 17:42:31 +0900 INADA Naoki wrote: > > If str has str.isascii() method, it can be simpler: > > `if s.isascii() and s.isdigit():` > > I want to add it in Python 3.7 if there are no opposite opinions. +1 from me. Regards Antoine.

Re: [Python-ideas] Adding str.isascii() ?

On Fri, 26 Jan 2018 22:33:36 +0900 INADA Naoki wrote: > > > > Can you create a simple test-case that proves this? > > Sure. I think the question assumed "without writing custom C or ctypes code that deliberately builds a non-conformant unicode object" ;-) Regards

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On Tue, 30 Jan 2018 09:14:06 -0800 Chris Barker wrote: > On Sat, Jan 27, 2018 at 10:14 PM, Nick Coghlan wrote: > > > More broadly, the current lack of perceived commercial incentives for > > large corporations to invest millions in offering a faster

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On Mon, 29 Jan 2018 23:24:43 -0500 Barry Warsaw wrote: > > This is often undervalued, but shouldn't be! Moore's Law doesn't apply > to humans, and you can't effectively or cost efficiently scale up by > throwing more bodies at a project. Moore's Law doesn't really apply to

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On Sat, 27 Jan 2018 22:18:08 +0100 Pau Freixes wrote: > > Correct me if I'm wrong, but most of you argue that the proper Zen of > Python - can we say it mutability [1]? as Victor pointed out - that > allow the user have the freedom to mutate objects in runtime goes in > the

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

On Mon, 19 Feb 2018 20:15:27 +0100 Stefan Behnel wrote: > Nick Coghlan schrieb am 02.02.2018 um 06:47: > > to make the various extension module authoring tools > > easier to discover, rather than having folks assuming that handcrafted > > calls directly into the CPython C API

[Python-ideas] Toxic forum

On Sun, 12 Aug 2018 23:56:24 -0500 Abe Dillon wrote: > > This forum is looking more and more toxic. I've explained myself over and > over again. I just wanted to +1 Steven's original comment. This is > ridiculous. I guess I've pissed of the good-old-boys by calling out > Steven's unnecessary

Re: [Python-ideas] REPL features

On Wed, 22 Aug 2018 09:38:57 -0700 Chris Barker via Python-ideas wrote: > On Tue, Aug 21, 2018 at 3:07 PM, Jonathan Fine wrote: > > > > Maybe this is something Python's REPL should do? > > > > Good idea. > > > > I can't find (with very little effort) any documentation of this, but I > have

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, 18 Jul 2018 08:21:31 +0100 Ronald Oussoren via Python-ideas wrote: > Some past attempts at getting rid of the GIL used atomic inc/dec, and that > resulted in bad performance because these instructions aren’t cheap. Please read in context: we are not talking about making all refcounts

Re: [Python-ideas] Do not block threads when pickle/unpickle

Hi, On Mon, 16 Jul 2018 19:56:34 +0200 Martin Bammer wrote: > Hi, > > the old and slow python implementation of pickle didn't block background > thread. > > But the newer C-implementation blocks other threads while dump/load is > running. This is a fair comment. Please open an issue on

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Sun, 15 Jul 2018 20:21:56 -0700 Nathaniel Smith wrote: > > If you need shared-memory threads, on multiple cores, for CPU-bound > logic, where the logic is implemented in Python, then yeah, you > basically need a free-threaded implementation of Python. Jython is > such an implementation. PyPy

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Mon, 16 Jul 2018 07:00:34 +0200 Stephan Houben wrote: > What about the following model: you have N Python interpreters, each with > their own GIL. Each *Python* object belongs to precisely one interpreter. This is roughly what Eric's subinterpreters approach tries to do. Regards Antoine.

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Mon, 16 Jul 2018 18:00:37 +0100 MRAB wrote: > Could you explicitly share an object in a similar way to how you > explicitly open a file? > > The shared object's refcount would be incremented and the sharing > function would return a proxy to the shared object. > > Refcounting in the

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, 23 Jul 2018 11:12:45 -0400 David Mertz wrote: > > The particular names I use are nothing special, and better ones might be > found. I just called the class NoneAware and the "escape" method > `.unbox()` because that seemed intuitive at first brush. > > I don't disagree that needing to

Re: [Python-ideas] PEP 505: None-aware operators

On Sun, 22 Jul 2018 22:43:15 +0200 "Giampaolo Rodola'" wrote: > On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico wrote: > > > > On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola' > > wrote: > > > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico wrote: > > > I find it less explicit mainly

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, 23 Jul 2018 06:53:53 +1000 Chris Angelico wrote: > > >> Which is back to what Steven said: people demand such a high > >> bar for new syntax that few existing pieces of syntax would pass it. > > > > Probably. That's what happens when a language is mature. Personally I > > don't think

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 12:38, Steve Dower a écrit : > > General comment to everyone (not just Antoine): these arguments have > zero value to me. Feel free to keep making them, but I am uninterested. So you're uninterested in learning from past mistakes? You sound like a child who thinks their

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, 23 Jul 2018 10:51:31 +0100 Steve Dower wrote: > > Which is the most important operator? > - > > Personally, I think '?.' is the most valuable. For me, it's the most contentious. The fact that a single '?' added to a regular line of Python code can

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 12:25, Steve Dower a écrit : > On 23Jul2018 1111, Antoine Pitrou wrote: >> On Mon, 23 Jul 2018 10:51:31 +0100 >> Steve Dower wrote: >>> >>> Which is the most important operator? >>> - >>>

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 13:09, Steve Dower a écrit : > On 23Jul2018 1145, Antoine Pitrou wrote: >> >> Le 23/07/2018 à 12:38, Steve Dower a écrit : >>> >>> General comment to everyone (not just Antoine): these arguments have >>> zero value to me. Feel free

Re: [Python-ideas] PEP 505: None-aware operators

On Thu, 19 Jul 2018 19:11:33 +1000 Chris Angelico wrote: > On Thu, Jul 19, 2018 at 4:06 PM, Greg Ewing > wrote: > > Chris Angelico wrote: > >> > >> I'd love to hear an explanation of WHY this doesn't look like Python > >> any more. For instance, is the + operator somehow wrong for Python, >

Re: [Python-ideas] PEP 505: None-aware operators

This is adding a whole range of new operators without enough of a use case. It is also making code harder to read, as evaluation can stop at any of the "?*" operators. And it looks like noise (or like Perl 6, which is the same). There is a use case I sympathize with: the argument-is-None

  1   2   3   >