Hi,
I don't know if this was already debated but I don't know how to search
in the whole archive of the list.
For now the adoption of pyproject.toml file is more difficult because
toml is not in the standard library.
Each tool which wants to use pyproject.toml has to add a toml lib as a
conditional or hard dependency.
Since toml is now the standard configuration file format, it's strange
the python does not support it in the stdlib lije it would have been
strange to not have the configparser module.
I know it's complicated to add more and more thing to the stdlib but I
really think it is necessary for python packaging being more consistent.
Maybe we could thought to a readonly lib to limit the added code.
If it's conceivable, I'd be happy to help in it.
Nice Day guys and girls.
Jimmy
> On Friday, April 6, 2018 at 8:14:30 AM UTC-7, Guido van Rossum wrote:
> On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor <peter.ed...(a)gmail.com> wrote:
>> So some more humble proposals would be:
>>
>> 1) An initializer to itertools.accumulate
>> functools.reduce already has an initializer, I can't see any controversy to adding an initializer to itertools.accumulate
>
> See if that's accepted in the bug tracker.
It did come-up once but was closed for a number reasons including lack of use cases. However, Peter's signal processing example does sound interesting, so we could re-open the discussion.
For those who want to think through the pluses and minuses, I've put together a Q&A as food for thought (see below). Everybody's design instincts are different -- I'm curious what you all think think about the proposal.
Raymond
---------------------------------------------
Q. Can it be done?
A. Yes, it wouldn't be hard.
_sentinel = object()
def accumulate(iterable, func=operator.add, start=_sentinel):
it = iter(iterable)
if start is _sentinel:
try:
total = next(it)
except StopIteration:
return
else:
total = start
yield total
for element in it:
total = func(total, element)
yield total
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.accumulat...
* https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html
* http://microapl.com/apl/apl_concepts_chapter5.html
\+ 1 2 3 4 5
1 3 6 10 15
* https://reference.wolfram.com/language/ref/Accumulate.html
* https://www.haskell.org/hoogle/?hoogle=mapAccumL
Q. How much work for a person to do it currently?
A. Almost zero effort to write a simple helper function:
myaccum = lambda it, func, start: accumulate(chain([start], it), func)
Q. How common is the need?
A. Rare.
Q. Which would be better, a simple for-loop or a customized itertool?
A. The itertool is shorter but more opaque (especially with respect
to the argument order for the function call):
result = [start]
for x in iterable:
y = func(result[-1], x)
result.append(y)
versus:
result = list(accumulate(iterable, func, start=start))
Q. How readable is the proposed code?
A. Look at the following code and ask yourself what it does:
accumulate(range(4, 6), operator.mul, start=6)
Now test your understanding:
How many values are emitted?
What is the first value emitted?
Are the two sixes related?
What is this code trying to accomplish?
Q. Are there potential surprises or oddities?
A. Is it readily apparent which of assertions will succeed?
a1 = sum(range(10))
a2 = sum(range(10), 0)
assert a1 == a2
a3 = functools.reduce(operator.add, range(10))
a4 = functools.reduce(operator.add, range(10), 0)
assert a3 == a4
a4 = list(accumulate(range(10), operator.add))
a5 = list(accumulate(range(10), operator.add, start=0))
assert a5 == a6
Q. What did the Python 3.0 Whatsnew document have to say about reduce()?
A. "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable."
Q. What would this look like in real code?
A. We have almost no real-world examples, but here is one from a StackExchange post:
def wsieve(): # wheel-sieve, by Will Ness. ideone.com/mqO25A->0hIE89
wh11 = [ 2,4,2,4,6,2,6,4,2,4,6,6, 2,6,4,2,6,4,6,8,4,2,4,2,
4,8,6,4,6,2,4,6,2,6,6,4, 2,4,6,2,6,4,2,4,2,10,2,10]
cs = accumulate(cycle(wh11), start=11)
yield( next( cs)) # cf. ideone.com/WFv4f
ps = wsieve() # codereview.stackexchange.com/q/92365/9064
p = next(ps) # 11
psq = p*p # 121
D = dict( zip( accumulate(wh11, start=0), count(0))) # start from
sieve = {}
for c in cs:
if c in sieve:
wheel = sieve.pop(c)
for m in wheel:
if not m in sieve:
break
sieve[m] = wheel # sieve[143] = wheel@187
elif c < psq:
yield c
else: # (c==psq)
# map (p*) (roll wh from p) = roll (wh*p) from (p*p)
x = [p*d for d in wh11]
i = D[ (p-11) % 210]
wheel = accumulate(cycle(x[i:] + x[:i]), start=psq)
p = next(ps) ; psq = p*p
next(wheel) ; m = next(wheel)
sieve[m] = wheel
> Date: Thu, 7 Jun 2018 12:33:29 +0000
> From: Robert Vanden Eynde <robertvandeneynde(a)hotmail.com>
> To: python-ideas <python-ideas(a)python.org>
> Subject: [Python-ideas] Trigonometry in degrees
> Message-ID:
> >
> I suggest adding degrees version of the trigonometric functions in the math module.
>
> - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a function.
I agree that degrees are useful for teaching. They are also very
useful for graphics
programming, especially with my favourite OpenGL API. But I think that
the use of
radians in programming language APIs is more prevalent, so the initial advantage
of easy learning will be outweighed by the long term inconvenience of
adjusting to
what everyone else is doing.
Writing degrees(x) and radians(x) is a little inconvenient, but it
does make it clear
what units are being used. And even if your proposal is adopted, there
is still going
to be a lot of code around that uses the older math routines. With the
current API
it is a least safe to assume that angles are radians unless stated otherwise.
> - Special values could be treated, aka when the angle is a multiple of 90, young students are often surprise to see that cos(pi/2) != 0
>
> Testing for a special value Isn't very costly (x % 90 == 0) but it could be pointed out that there is a small overhead using the "degrees" equivalent of trig function because of the radians to degrees conversion And the special values testing.
Not just young students :-) I agree with this, but I would prefer the
check to be in
the implementation of the existing functions as well. Any sin/cos very
close to 0
becomes 0, any close to 1 becomes 1.
> - Standard names will be chosen so that everyone will use the same name convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, atan2d.
Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d"
means "double precision". It's even sort of implied by the C math
library which has
sinf and friends for single precision.
>
> Creating a new package like 'from math.degrees import cos' however I would not recommend that because "cos" in the source code would mean to lookup the import to know if it's in degrees or radians (and that leads to very filthy bugs). Also "degrees" is already so the name would have to change the name of the package.
Agree, not a good idea.
--
cheers,
Hugh Fisher
This idea was proposed to me at the core sprints last month by Larry
Hastings. I've discussed it with a few people, who seem generally
positive about it, and we've tweaked it a little bit. I've spent some
time implementing it, and I think it's doable. I thought I'd post it
here for any additional feedback.
Here’s the idea: for f-strings, we add a !d conversion operator, which
is superficially similar to !s, !r, and !a. The meaning of !d is:
produce the text of the expression (not its value!), followed by an
equal sign, followed by the repr of the value of the expression. So:
value = 10
s = 'a string!'
print(f'{value!d}')
print(f'next: {value+1!d}')
print(f'{s!d}')
produces:
value=10
next: value+1=11
s='a string!'
I’m not proposing this for str.format(). It would only really make sense
for named arguments, and I don’t think
print('{value!d}'.format(value=value) is much of a win.
The result is a string, so if you really wanted to, you could use a
string formatting spec. So:
print(f'*{value!d:^20}*'
would produce:
* value=10 *
Although I don’t think that would be very useful in general.
The mnemonic is !d for “debugging”. I’d wanted to use !=, because
there’s an equal sign involved in the result, but = is the one character
that can’t be used after ! (it’s “not equal” in expressions, and
f-strings look specifically for that case). I also mentioned !!, but I
think I prefer !d as being less confusing.
This would be used in debugging print statements, that currently end up
looking like:
print(f'value={value!r}')
and would now be:
print(f'{value!d}')
There have been discussions about ways to specify str() vs. repr(),
using characters other than '=', adding spaces, etc. But they all end up
over-complicating what should be a simple tool, not a Swiss Army knife.
Thoughts?
Eric
I'd like to suggest what I think would be a simple addition to `def` and
`class` blocks. I don't know if calling those "Assignment Blocks" is
accurate, but I just mean to refer to block syntaxes that assign to a name.
Anyway, I propose a combined return-def structure, and optionally also
allowing a return-class version. Omitting the name would be allowable, as
well.
This would only apply to a `def` or `class` statement made as the last part
of the function body, of course.
def ignore_exc(exc_type):
return def (func):
@wraps(func)
return def (*args, **kwargs):
try:
return func(*args, **kwargs)
except exc_type:
pass
Thanks for considering and for any comments, thoughts, or feedback on the
idea!
Dear all,
Who might also be interested in setting up a project that supports localization for Unicode block description and character description.
Translations are available from https://github.com/unicode-table/unicode-table-data/tree/master/loc
<https://github.com/unicode-table/unicode-table-data/tree/master/loc> If possible, use a gettext approach similar to https://pypi.org/project/pycountry/ <https://pypi.org/project/pycountry/>
Implementing this feature will allow users to read Unicode descriptions in their own language, other than English.
For example, now is possible only in English:
from unicodedata import name
print(name('ß'))
LATIN SMALL LETTER SHARP S
So unicodedata could provide a way to translate LATIN SMALL LETTER SHARP S to e.g. German with:
from unicodedata import name
from unicodedata_l10n import LOCALED_DIR
from gettext import translation
german = translation('UnicodeData' LOCALED_DIR, languages=['de'])
german.install()
print(_(name('ß')))
LATEINISCHER KLEINBUCHSTABE SCHARFES S
and something similar for unicodedata.category
Best,
Pander
Hello,
During the last 10 years, Python has made steady progress in convenience to
assemble strings. However, it seems to me that joining is still, when
possible, the cleanest way to code string assembly.
However, I'm still sometimes confused between the different syntaxes used
by join methods:
0. os.path.join takes *args
1. str.join takes a list argument, this inconsistence make it easy to
mistake with the os.path.join signature
Also, I still think that:
'_'.join(['cancel', name])
Would be more readable as such:
['cancel', name].join('_')
Not only this would fix both of my issues with the current status-quo, but
this would also be completely backward compatible, and probably not very
hard to implement: just add a join method to list.
Thanks in advance for your reply
Have a great day
--
∞
Hey List,
this is my very first approach to suggest a Python improvement I'd think
worth discussing.
At some point, maybe with Dart 2.0 or a little earlier, Dart is now
supporting multiline strings with "proper" identation (tried, but I can't
find the according docs at the moment. probably due to the rather large
changes related to dart 2.0 and outdated docs.)
What I have in mind is probably best described with an Example:
print("""
I am a
multiline
String.
""")
the closing quote defines the "margin indentation" - so in this example all
lines would get reduces by their leading 4 spaces, resulting in a "clean"
and unintended string.
anyways, if dart or not, doesn't matter - I like the Idea and I think
python3.x could benefit from it. If that's possible at all :)
I could also imagine that this "indentation cleanup" only is applied if the
last quotes are on their own line? Might be too complicated though, I can't
estimated or understand this...
thx for reading,
Marius
I keep coming back to this great video <https://vimeo.com/74316116> about
coding style, and one point in particular rings true to me:
ALL_CAPS_IS_OBNOXIOUS
It destroys the visual flow of code and for what? To signify a global,
constant, or Enum? Is that really so important? I don't think so. I think
the all caps style has out-lived its usefulness and needs to go the way of
the dodo.
The last time I saw all caps used appropriately was in a YouTube comment
where some guy was ranting about the communist Jewish banker conspiracy to
control the world. In that case, all caps clearly communicated to me that
the person was a frothing lunatic (thought find the idea of communist
bankers intriguing).
Currently PEP-8 prescribes all caps for constants
<https://www.python.org/dev/peps/pep-0008/#constants> and uses the all cap
variable "FILES" as an example in a different section.
<https://www.python.org/dev/peps/pep-0008/#when-to-use-trailing-commas> It
also appears to be the defacto-standard for enums (based on the
documentation <https://docs.python.org/3/library/enum.html#creating-an-enum>
)
I don't think it's necessary to make any breaking changes. Just pep-8 and
(of less importance) spurious documentation examples.
I've found that almost any time I'm writing a 'with' block, it's doing
something that could throw an exception. As a result, each of those
'with' blocks needs to be nested within a 'try' block. Due to the
nature of 'with', it is rarely (if ever) the case that the try block
contains anything other than the with block itself.
As a result, I would like to propose that the syntax for 'with' blocks
be changed such that they can be accompanied by 'except', 'finally',
and/or 'else' blocks as per a standard 'try' block. These would handle
exceptions that occur in the 'with' block, including the execution of
the applicable __enter__ and __exit__ methods.
Example:
try:
with open(path) as myfile:
... # Do stuff with file
except (OSError, IOError) as err:
logger.error("Failed to read/open file {}: {}".format(path, err)
The above would turn into simply:
with open(path) as myfile:
... # Do stuff with file
except (OSError, IOError) as err:
logger.error(...)
I think this is rather straightforward in meaning and easy to read,
and simplifies some unnecessary nesting. I see this as the natural
evolution of what 'with'
is all about - replacing necessary try-finally blocks with something
more elegant. We just didn't include the 'except' portion.
I'm a bit hesitant to put this out there. I'm not worried about it
getting shot down - that's kind of the point here. I'm just pretty
strongly against to unnecessary syntactical additions to the language.
This though, I think I can except. It introduces no new concepts and
requires no special knowledge to use. There's no question about what
is going on when you read it.
--
Paul Ferrell
pflarr(a)gmail.com
