Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

[Alexander Belopolsky]

> In [12]: a= mdict(a=[2], b='a')
> In [13]: a+a

Aren't you reinventing the Counter type?

>>> from collections import Counter
>>> c = Counter(a=1,b=2)
>>> c + c
Counter({'b': 4, 'a': 2})
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add a __cite__ method for scientific packages

[Alexander Belopolsky]

On Sun, Jul 1, 2018 at 9:45 AM David Mertz  wrote:

> ..
> There's absolutely nothing in the idea that requires a change in Python,
> and Python developers or users are not, as such, the relevant experts.
>

This is not entirely true.  If some variant of __citation__ is endorsed by
the community, I would expect that pydoc would extract this information to
fill an appropriate section in the documentation page.  Note that pydoc
already treats a number of dunder variables
specially: '__author__', '__credits__', and '__version__' are a few that
come to mind, so I don't think the threshold for adding one more should be
too high.  On the other hand, maybe   '__author__', '__credits__', and
'__citation__' should be merged in one structured variable (a dict?) with
format designed with some extendability in mind.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alexander Belopolsky]

On Thu, May 31, 2018 at 10:37 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 instance before we can decide
whether or not the raised exception matches the given exception handler
criteria.


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 E() in this case?  Yet when I run it,
I see "instantiated" printed on the console.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Reuse "for" to express "given"

[Alexander Belopolsky]

On Thu, May 24, 2018 at 4:59 PM Matt Arcidy <marc...@gmail.com> wrote:

>
>
> On Thu, May 24, 2018, 11:47 Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
>
>> > But I do have a mathematics background, and I don't remember ever
>> seeing
>> > "for x = value" used in the sense you mean.
>>
>> That's so because in mathematics, "for" is spelled ":" as in
>>
>>  {2*a* : *a*∈*Z*}
>>
>> If you can read the above, you should not have trouble reading
>>
>>  {2*a* + *b* : *a*∈*Z *: *b = *1}
>>
>
> Inverted "A" is "for all", and colon means "such that".  It may be
> acceptable somewhere to use a colon as you do,
>

See <https://en.wikipedia.org/wiki/Set_notation>.  Also, "[list
comprehensions] is Python's way of implementing a well-known notation for
sets as used by mathematicians." <
https://www.python-course.eu/list_comprehension.php>.  Although, the latter
uses "|" instead of ":".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Reuse "for" to express "given"

[Alexander Belopolsky]

> But I do have a mathematics background, and I don't remember ever seeing
> "for x = value" used in the sense you mean.

That's so because in mathematics, "for" is spelled ":" as in

 {2*a* : *a*∈*Z*}

If you can read the above, you should not have trouble reading

 {2*a* + *b* : *a*∈*Z *: *b = *1}
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Reuse "for" to express "given"

[Alexander Belopolsky]

On Thu, May 24, 2018 at 12:04 PM Robert Vanden Eynde 
wrote:

> This idea was mentioned (by me) at a time yes, but wasn't written in the
document.

Can you point me to a specific post?  There were so may that I must have
missed that one.

> I think one of the thing was that it would make the grammar non LL1
because when seeing the token "for" in a list comprehension it wouldn't
know in advance if it's the loop or the assignment.

I don't see how that can be a problem.  From the grammar point of view,
"for" in "for var = " may still be seen as introducing a "loop", but
when "=" is seen in place of "in", the compiler will resize that the "loop"
is one a single value and emit efficient code for it.  At the AST level,
  "for var = "  will look exactly the same as  "for var in "
only with an "=" instead of "in".

> And also, it might confuse people because 'for' is for iteration.

I think I addressed this in my previous post.  Yes, for people with a C/C++
background, "for" may be too strongly associated with loops, but in
mathematical sense, it seems clear that "for var in a set" means iteration
over a set, while "for var = expression" means binding to a single value.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Reuse "for" to express "given"

[Alexander Belopolsky]

