On 14 April 2018 at 19:22, Steve Barnes wrote:
> I generally love the current import system for "just working" regardless
> of platform, installation details, etc., but what I would like to see is
> a clear import local, (as opposed to import from wherever you can find
> something to satisfy mecha
On 15 April 2018 at 17:12, Nick Coghlan wrote:
> If you want to do this dynamically relative to the current module,
> then it's possible to do:
>
> global __path__
> __path__[:] = (some_directory, some_other_directory)
> custom_mod = importlib.import_module(".name", package=__name__)
On 15 April 2018 at 13:54, Chris Angelico wrote:
> On Sun, Apr 15, 2018 at 1:08 PM, Nick Coghlan wrote:
>> === Target first, 'from' keyword ===
>>
>> while (value from read_next_item()) is not None: # New
>> ...
>>
>> Pros:
>>
>> * avoids the syntactic ambiguity of "as"
>> * being
Hi all,
I am new in python (i am moving from Perl world), but I always love
Python for hight level, beatuful and clean syntax.
Now I have question/idea about working with files.
On mine opinion it very popular use case:
1. Open file (for read and write)
2. Read data from file
3. Modify data.
4.
2018-04-15 6:08 GMT+03:00 Nick Coghlan :
>
> It's not completely off topic. as it's due to the fact we use "," to
> separate both context managers and items in a tuple, so "with (cm1,
> cm2, cm3):" is currently legal syntax that means something quite
> different from "with cm1, cm2, cm3:". While u
15.04.18 11:57, Alexey Shrub пише:
I am new in python (i am moving from Perl world), but I always love
Python for hight level, beatuful and clean syntax.
Now I have question/idea about working with files.
On mine opinion it very popular use case:
1. Open file (for read and write)
2. Read data fr
On Sun, Apr 15, 2018 at 12:19 PM, Kirill Balunov
wrote:
>
>
> 2018-04-15 6:08 GMT+03:00 Nick Coghlan :
>>
>>
>
>>
>> P.S. The pros and cons of the current syntax proposals, as I see them:
>>
>> === Expression first, 'as' keyword ===
>>
>> while (read_next_item() as value) is not None:
>>
В Воскресенье, 15 апр. 2018 в 12:40 , Serhiy Storchaka
написал:
If the problem is that you want to use a single line instead of three
line, you can add a function
Yes, I think that single line with word 'rewrite' is much more readable
than those three lines.
And yes, I can make my own functio
On Sun, 15 Apr 2018 00:05:58 -0500
Tim Peters wrote:
> Just for fun - no complaint, no suggestion, just sharing a bit of code
> that tickled me.
>
> The docs for `itertools.tee()` contain a Python work-alike, which is
> easy to follow. It gives each derived generator its own deque, and
> when a
15.04.18 12:49, Alexey Shrub пише:
В Воскресенье, 15 апр. 2018 в 12:40 , Serhiy Storchaka
написал:
If the problem is that you want to use a single line instead of three
line, you can add a function
Yes, I think that single line with word 'rewrite' is much more readable
than those three lines
This pitfall sounds like a good reason to have such a function in the
standard library.
Elazar
בתאריך יום א׳, 15 באפר׳ 2018, 13:13, מאת Serhiy Storchaka <
storch...@gmail.com>:
> 15.04.18 12:49, Alexey Shrub пише:
> > В Воскресенье, 15 апр. 2018 в 12:40 , Serhiy Storchaka
> > написал:
> >> If
On 15 April 2018 at 10:49, Alexey Shrub wrote:
> В Воскресенье, 15 апр. 2018 в 12:40 , Serhiy Storchaka
> написал:
>>
>> If the problem is that you want to use a single line instead of three
>> line, you can add a function
>
>
> Yes, I think that single line with word 'rewrite' is much more reada
On 15 April 2018 at 11:22, Elazar wrote:
> בתאריך יום א׳, 15 באפר׳ 2018, 13:13, מאת Serhiy Storchaka
> :
>> Actually the reliable code should write into a separate file and replace
>> the original file by the new file only if writing is successful. Or
>> backup the old file and restore it if writ
On 15 April 2018 at 19:41, Mikhail V wrote:
> So IIUC, the *only* reason is to avoid '==' ad '=' similarity?
> If so, then it does not sound convincing at all.
> Of course Python does me a favor showing an error,
> when I make a typo like this:
> if (x = y)
>
> But still, if this is the only real
2018-04-15 12:41 GMT+03:00 Mikhail V :
>
> Exactly, all forms invites this and other questions.
>
> First of all, coming back to original spelling choice arguments
> [Sorry in advance if I've missed some points in this huge thread]
>
> citation from PEP:
> "Differences from regular assignment st
On 15 April 2018 at 20:47, Paul Moore wrote:
> On 15 April 2018 at 11:22, Elazar wrote:
>> בתאריך יום א׳, 15 באפר׳ 2018, 13:13, מאת Serhiy Storchaka
>> :
>>> Actually the reliable code should write into a separate file and replace
>>> the original file by the new file only if writing is successf
On Sun, Apr 15, 2018 at 7:19 PM, Kirill Balunov wrote:
>> === Expression first, 'as' keyword ===
>>
>> while (read_next_item() as value) is not None:
>> ...
>>
>> Pros:
>>
>> * typically reads nicely as pseudocode
>> * "as" is already associated with namebinding operations
>>
>
> I
В Воскресенье, 15 апр. 2018 в 2:40 , Nick Coghlan
написал:
https://bugs.python.org/issue8604#msg174104 is the relevant tracker
discussion
Thanks all, I agree that universal and absolutly safe solution is very
difficult, but for experiment I made some draft
https://github.com/worldmind/script
2018-04-15 15:21 GMT+03:00 Chris Angelico :
> On Sun, Apr 15, 2018 at 7:19 PM, Kirill Balunov
> wrote:
> >> === Expression first, 'as' keyword ===
> >>
> >> while (read_next_item() as value) is not None:
> >> ...
> >>
> >> Pros:
> >>
> >> * typically reads nicely as pseudocode
> >>
2018-04-15 17:17 GMT+03:00 Kirill Balunov :
>
>
> for item in iter(read_next_item, None):
> items.append(item)
> print(r'%d/%d' % (i, len(items)), end='\r')
>
>
> With kind regards,
> -gdg
>
Oh, I forgot about `i`:
for item in iter(read_next_item, None):
i += 1
items.append(item)
> To me, "from" strongly suggests that an element is being obtained from a
container/collection of
> elements. This is how I conceptualize "from module import name": "name"
refers to an object
> INSIDE the module, not the module itself. If I saw
>
> if (match from pattern.search(data)) is not None:
>
>
> 0.
>
> while (items[i := i+1] := read_next_item()) is not None:
> print(r'%d/%d' % (i, len(items)), end='\r')
>
> 1.
>
> while (read_next_item() -> items[(i+1) -> i]) is not None:
> print(r'%d/%d' % (i, len(items)), end='\r')
>
> 2.
>
> while (item := read_next_item()) is not None:
>
On Sun, Apr 15, 2018 at 05:15:55PM +0300, Alexey Shrub wrote:
> В Воскресенье, 15 апр. 2018 в 2:40 , Nick Coghlan
> написал:
> > https://bugs.python.org/issue8604#msg174104 is the relevant tracker
> > discussion
>
> Thanks all, I agree that universal and absolutly safe solution is very
> difficu
On Sun, Apr 15, 2018 at 10:21:02PM +1000, Chris Angelico wrote:
> I don't think we're ever going to unify everyone on an arbitrary
> question of "expression first" or "name first". But to all the
> "expression first" people, a question: what if the target is not just
> a simple name?
>
> while (r
Depending on how firm your requirements around locking are, you may find
this code useful:
https://github.com/mahmoud/boltons/blob/6b0721b6aeda6d3ec6f5d31be7c741bc7fcc4635/boltons/fileutils.py#L303
(docs here:
http://boltons.readthedocs.io/en/latest/fileutils.html#atomic-file-saving )
Basically e
[Raymond Hettinger ]
> Q. Do other languages do it?
> A. Numpy, no. R, no. APL, no. Mathematica, no. Haskell, yes.
>
> *
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html
> * https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html
> * http://
On Sun, Apr 15, 2018 at 11:11:37PM +0800, Thautwarm Zhao wrote:
> I think maybe we can use unicode characters like ≜ (\triangleq) and add the
> support of unicode completion to python repl. The unicode completion of
> editors or ides has been quite mature.
What key combination do I need to type t
On Sun, Apr 15, 2018 at 09:10:57AM -0700, Mahmoud Hashemi
wrote:
> Depending on how firm your requirements around locking are, you may find
> this code useful:
> https://github.com/mahmoud/boltons/blob/6b0721b6aeda6d3ec6f5d31be7c741bc7fcc4635/boltons/fileutils.py#L303
>
> (docs here:
> http://bo
[Antoine Pitrou ]
> This implementation doesn't work with Python 3.7 or 3.8.
> I've tried it here:
> https://gist.github.com/pitrou/b3991f638300edb6d06b5be23a4c66d6
>
> and get:
> Traceback (most recent call last):
> File "mytee.py", line 14, in gen
> mylast = last[1] = last = [next(it), None
2018-04-15 18:58 GMT+03:00 Steven D'Aprano :
>
> [...]
>
> But this time we don't care about the name. Its the value we care about:
>
> result = some_func(don't care,
>don't care -> don't care
>don't care -> don't care
>do
On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov
wrote:
> [...] For me personally, `: =` looks and feels just like normal assignment
> statement which can be used interchangeable but in many more places in the
> code. And if the main goal of the PEP was to offer this `assignment
> expression` as a
15.04.18 19:52, Tim Peters пише:
No, I don't ;-) If I have to catch StopIteration myself now, then I
want the entire "white True:" loop in the "try" block. Setting up
try/except machinery anew on each iteration would add significant
overhead; doing it just once per derived generator wouldn't.
On 15/04/2018 08:12, Nick Coghlan wrote:
> On 14 April 2018 at 19:22, Steve Barnes wrote:
>> I generally love the current import system for "just working" regardless
>> of platform, installation details, etc., but what I would like to see is
>> a clear import local, (as opposed to import from wh
Dear Steve, I'm sorry to annoy you by my proposal, but I do think using
unicode might be wise in current stage.
\triangleq could be print with unicode number \u225c, and adding plugins to
support typing this in editors could be easy, just simply map \xxx to the
specific unicode char when we press
On Sun, Apr 15, 2018 at 7:15 PM, Steven D'Aprano wrote:
> On Sun, Apr 15, 2018 at 11:11:37PM +0800, Thautwarm Zhao wrote:
>
>> I think maybe we can use unicode characters like ≜ (\triangleq) and add the
>> support of unicode completion to python repl. The unicode completion of
>> editors or ides h
Hi,
some similar thing already exist in standard:
https://docs.python.org/3/library/fileinput.html
fileinput(... inplace=True...)
BR,
George
2018-04-15 10:57 GMT+02:00 Alexey Shrub :
> Hi all,
>
> I am new in python (i am moving from Perl world), but I always love Python
> for hight level, bea
On Mon, Apr 16, 2018 at 1:58 AM, Steven D'Aprano wrote:
> On Sun, Apr 15, 2018 at 10:21:02PM +1000, Chris Angelico wrote:
>
>> I don't think we're ever going to unify everyone on an arbitrary
>> question of "expression first" or "name first". But to all the
>> "expression first" people, a question
On Mon, Apr 16, 2018 at 12:17 AM, Kirill Balunov
wrote:
>
>
> 2018-04-15 15:21 GMT+03:00 Chris Angelico :
>> I don't think we're ever going to unify everyone on an arbitrary
>> question of "expression first" or "name first". But to all the
>> "expression first" people, a question: what if the targ
On Mon, Apr 16, 2018 at 3:19 AM, Guido van Rossum wrote:
> On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov
> wrote:
>> But somehow this PEP does not mean it! And with the current rationale of
>> this PEP it's a huge CON for me that `=` and `:=` feel and look the same.
>
> Then maybe the PEP needs
On Sun, Apr 15, 2018 at 2:01 PM, Nick Coghlan wrote:
> On 15 April 2018 at 19:41, Mikhail V wrote:
>> So IIUC, the *only* reason is to avoid '==' ad '=' similarity?
>> If so, then it does not sound convincing at all.
>> Of course Python does me a favor showing an error,
>> when I make a typo like
On Mon, Apr 16, 2018 at 4:58 AM, Thautwarm Zhao wrote:
> Dear Steve, I'm sorry to annoy you by my proposal, but I do think using
> unicode might be wise in current stage.
>
> \triangleq could be print with unicode number \u225c, and adding plugins to
> support typing this in editors could be easy,
On Sun, Apr 15, 2018 at 8:05 AM, Tim Peters wrote:
[...]
> Then I thought "this is stupid! Python already does reference
> counting." Voila! Vast swaths of tedious code vanished, giving this
> remarkably simple implementation:
>
> def mytee(xs, n):
> last = [None, None]
>
>
On Mon, Apr 16, 2018 at 6:46 AM, Koos Zevenhoven wrote:
> Anyway, the whole linked list is unnecessary if the iterable can be iterated
> over multiple times. But "tee" won't know when to do that. *That* is what I
> call overhead (unless of course all the tee branches are consumed in an
> interleav
[Koos Zevenhoven ]
> It's definitely possible to write the above in a more
> readable way, and FWIW I don't think it involves "assignments as
> expressions".
Of course it is. The point was brevity and speed, not readability.
It was presented partly as a puzzle :-)
>> What I find kind of hila
On 2018-04-12 18:03, Guido van Rossum wrote:
It's a slippery slope indeed. While having to change update() alone wouldn't
worry me, the subclass constructors do seem like they are going to want changing
too, and that's indeed a bit much. So let's back off a bit. Not every three
lines of code ne
On 2018-04-15 08:58, Steven D'Aprano wrote:
I've been mulling over the question why I think the expression needs to
come first here, whereas I'm satisfied with the target coming first for
assignment statements, and I think I've finally got the words to explain
it. It is not just long familiarity
For most types that implement __add__, `x + x` is equal to `2 * x`.
That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
for collections.Counter. I can add two Counters, but I can't multiply one
by a scalar. That seems like an oversight.
It would be worthwhile to implement m
Good call. Is it any faster to initialize Counter with a dict comprehension?
return Counter({k: v*scalar for (k, v) in self.items())
On Sun, Apr 15, 2018 at 5:05 PM, Peter Norvig wrote:
> For most types that implement __add__, `x + x` is equal to `2 * x`.
>
> That is true for all numbers, list,
That's actually how I coded it myself the first time. But I worried it
would be wasteful to create an intermediate dict and discard it.
`timeit` results:
3.79 µs for the for-loop, 5.08 µs for the dict-comprehension with a 10-key
Counter
257 µs for the for-loop, 169 µs for the dict-comprehension w
> On Apr 15, 2018, at 2:05 PM, Peter Norvig wrote:
>
> For most types that implement __add__, `x + x` is equal to `2 * x`.
>
> ...
>
>
> That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
> for collections.Counter. I can add two Counters, but I can't multiply one b
If you think of a Counter as a multiset, then it should support __or__, not
__add__, right?
I do think it would have been fine if Counter did not support "+" at all
(and/or if Counter was limited to integer values). But given where we are
now, it feels like we should preserve `c + c == 2 * c`.
A
On Sunday, April 15, 2018, Peter Norvig wrote:
> If you think of a Counter as a multiset, then it should support __or__,
> not __add__, right?
>
> I do think it would have been fine if Counter did not support "+" at all
> (and/or if Counter was limited to integer values). But given where we are
tf.bincount() returns a vector with integer counts.
https://www.tensorflow.org/api_docs/python/tf/bincount
Keras calls np.bincount in an mnist example.
np.bincount returns an array with a __mul__
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.bincount.html
- sklearn.preprocess
> On Apr 15, 2018, at 5:44 PM, Peter Norvig wrote:
>
> If you think of a Counter as a multiset, then it should support __or__, not
> __add__, right?
FWIW, Counter is explicitly documented to support the four multiset-style
mathematical operations discussed in Knuth TAOCP Volume II section 4.
> On Apr 15, 2018, at 7:18 PM, Wes Turner wrote:
>
> And I'm done sharing non-pure-python solutions for this problem, I promise
Keep them coming :-)
Thanks for the research. It helps to remind ourselves that almost none of our
problems are new :-)
Raymond
__
On Mon, Apr 16, 2018 at 1:39 PM, Raymond Hettinger
wrote:
>
> So, the API design issue that confronts us is that it would be a bit weird
> and disorienting for the arithmetic operators to have two different
> signatures:
>
> +=
> -=
> *=
> /=
>
This needn't be a blocker.
On Sun, Apr 15, 2018 at 8:39 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> FWIW, Counter is explicitly documented to support the four multiset-style
> mathematical operations discussed in Knuth TAOCP Volume II section 4.6.3
> exercise 19:
>
Wow, I never noticed "&" and "|" -- I gue
> On Apr 15, 2018, at 9:04 PM, Peter Norvig wrote:
>
> it would be a bit weird and disorienting for the arithmetic operators to have
> two different signatures:
>
> +=
> -=
> *=
> /=
>
> Is it weird and disorienting to have:
>
> +=
> *=
Yes, there is a preceden
I don't have strong feelings, but I would say yes to __imul__, no to
__div__ and __floordiv__ (with str/list/tuple as the precedent).
For chisquare, I would be perfectly happy with:
digit_counts = Counter(...)
scipy.stats.chisquare(list(digit_counts.values()))
On Sun, Apr 15, 2018 at 9:39 PM Ray
[Peter Norvig]
> For most types that implement __add__, `x + x` is equal to `2 * x`.
>
> That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
> for collections.Counter. I can add two Counters, but I can't multiply one
> by a scalar. That seems like an oversight.
>
> ...
> Here
On Monday, April 16, 2018, Raymond Hettinger
wrote:
>
>
> > On Apr 15, 2018, at 9:04 PM, Peter Norvig wrote:
> >
> > it would be a bit weird and disorienting for the arithmetic operators to
> have two different signatures:
> >
> > +=
> > -=
> > *=
> > /=
> >
> > Is it wei
> On Apr 15, 2018, at 10:07 PM, Tim Peters wrote:
>
> Adding Counter * integer doesn't bother me a bit, but the definition
> of what that should compute isn't obvious.
Any thoughts on Counter * float? A key use case for what is being proposed is:
c *= 1 / c.total
Raymond
[Tim]
>> Adding Counter * integer doesn't bother me a bit, but the definition
>> of what that should compute isn't obvious.
[Raymond]
> Any thoughts on Counter * float? A key use case for what is being proposed
> is:
>
> c *= 1 / c.total
Ah, I thought I had already addressed that, but loo
On 16/04/2018 06:07, Tim Peters wrote:
> [Peter Norvig]
>> For most types that implement __add__, `x + x` is equal to `2 * x`.
>>
>> That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
>> for collections.Counter. I can add two Counters, but I can't multiply one
>> by a scal
> On Apr 15, 2018, at 10:51 PM, Tim Peters wrote:
>
> I also have no problem with inplace operators. Or with adding
> `Counter /= scalar", for that matter.
But surely __rdiv__() would be over the top, harmonic means be damned ;-)
Raymond
___
P
65 matches
Mail list logo
