Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Tue, 21 Apr 2015 at 09:59 Cory Benfield wrote: [...] > Further, Python's type system is not sufficiently flexible to allow > library authors to adequately specify the types their code actually > works on. I need to be able to talk about interfaces, because > interfaces are the contract around which APIs are build in Python, but > I cannot do that with this system in a way that makes any sense at > all. To even begin to be useful for library authors this PEP would > need to allow some kind of type hierarchy that is *not* defined by > inheritance, but instead by interfaces. We've been discouraging use of > 'type' and 'isinstance' for years because they break duck typing, but > that has *nothing* on what this PEP appears to do to duck typing. > > This is why I feel like this PEP may be a real threat to duck typing. If people constantly get told by their editor / IDE that they are calling function with the wrong argument types, what are they going to do? They may start adopting the same approach as in Java / C++ etc... where interfaces must be explicitly defined and the practice of duck typing may become forgotten because discouraged by the tools programmers use. I guess what I'm saying is that this could encourage a very significant cultural change in the way Python code is written towards a less flexible mindset. -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await in Python; v2
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote: > > Hi python-dev, > > I'm moving the discussion from python-ideas to here. > > The updated version of the PEP should be available shortly > at https://www.python.org/dev/peps/pep-0492 > and is also pasted in this email. > Hi Yury, Having read this very interesting PEP I would like to make two remarks. I apologise in advance if they are points which have already been discussed. 1. About the 'async for' construct. Each iteration will create a new coroutine object (the one returned by Cursor.__anext__()) and it seems to me that it can be wasteful. In the example given of an 'aiterable' Cursor class, probably a large number of rows will fill the cursor buffer in one call of cursor._prefetch(). However each row that is iterated over will involve the creation execution of a new coroutine object. It seems to me that what is desirable in that case is that all the buffered rows will be iterated over as in a plain for loop. 2. I think the semantics of the new coroutine objects could be defined more clearly in the PEP. Of course they are pretty obvious when you know that the coroutines are meant to replace asyncio.coroutine as described in [1]. I understand that this PEP is mostly for the benefit of asyncio, hence mainly of interest of people who know it. However I think it would be good for it to be more self-contained. I have often read a PEP as an introduction to a new feature of Python. I feel that if I was not familiar with yield from and asyncio I would not be able to understand this PEP, even though potentially one could use the new constructs without knowing anything about them. Cheers, -- Arnaud Delobelle [1] https://docs.python.org/3/library/asyncio-task.html#coroutines ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await in Python; v2
On 25 April 2015 at 22:02, Yury Selivanov wrote: [...] > On 2015-04-25 4:47 PM, Arnaud Delobelle wrote: [...] >> 1. About the 'async for' construct. Each iteration will create a new >> coroutine object (the one returned by Cursor.__anext__()) and it seems >> to me that it can be wasteful. In the example given of an 'aiterable' >> Cursor class, probably a large number of rows will fill the cursor >> buffer in one call of cursor._prefetch(). However each row that is >> iterated over will involve the creation execution of a new coroutine >> object. It seems to me that what is desirable in that case is that >> all the buffered rows will be iterated over as in a plain for loop. > > > I agree that creating a new coroutine object is a little bit > wasteful. > > However, the proposed iteration protocol was designed to: > > 1. Resemble already existing __iter__/__next__/StopIteration > protocol; > > 2. Pave the road to introduce coroutine-generators in the > future. Do you mean that __aiter__() would return a 'coroutine-generator'? I'm not sure what such an object is but if it is a suspendable generator in the same way that a coroutine is a suspendable function, then this is a strong argument to make the __aiter__() magic method a coroutine rather than a plain function. I.e. __aiter__() would return either an 'aiterator' or a 'coroutine generator object'. I think this could be mentioned in the section 'Why "__aiter__" is a coroutine' [1]. > We could, in theory, design the protocol to make __anext__ > awaitable return a regular iterators (and raise > StopAsyncIteration at the end) to make things more > efficient, but that would complicate the protocol > tremendously, and make it very hard to program and debug. > > My opinion is that this has to be addressed in 3.6 with > coroutine-generators if there is enough interest from > Python users. True, but to me this is bound to happen. I feel like the semantics of __anext__() is tied to the behaviour of this yet to be defined coroutine generator object and that if it turns out that the natural bevaviour of a coroutine generator is not consistent with the semantics of __anext__() then it would be a shame. I must say I have no evidence that this will happen! >> >> 2. I think the semantics of the new coroutine objects could be >> defined more clearly in the PEP. Of course they are pretty obvious >> when you know that the coroutines are meant to replace >> asyncio.coroutine as described in [1]. I understand that this PEP is >> mostly for the benefit of asyncio, hence mainly of interest of people >> who know it. However I think it would be good for it to be more >> self-contained. I have often read a PEP as an introduction to a new >> feature of Python. I feel that if I was not familiar with yield from >> and asyncio I would not be able to understand this PEP, even though >> potentially one could use the new constructs without knowing anything >> about them. >> > > I agree. I plan to update the PEP with some new > semantics (prohibit passing coroutine-objects to iter(), > tuple() and other builtins, as well as using them in > 'for .. in coro()' loops). I'll add a section with > a more detailed explanation of coroutine-objects. Great! Thanks, -- Arnaud PS: there's a slight asymmetry in the terminology between coroutines and generators. 'Generator functions' are to 'generators' what 'coroutines' are to 'coroutine objects', which makes it difficult to what one is talking about when referring to a 'coroutine generator'. [1] https://www.python.org/dev/peps/pep-0492/#id52 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492: async/await in Python; version 4
On 1 May 2015 at 21:27, Yury Selivanov wrote: > On 2015-05-01 4:24 PM, Arnaud Delobelle wrote: >> >> On 1 May 2015 at 20:24, Yury Selivanov wrote: >>> >>> On 2015-05-01 3:19 PM, Ethan Furman wrote: >> >> [...] >>>> >>>> If we must have __aiter__, then we may as well also have __anext__; >>>> besides >>>> being more consistent, it also allows an object to be both a normol >>>> iterator >>>> and an asynch iterator. >>> >>> >>> And this is a good point too. >> >> I'm not convinced that allowing an object to be both a normal and an >> async iterator is a good thing. It could be a recipe for confusion. >> > > > I doubt that it will be a popular thing. But disallowing this > by merging two different protocols in one isn't a good idea > either. I having been arguing for merging two different protocols. I'm saying that allowing an object to be both normal and async iterable is not an argument for having separate protocols because it's not a good thing. Cheers, -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492: What is the real goal?
On 29 April 2015 at 20:42, Yury Selivanov wrote: > Everybody is pulling me in a different direction :) > Guido proposed to call them "native coroutines". Some people > think that "async functions" is a better name. Greg loves > his "cofunction" term. > > I'm flexible about how we name 'async def' functions. I like > to call them "coroutines", because that's what they are, and > that's how asyncio calls them. It's also convenient to use > 'coroutine-object' to explain what is the result of calling > a coroutine. I'd like the object created by an 'async def' statement to be called a 'coroutine function' and the result of calling it to be called a 'coroutine'. This is consistent with the usage of 'generator function' and 'generator' has two advantages IMO: - they both would follow the pattern 'X function' is a function statement that when called returns an 'X'. - When the day comes to define generator coroutines, then it will be clear what to call them: 'generator coroutine function' will be the function definition and 'generator coroutine' will be the object it creates. Cheers, -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492: async/await in Python; version 4
On 1 May 2015 at 20:24, Yury Selivanov wrote: > On 2015-05-01 3:19 PM, Ethan Furman wrote: [...] >> If we must have __aiter__, then we may as well also have __anext__; >> besides >> being more consistent, it also allows an object to be both a normol >> iterator >> and an asynch iterator. > > > And this is a good point too. I'm not convinced that allowing an object to be both a normal and an async iterator is a good thing. It could be a recipe for confusion. -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 quibble and request
On 1 May 2015 at 20:59, Guido van Rossum wrote: > On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: >> >> >> Another useful async function might be... >> >>async def yielding(): >>pass >> >> In a routine is taking very long time, just inserting "await yielding()" >> in the long calculation would let other awaitables run. >> > That's really up to the scheduler, and a function like this should be > provided by the event loop or scheduler framework you're using. Really? I was under the impression that 'await yielding()' as defined above would actually not suspend the coroutine at all, therefore not giving any opportunity for the scheduler to resume another coroutine, and I thought I understood the PEP well enough. Does this mean that somehow "await x" guarantees that the coroutine will suspend at least once? To me the async def above was the equivalent of the following in the 'yield from' world: def yielding(): return yield # Just to make it a generator Then "yield from yielding()" will not yield at all - which makes its name rather misleading! -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492: async/await in Python; version 4
On 3 May 2015 at 16:24, Steven D'Aprano wrote: > On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote: > >> I'm not convinced that allowing an object to be both a normal and an >> async iterator is a good thing. It could be a recipe for confusion. > > In what way? > > I'm thinking that the only confusion would be if you wrote "async for" > instead of "for", or vice versa, and instead of getting an exception you > got the (a)syncronous behaviour you didn't want. Yes. This is the same kind of confusion that this PEP is trying hard to get rid of in other parts (i.e. the confusion between 'yield' and 'yield from' in current coroutines). > But I have no intuition for how likely it is that you could write an > asyncronous for loop, leave out the async, and still have the code do > something meaningful. Well if you've made you object both iterable and 'async iterable' then it's very likely that you're going to get something meaningful out of either kind of iteration. Just not the way you want it if you mistakenly left out (or added) the 'async' keyword in your loop. > Other than that, I think it would be fine to have an object be both a > syncronous and asyncronous iterator. You specify the behaviour you want > by how you use it. We can already do that, e.g. unittest's assertRaises > is both a test assertion and a context manager. The latter is fine, because there is no danger of mistaking one for the other, unlike iterators and 'async iterators'. But my argument is simply that there is no good reason to aim for the ability to have object conform to both protocols. So it shouldn't be a criterion when looking at the merits of a proposal. I may very well be wrong but I haven't yet seen a compelling case for an object implementing both protocols. Cheers, -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 quibble and request
On 3 May 2015 at 02:22, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > <mailto:arno...@gmail.com>> wrote:
>>
>> Does this mean that
>> somehow "await x" guarantees that the coroutine will suspend at least
>> once?
>
>
> No. First, it's possible for x to finish without yielding.
> But even if x yields, there is no guarantee that the
> scheduler will run something else -- it might just
> resume the same task, even if there is another one that
> could run. It's up to the scheduler whether it
> implements any kind of "fair" scheduling policy.
That's what I understood but the example ('yielding()') provided by
Ron Adam seemed to imply otherwise, so I wanted to clarify.
--
Arnaud
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: PEP 467 feedback from the Steering Council
It probably won't fly but why not bytes.frombyte? There's no such thing as a byte type in Python, only bytes, so I want to argue it makes it clear the argument is a number in the range 0..255 and the result is a bytes object containing this single byte value. Tentatively, Arnaud PS. But truly I feel like this method is superfluous. On Thu, 9 Sept 2021 at 11:11, Victor Stinner wrote: > > I proposed bytes.byte earlier in this thread: > https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ > > Gregory dislikes the name: "I don't *like* to argue over names (the > last stage of anything) but I do need to point out how that sounds to > read". > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-) > > Victor > > On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou wrote: > > > > On Thu, 9 Sep 2021 18:55:04 +1000 > > Nick Coghlan wrote: > > > > > > P.S. The fact that it *didn't* look like the inverse operation for > > > `int.from_bytes` was one advantage of calling the method > > > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC > > > is right that `bytes.fromint` is a more comprehensible method name > > > overall. > > > > Perhaps we can call it `bytes.byte` to make it unambiguous? > > > > Regards > > > > Antoine. > > > > > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P7XG5CLLBXZTS6UE72KSGWLVYXRDXKT4/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] [Python-3000] No releases tonight
On 2 Mar 2008, at 02:00, Alex Martelli wrote: > On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw <[EMAIL PROTECTED]> > wrote: > ... >>> I also propose translations of the shorter text to important >>> languages >>> like French, German, Japanese, Portuguese and Spanish. I'm willing >>> to >>> help with the German translation. >> >> Cool, thanks. > > I'd like to volunteer for Italian (and we, the Italian Python > community, do have reasonably good connections to the Italian > technical press, which is covering e.g. the upcoming Pycon Due > conference), and although my French is VERY rusty I can give it a try > if no native French speaker is forthcoming. I'm a native French speaker, and although I am not involved in Python's development I would be happy to help by translating the documents. I have no connections with the French-speaking technical press. -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