I have read most of the PEP 572 related threads, but I don't think I've
seen this idea.  As many other people mentioned, Python already allows a
trick to introduce local bindings in generator expressions and list
comprehensions.  This can be achieved by adding a "for var in []"
clause.  I propose to make "for var = " have the same effect as "for
var in []".

Note that in the case of filters, the order will be different from that in
the original "given" proposal: instead of

[(x, y, x/y) for x in data if y given y = f(x)]

we will write

[(x, y, x/y) for x in data for y = f(x) if y]

The use of "for" in place of "given" in the if statements does not look too
bad:

   if m for m = pattern.search(data):
...
elif m for m = other_pattern.search(data)):
...
else:
...

I have to admit that

while m for m = pattern.search(remaining_data):
...

looks strange at first because both while and for are strongly associated
with loops, but if you read "for var = " as "for var equals
expression", the difference between that and "for var in (iterable)
expression" becomes apparent.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 7:12 PM Wes Turner  wrote:

> AstroPy solves for leap seconds [1][2] according to the IAU ERFA (SOFA)
> library [3] and the IERS-B and IERS-A tables [4]. IERS-B tables ship with
> AstroPy. The latest IERS-A tables ("from 1973 though one year into the
> future") auto-download on first use [5].
>

I've just tried it.  Unfortunately, it does not seem to be compatible with
PEP 495 datetime yet:

>>> t = astropy.time.Time('2016-12-31T23:59:60')
>>> t.to_datetime()
Traceback (most recent call last):
 ...
ValueError: Time (array(2016, dtype=int32), array(12, dtype=int32),
array(31, dtype=int32), array(23, dtype=int32), array(59, dtype=int32),
array(60, dtype=int32), array(0, dtype=int32)) is within a leap second but
datetime does not support leap seconds

Maybe someone can propose a feature for astropy to return
datetime(2016,12,31,23,59,59,fold=1) in this case.


>
> [1] http://docs.astropy.org/en/stable/time/#time-scales-for-time-deltas
> [2] http://docs.astropy.org/en/stable/time/#writing-a-custom-format
> [3] "Leap second day utc2tai interpolation"
> https://github.com/astropy/astropy/issues/5369
> [4] https://github.com/astropy/astropy/pull/4436
> [5] http://docs.astropy.org/en/stable/utils/iers.html
>
>>
>>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 3:13 PM Tim Peters  wrote:

> [Chris Barker]
> > Does that support the other way -- or do we never lose a leap second
> anyway?
> > (showing ignorance here)
>
> Alexander covered the Python part of this,  ...
>

No, I did not.  I did not realize that the question was about skipping a
second instead of inserting it.  Yes, regardless of whether it is possible
given the physics of Earth rotation, negative leap seconds can be
supported.  They simply become "gaps" in PEP 495 terminology.  Check out
PEP 495 and read "second" whenever you see "hour". :-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 2:51 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

>
> TAI  | UTC
> -+
> 2016-12-31T23:59:35  | 2016-12-31T23:59:59
> 2016-12-31T23:59:36  | 2016-12-31T23:59:60
> 2016-12-31T23:59:37  | 2017-01-01T00:00:00
>
> this correspondence can be implemented in Python using the following
> datetime objects:
>
> TAI| UTC
> ---+---
> datetime(2016,12,31,23,59,35)  | datetime(2016,12,31,23,59,59)
> datetime(2016,12,31,23,59,36)  | datetime(2016,12,31,23,59,59,fold=1)
> datetime(2016,12,31,23,59,37)  | datetime(2017,1,1,0,0,0)
>
>
>
Correction: 2016-01-01 in the tables I presented before should be read as
2017-01-01 and similarly for the datetime fields.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 1:33 PM Chris Barker <chris.bar...@noaa.gov> wrote:
>
> On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>>  [...] Since the implementation of PEP 495, it is
>> possible to represent the 23:59:60 as 23:59:59 with the "fold" bit set.
Of
>> course, the repeated 23:59:59 will be displayed and behave exactly the
same
>> as the first 23:59:59, but a 3rd party library can be written to take the
>> "fold" bit into account in temporal operations.
>
>
> Does that support the other way -- or do we never lose a leap second
anyway? (showing ignorance here)
>

I am not sure I understand your question.  All I said was that since PEP
495, it became possible to write a pair of functions to convert between TAI
and UTC timestamps without any loss of information.

For example, around the insertion  of the last leap second at the end of
2016, we had the following sequence of seconds:

TAI  | UTC
-+
2016-12-31T23:59:35  | 2016-12-31T23:59:59
2016-12-31T23:59:36  | 2016-12-31T23:59:60
2016-12-31T23:59:37  | 2016-01-01T00:00:00

this correspondence can be implemented in Python using the following
datetime objects:

TAI| UTC
---+---
datetime(2016,12,31,23,59,35)  | datetime(2016,12,31,23,59,59)
datetime(2016,12,31,23,59,36)  | datetime(2016,12,31,23,59,59,fold=1)
datetime(2016,12,31,23,59,37)  | datetime(2016,1,1,0,0,0)


Of course, Python will treat datetime(2016,12,31,23,59,59) and datetime(
2016,12,31,23,59,59,fold=1)as equal, but you should be able to use your
utc_to_tai(t) function to translate to TAI, do the arithmetic there and
translate back with the tai_to_utc(t) function.  Wherever tai_to_utc(t)
returns a datetime instance with fold=1, you should add that to the seconds
field before displaying.

> But still, now datetime *could* support leap seconds (which is nice,
because before, 23:59:60 was illegal, so it couldn't even be done at all),
but that doesn't mean that it DOES support leap seconds

By the same logic the standard library datetime does not support any local
time because it does not include the timezone database.  This is where the
3rd party developers should fill the gap.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 12:56 PM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:

> The other issue with leap-seconds is that python's datetime doesn't
support them :-)

That's not entirely true.  Since the implementation of PEP 495, it is
possible to represent the 23:59:60 as 23:59:59 with the "fold" bit set.  Of
course, the repeated 23:59:59 will be displayed and behave exactly the same
as the first 23:59:59, but a 3rd party library can be written to take the
"fold" bit into account in temporal operations.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Inline assignments using "given" clauses

[Alexander Belopolsky]

On Fri, May 11, 2018 at 11:43 AM Steven D'Aprano 
wrote:
> ...
> I agree with Jacco here. We have to name the variable twice, even if it
> is only used once, and we have a relatively long keyword, five
> characters, longer than average for all keywords, and only one char
> short of the maximum.

To be fair when counting the keystrokes, you should take into account that
the colon and the parentheses that appear in the := syntax are the upper
register keys that counting the shift require two keystrokes each.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] High Precision datetime

