Sven R. Kunze wrote:
I already noted that
Python can detect when to make the switch without a marker. And you fail
to explain where the issue with this point of view is.
The issue is that Guido wants to see where all the
potential suspension points are.
--
Greg
___
Before removing provisional state from the pathlib module, we should
resolve the issue with Path.resolve(). It corresponds to
os.path.realpath(), but behaves differently in case of non-existent
path. Actually we can't say that any of these functions is wrong. Both
behaviors make sense in differ
There's been discussion here and on python-dev regarding PEP 526 that
assumes there will be multiple type checkers for Python. I really
can't see this happening. If typing annotations become common or maybe
considered best practice, the Zen of Python "there should be one-- and
preferably only one -
On 7 September 2016 at 10:28, Hugh Fisher wrote:
> Firstly, the interpreter will need to have type checking built in.
> Just about every intro book and tutorial for Python says how great it
> is that you don't have an edit-save-compile cycle, just fire up the
> Python interpreter and start typing.
> import threading
>
> class AtomicCounter:
> def __init__(self, initial=0):
> self.value = initial
> self._lock = threading.Lock()
>
> def increment(self, num=1):
> with self._lock:
> self.value += num
> re
On 7 September 2016 at 04:54, Sven R. Kunze wrote:
> On 06.09.2016 20:37, Nick Coghlan wrote:
>> As Anthony already noted, the "async" keyword switches to the
>> asynchronous version of the iterator protocol - you use this when your
>> *iterator* needs to interact with the event loop, just as you
On 4 September 2016 at 09:31, Yury Selivanov wrote:
> With the proposed asynchronous comprehensions syntax, the above code
> becomes as short as::
>
> result = [i async for i in aiter() if i % 2]
After using it a few times in examples, while I'm prepared to accept
the agrammatical nature of "
On Wed, Sep 7, 2016 at 2:11 PM, Nick Coghlan wrote:
> On 7 September 2016 at 04:54, Sven R. Kunze wrote:
>> On 06.09.2016 20:37, Nick Coghlan wrote:
>>> As Anthony already noted, the "async" keyword switches to the
>>> asynchronous version of the iterator protocol - you use this when your
>>> *it
On Wed, Sep 7, 2016 at 2:31 PM Nick Coghlan wrote:
> On 4 September 2016 at 09:31, Yury Selivanov
> wrote:
> > With the proposed asynchronous comprehensions syntax, the above code
> > becomes as short as::
> >
> > result = [i async for i in aiter() if i % 2]
>
> After using it a few times in
On Wed, Sep 7, 2016 at 2:31 PM, Nick Coghlan wrote:
> On 4 September 2016 at 09:31, Yury Selivanov wrote:
>> With the proposed asynchronous comprehensions syntax, the above code
>> becomes as short as::
>>
>> result = [i async for i in aiter() if i % 2]
>
> After using it a few times in examp
On 7 September 2016 at 19:41, Paul Moore wrote:
> Frankly, this is the only model that makes sense, precisely because of
> the issues you raise. And it's an existing model used by linters like
> pyflakes, so there's no reason to assume it will be any less
> acceptable for type checkers.
Exactly -
On 7 September 2016 at 21:37, Andrew Svetlov wrote:
> On Wed, Sep 7, 2016 at 2:31 PM Nick Coghlan wrote:
>> After using it a few times in examples, while I'm prepared to accept
>> the agrammatical nature of "async for" in the statement form (where
>> the adjective-noun phrase can be read as a kin
On Sep 7, 2016 4:28 AM, "Hugh Fisher" wrote:
>
> There's been discussion here and on python-dev regarding PEP 526 that
> assumes there will be multiple type checkers for Python. I really
> can't see this happening.
It already did:
- mypy
- pytype
- PyCharm has an integrated one
- pylint will add
Serhiy Storchaka writes:
> The readlink utility from GNU coreutils has three mode for resolving
> file path:
>
> -f, --canonicalize
>canonicalize by following every symlink in every
> component of the given name recursively; all but the last component must
> exis
On Wed, Sep 7, 2016 at 3:27 PM, Nick Coghlan wrote:
[...]
>
> The new issue that's specific to comprehensions is that the statement
> form doesn't have the confounding factor of having an expression to
> the left of it. Thus, the prefix is unambiguous and can be read as
> modifying the entire stat
On 8 September 2016 at 00:57, Koos Zevenhoven wrote:
> On Wed, Sep 7, 2016 at 3:27 PM, Nick Coghlan wrote:
> [...]
>>
>> The new issue that's specific to comprehensions is that the statement
>> form doesn't have the confounding factor of having an expression to
>> the left of it. Thus, the prefix
On 2016-09-06 7:19 PM, Guido van Rossum wrote:
On Tue, Sep 6, 2016 at 10:42 AM, Yury Selivanov wrote:
On 2016-09-04 3:10 AM, Adam Bartoš wrote:
will await be allowed also in the "if" part of comprehensions? And what
about the "in" part? (e.g. if I'm not mistaken, we may have an asynchronous
On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov wrote:
> Thank you for accepting the PEP! Will focus on the implementation now.
You're welcome! Good luck with the implementation.
@Nick, regarding the suggestion to use
[ for in async ]
instead of
[ async for in ]
I think the lack of gra
On 06.09.2016 21:45, Terry Reedy wrote:
On 9/6/2016 2:54 PM, Sven R. Kunze wrote:
PS: Nick, I noted that while replying, my mail client made me responding
to you and the list as cc.
For Thunderbird, this is normal behavior. I suspect you would find
the same if your tried 'replay all' to mul
On 8 Sep 2016 02:48, "Guido van Rossum" wrote:
>
> On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov
wrote:
> > Thank you for accepting the PEP! Will focus on the implementation now.
>
> You're welcome! Good luck with the implementation.
>
> @Nick, regarding the suggestion to use
>
> [ for in as
On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan wrote:
>
> Exactly - in a dynamic language like Python, running a typechecker is
> a form of testing, rather than a necessary part of getting the code to
> work in the first place.
>
The average programmer such as myself will expect that if I write cod
On 06.09.2016 21:29, Tim Peters wrote:
In the absence of anything approaching [use-cases], it's a matter of taste, and
then
- yes - decades of Python development experience do - and should -
outweigh a newcomer's wish list. Especially when, as appears to be
the case here, those with truly exte
On 7 September 2016 at 22:31, Hugh Fisher wrote:
> The average programmer such as myself will expect that if I write code
> specifying the type of a variable or whatever it should *do
> something*. It's code, I wrote it, it should be interpreted.
Reading the documentation should correct that mist
[Sven R. Kunze ]
> I am not questioning experience which everyone in a team can benefit from.
>
>
> BUT experienced devs also need to recognize and respect the fact that
> younger/unexperienced developers are just better in detecting
> inconsistencies and bloody work-arounds. They simply haven't ha
On 07.09.2016 02:49, Chris Kaynor wrote:
I'll weigh in and say that I've had a few cases where I've wanted a
shuffled function, but not many. The vast majority are interactive
uses, where I want to get a sampling of data, and in those cases I'm
normally just printing the output (often, by letti
On 8 September 2016 at 00:00, Paul Moore wrote:
> > Type annotations are code, not tests.
>
> Not in Python they aren't.
>
Well, to a certain extent. One can try something like this in REPL:
from typing import get_type_hints
import __main__
s: str
class C:
x: int
get_type_hints(C)
get_t
Maybe, there's a misunderstanding here and I hope I didn't waste too
much of your and my time.
Not sure where I got this from but my last status was that Arek would
like to have a "shuffled" function that does exactly what you described.
Maybe, that doesn't fit the reports description but his
On 08.09.2016 00:00, Paul Moore wrote:
On 7 September 2016 at 22:31, Hugh Fisher wrote:
The average programmer such as myself will expect that if I write code
specifying the type of a variable or whatever it should *do
something*. It's code, I wrote it, it should be interpreted.
Reading the do
I lurk around here a lot more than I actually post -- But in this case I
find myself weighing in firmly on the side of "please don't add this".
It'd just add noise in the documentation and __builtins__ namespace. There
are millions of useful functions that *could* be added to the `list` object
(or
Thank you all for the meta discussion. I know we sidetracked a bit but
please everyone remember, this is an open discussion floor.
I can present you a use case, just didnt think I even needed one. This
seems so obvious to me that it should just go in without much saying. In
the project I maintain
On 08.09.2016 00:41, Matt Gilson wrote:
I lurk around here a lot more than I actually post -- But in this case
I find myself weighing in firmly on the side of "please don't add
this". It'd just add noise in the documentation and __builtins__
namespace. There are millions of useful functions t
On Wed, Sep 7, 2016 at 3:10 PM, Sven R. Kunze wrote:
> @David
> Your idea of a PyPI package could almost work. However, in an interactive
> python console, I expect as much batteries included as possible to make it
> as quick as possible. And considering how simple such wrapper would be, it
> alm
On 07/09/2016 23:41, Matt Gilson wrote:
I lurk around here a lot more than I actually post
Very wise. I am a tournament Bridge player, and one of the things I say
to my partners is: "Bidding is very simple. When you have something to
say, say it (unless it really seems too dangerous). When
On Wed, Sep 7, 2016 at 6:56 PM, Arek Bulski wrote:
> In the project I maintain (construct) there are declarative testcases that
> look like a long list of (func, args, excepted output, error type) tuples.
> There is no way for me to call shuffle in there.
Can you explain why? Something like th
If you want to see the declarative tests, here it is.
https://github.com/construct/construct/blob/master/tests/test_all.py
pozdrawiam,
Arkadiusz Bulski
2016-09-08 2:13 GMT+02:00 Arek Bulski :
> See for yourself. There is a long list of declarative tests.
> https://github.com/construct/construct
On Wed, Sep 7, 2016 at 8:14 PM, Arek Bulski wrote:
>
> If you want to see the declarative tests, here it is.
> https://github.com/construct/construct/blob/master/tests/test_all.py
So, why can't you call random.shuffle(all_tests) if you want to run your
tests in random order?
If for some reason
On Wed, Sep 7, 2016 at 9:12 PM, Alexander Belopolsky <
[email protected]> wrote:
> On Wed, Sep 7, 2016 at 8:14 PM, Arek Bulski wrote:
> >
> > If you want to see the declarative tests, here it is.
> > https://github.com/construct/construct/blob/master/tests/test_all.py
>
>
> So, why c
On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
> BUT experienced devs also need to recognize and respect the fact that
> younger/unexperienced developers are just better in detecting
> inconsistencies and bloody work-arounds.
That is not a fact. It is the opposite of a fact -- i
On 8 September 2016 at 07:31, Hugh Fisher wrote:
> On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan wrote:
>>
>> Exactly - in a dynamic language like Python, running a typechecker is
>> a form of testing, rather than a necessary part of getting the code to
>> work in the first place.
>>
>
> The avera
On Thu, Sep 08, 2016 at 12:22:28AM +0200, Sven R. Kunze wrote:
> About the confusion of returning None. It's not confusing in the sense
> of "o my god, I did it wrong, I need to learn it", but more, like "I
> used shuffle, BECAUSE it's the only one I could find in a hurry"
Then don't be in such
Though I agree with the argument that inexperienced developers are
[usually] worse, that's not the case here, unless anyone here is really
trying to say the ones arguing for or against "shuffled" are inexperienced.
These ad hominem won't bring us anywhere.
No one seem to be arguing if "shuffled" i
On 8 September 2016 at 12:00, Steven D'Aprano wrote:
> On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
>
>> BUT experienced devs also need to recognize and respect the fact that
>> younger/unexperienced developers are just better in detecting
>> inconsistencies and bloody work-aroun
On Wed, Sep 07, 2016 at 11:47:49PM -0300, Danilo J. S. Bellini wrote:
> Though I agree with the argument that inexperienced developers are
> [usually] worse, that's not the case here, unless anyone here is really
> trying to say the ones arguing for or against "shuffled" are inexperienced.
> These
On 8 September 2016 at 12:47, Danilo J. S. Bellini
wrote:
> Though I agree with the argument that inexperienced developers are [usually]
> worse, that's not the case here, unless anyone here is really trying to say
> the ones arguing for or against "shuffled" are inexperienced. These ad
> hominem
On 8 September 2016 at 13:23, Nick Coghlan wrote:
> Beyond that practical benefit, if you want
> random-sampling-with-replacement, then "map(random.choice, container)"
Oops, that was supposed to be "map(random.choice, itertools.repeat(container))".
Cheers,
Nick.
--
Nick Coghlan | ncogh...
Nice to know about random.sample! =)
I think what OP said can then be reduced to having the default k in
random.sample to be the iterable size. The existance of random.sample is a
very strong argument against "shuffled", and the only "feature" shuffled
would have that random.sample doesn't have is
On 8 September 2016 at 13:33, Danilo J. S. Bellini
wrote:
> Nice to know about random.sample! =)
>
> I think what OP said can then be reduced to having the default k in
> random.sample to be the iterable size. The existance of random.sample is a
> very strong argument against "shuffled", and the o
>
> 1. The cognitive leap between shuffling and sampling isn't small
>
I don't think so, actually the Fisher-Yates shuffle algorithm algorithm is
an iterative sampling algorithm: https://gist.github.com/danilo
bellini/6384872
> 2. "shuffled" would be a more logical name for an out-of-place shuffl
48 matches
Mail list logo