[Alexander Belopolsky]

> Is there interest in a PEP for extending time, datetime / timedelta for
arbitrary or extended precision fractional seconds?

Having seen the utter disaster that similar ideas brought to numpy, I would
say: no.

On the other hand, nanoseconds are slowly making their way to the stdlib
and to add nanoseconds to datetime we only need a fully backward compatible
implementation, not even a PEP.

See .
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Inline assignments using "given" clauses

[Alexander Belopolsky]

On Thu, May 10, 2018 at 9:44 AM, Guido van Rossum  wrote:
> I'm sorry, but unless there's a sudden landslide of support for 'given' in
> favor of ':=', I'm really not going to consider it.

How much support was there for ":="?  Are you serious about bringing
back Pascal and Algol from their comfortable resting places?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Inline assignments using "given" clauses

[Alexander Belopolsky]

On Fri, May 4, 2018 at 8:06 AM, Nick Coghlan  wrote:
> ...
> With that spelling, the three examples above would become:
>
> # Exactly one branch is executed here
> if m given m = pattern.search(data):
> ...
> elif m given m = other_pattern.search(data)):
> ...
> else:
> ...
>
> # This name is rebound on each trip around the loop
> while m given m = pattern.search(remaining_data):
> ...
>
> # "f(x)" is only evaluated once on each iteration
> result = [(x, y, x/y) for x in data if y given y = f(x)]

I think this is a step in the right direction.  I stayed away from the
PEP 572 discussions because while intuitively it felt wrong, I could
not formulate what exactly was wrong with the assignment expressions
proposals.  This proposal has finally made me realize why I did not
like PEP 572.  The strong expression vs. statement dichotomy is one of
the key features that set Python apart from many other languages and
it makes Python programs much easier to understand.  Right from the
title, "Assignment Expressions", PEP 572 was set to destroy the very
feature that in my view is responsible for much of Python's success.

Unlike PEP 572, Nick's proposal does not feel like changing the syntax
of Python expressions, instead it feels like an extension to the if-,
while- and for-statements syntax.  (While comprehensions are
expressions, for the purposes of this proposal I am willing to view
them as for-statements in disguise.)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] pdb to support running modules

[Alexander Belopolsky]

On Thu, Jan 4, 2018 at 8:15 PM, Guido van Rossum  wrote:
> Sounds uncontroversial, this can just be done via bugs.python.org.
>

.. and it has been proposed there over 7 years ago:
.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alexander Belopolsky]

On Mon, Oct 30, 2017 at 11:44 AM, Nick Coghlan  wrote:
..
> 3. We can't replicate it as readily in the regular REPL, since that runs
> Python code directly in the current process, but even there I believe we
> could potentially trigger a full process restart via execve (or the C++
> style _execve on Windows)

This exact problem is solved rather elegantly in Julia.  When you
upgrade a package that is already loaded in the REPL, it prints a
warning:

"The following packages have been updated but were already imported:
... Restart Julia to use the updated versions."

listing the affected packages.

See 
.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Alexander Belopolsky]

On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum  wrote:
> The proposal in your email seems incomplete

The proposal does not say anything about type((x=1, y=2)).  I assume
it will be the same as the type currently returned by namedtuple(?, 'x
y'), but will these types be cached? Will type((x=1, y=2)) is
type((x=3, y=4)) be True?.

> Regarding that spec, I think there's something missing: given a list (or
> tuple!) of values, how do you turn it into an 'ntuple'?

Maybe type((x=1, y=2))(values) will work?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] namedtuple with ordereddict

[Alexander Belopolsky]

On Wed, Jul 19, 2017 at 12:10 PM, Giampaolo Rodola' 
wrote:

>  Should have been something like this instead:
>
> $ python3.7 -m timeit -s "import collections; Point =
> collections.namedtuple('Point', ('x', 'y')); x = [5, 1]" "Point(*x)"
> 100 loops, best of 5: 311 nsec per loop
>
> $ python3.7 -m timeit -s "x = [5, 1]" "tuple(x)"
> 500 loops, best of 5: 89.8 nsec per loop
>

This looks like a typical python function call overhead.  Consider a toy
class:

$ cat c.py
class C(tuple):
def __new__(cls, *items):
return tuple.__new__(cls, items)

Comparing to a naked tuple, creation of a C instance is more than 3x slower.

$ python3 -m timeit -s "from c import C; x = [1, 2]" "C(*x)"
100 loops, best of 3: 0.363 usec per loop

$ python3 -m timeit -s "x = [1, 2]" "tuple(x)"
1000 loops, best of 3: 0.114 usec per loop
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Alexander Belopolsky]

On Mon, Jan 9, 2017 at 8:19 PM, Chris Barker  wrote:
>
> I think maybe by Dijkstra of C++ fame.

Dijkstra is famous for many things, but C++ is another Dutchman's fault.

Dijkstra's famous works include "GOTO Considered Harmful" [1] and "How do
we tell truths that might hurt?" [2].

[1]: http://wiki.c2.com/?GotoConsideredHarmful
[2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Alexander Belopolsky]

On Mon, Jan 9, 2017 at 8:12 PM, Simon Lovell  wrote:

> Re: Colons. I'm sure I've seen that FAQ before. I may be arrogant but I
> can't take it seriously. Being "slightly" easier to read is hardly a reason
> for a mandatory structure.
>

"Readability counts."  Did you notice that you placed a redundant ":"s in
every comment of yours after "Re"?  I don't think your message would look
better without them.

Another advantage of having : is that it allows smart editors to detect and
highlight errors sooner and to better perform auto-indentation.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

[Alexander Belopolsky]

On Wed, Dec 7, 2016 at 9:07 PM, Mikhail V  wrote:
>
> it somehow settled in
> peoples' minds that hex reference should be preferred, for no solid
reason IMO.

I may be showing my age, but all the facts that I remember about ASCII
codes are in hex:

1. SPACE is 0x20 followed by punctuation symbols.
2. Decimal digits start at 0x30 with '0' = 0x30, '1' = 0x31, ...
3. @ is 0x40 followed by upper-case letter: 'A' = 0x41, 'B' = 0x42, ...
4. Lower-case letters are offset by 0x20 from the uppercase ones: 'a' =
0x61, 'b' = 0x62, ...

Unicode is also organized around hexadecimal codes with various scripts
positioned in sections that start at round hexadecimal numbers.  For
example Cyrillic is at 0x0400 through 0x4FF <
http://unicode.org/charts/PDF/U0400.pdf>.

The only decimal fact I remember about Unicode is that the largest
code-point is 1114111 - a palindrome!
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Contribution Reward System

[Alexander Belopolsky]

On Mon, Nov 21, 2016 at 10:17 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> One practice that worked pretty well as motivation a few years ago was
> "review exchange" where a committer would offer one patch review in
> return for confirmation and triage of five new issues.  But I haven't
> seen that offer made explicitly for years.
>

I am not sure I made this offer publicly before, but with respect to
datetime module contributions, I have an outstanding offer to fill in the C
implementation for any patch that is otherwise complete (feature/bug fix
proposal is accepted, implemented in Python and the patch includes tests
and necessary documentation.)  I am also happy to offer a "review
exchange", but only within my areas of expertise.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python multi-dimensional array constructor

[Alexander Belopolsky]

On Wed, Oct 19, 2016 at 7:48 PM, Chris Barker  wrote:
>
>
> However, if you really don't like it, then you can pass a string to
aconfsturctor function instead:
>
> a = arr_from_string(" | 0, 1, 2 || 3, 4, 5 | ")
>
> yeah, you need to type the extra quotes, but that's not much.
>
> NOTE: I'm pretty sure numpy has something like this already, for folks
that like the MATLAB style -- though I can't find it at the moment.


You are probably thinking of the numpy.matrix constructor:

>>> a = np.matrix('1 2; 3 4')
>>> print(a)
[[1 2]
 [3 4]]

See .
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

[Alexander Belopolsky]

On Wed, Oct 12, 2016 at 5:57 PM, Elliot Gorokhovsky <
elliot.gorokhov...@gmail.com> wrote:

> On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith  wrote:
>
>> But this isn't relevant to Python's str, because Python's str never uses
>> UTF-8.
>>
>
> Really? I thought in python 3, strings are all unicode... so what encoding
> do they use, then?
>

No encoding is used.  The actual code points are stored as integers of the
same size.  If all code points are less than 256, they are stored as 8-bit
integers (bytes).  If some code points are greater or equal to 256 but less
than 65536, they are stored as 16-bit integers and so on.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delay evaluation of annotations

[Alexander Belopolsky]

On Thu, Sep 22, 2016 at 4:29 PM, אלעזר  wrote:

> Just as a demonstration, the parser can transform `EXP` into `lambda: EXP`
> - and that's it. It will not solve everything (e.g. error messages and
> .__annotation__ access as Alexander says), but it demonstrates the fact
> that the change need not be so deep at all.


On the second thought, why can't the parser a simply replace A with 'A' in
annotations that appear in the body of class A?  This will only break
somewhat pathological code that defines A before it is (re)defined by the
class statement.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delay evaluation of annotations

[Alexander Belopolsky]

On Thu, Sep 22, 2016 at 4:37 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> On the second thought, why can't the parser simply replace A with 'A' in
> annotations that appear in the body of class A?  This will only break
> somewhat pathological code that defines A before it is (re)defined by the
> class statement.


Then the default metaclass (type) can go over the annotations and replace
'A' with A that it just computed.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delay evaluation of annotations

[Alexander Belopolsky]

On Thu, Sep 22, 2016 at 3:58 PM, David Mertz  wrote:

> It's more verbose, but you can also spell it now as:
>
> class A:
> def __add__(self, other: type(self)) -> type(self): ...
>

No, you can't:

>>> class A:
... def __add__(self, other: type(self)) -> type(self): ...
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in A
NameError: name 'self' is not defined
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delay evaluation of annotations

[Alexander Belopolsky]

On Thu, Sep 22, 2016 at 1:19 PM, אלעזר  wrote:

> I propose delaying evaluation of annotation-expressions by either keeping
> the AST of the annotation, or turning it implicitly from EXP into "lambda:
> EXP". Inspection code that is interested in this information can access it
> be calling (or evaluating) it.
>
> It certainly isn't a backward compatible change
>

It can be made almost backward compatible by making __annotations__ a
property that calls your "lambda: EXP"s at the time when it is requested.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Make partial a built-in

[Alexander Belopolsky]

On Tue, Sep 20, 2016 at 11:51 AM, Guido van Rossum 
wrote:

> Also, I once timed it and could not show that partial was faster. This
> surprised me but it was what I measured (in one particular case).


I did similar timings on several occasions in the past and was also
surprised by the results.  Lambdas are often faster than equivalent
partials.  It looks like at least recent versions of Python have ways to
optimize calls to pure Python functions that are not available to functions
implemented in C or called from C.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Alexander Belopolsky]

On Sat, Sep 10, 2016 at 4:56 PM, Guido van Rossum  wrote:

> Another issue already discussed in PEP 505 is a conflict with IPython
> (Jupyter Notebook), which uses ? and ?? as custom syntax to request
> help. But maybe it can be taught to only recognize those when they're
> the last character(s) on the line?
>

I think this is already the case:

In [1]: ?foo
Object `foo` not found.

In [2]: foo?
Object `foo` not found.

In [3]: foo?bar
  File "", line 1
foo?bar
   ^
SyntaxError: invalid syntax
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Shuffled

[Alexander Belopolsky]

On Wed, Sep 7, 2016 at 9:12 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> On Wed, Sep 7, 2016 at 8:14 PM, Arek Bulski <arek.bul...@gmail.com> 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?


It may be instructive for you to see how this functionality is implemented
in CPython's own test suit:

https://github.com/python/cpython/blob/276f4ef97a434d4279a2d207daa34cafcf0994f7/Lib/test/libregrtest/main.py#L230
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Shuffled

[Alexander Belopolsky]

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 this can be easily done with pytest:

In [1]: def foo(x):
   ...: return x + 1
   ...:

In [2]: import pytest

In [3]: @pytest.mark.parametrize('x, y', [
   ...: (100, 101),
   ...: (200, 201),
   ...: (300, 301),])
   ...: def test_foo(x, y):
   ...: assert foo(x) == y
   ...:

In [4]: test_foo.parametrize.args
Out[4]: ('x, y', [(100, 101), (200, 201), (300, 301)])

In [5]: import random

In [6]: random.shuffle(test_foo.parametrize.args[1])

In [7]: test_foo.parametrize.args
Out[7]: ('x, y', [(200, 201), (100, 101), (300, 301)])
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Adding optional parameter to shutil.rmtree to not delete root.

[Alexander Belopolsky]

> On Aug 25, 2016, at 3:27 PM, Nick Jacobson via Python-ideas 
>  wrote:
> 
> +1 for clear_dir()
> 
> I agree that there's no other obvious meaning that it could have.

+1, but I think "cleardir" would better match naming conventions in the shutil 
module. 

(My personal rule of thumb on the use of underscores in function names is to 
omit them if any name component is abbreviated.  So either spell it out as 
clear_directory or shorten as cleardir.)___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/