> This is already valid in 3.8, so we should forget about overloading :=
> with a second meaning.
def func(x=(a:=expression), y=a+1):
def func(x:=options):
These two syntaxes do not conflict with each other.
> Do we want to encourage callers to pass None to
> indicate default
> arguments?
>
"<:" Does not give the user any intuition about what it does.
"<~" Ok, but same problems as "<:" and precludes the use of "<~~" due to
Python's parser.
"::" Could be confused with Haskell's type declaration operator.
If we want to avoid confusion with the walrus operator, "options!?=..." is a
I don't see myself using := for a few years, because support for Python 3.8
is not widespread yet among PyPy. However, that doesn't mean I oppose
evolving the language further so that down the line when Python 3.10
is ready, I'll have juicy new features to use.
> # Looks like an old Py2 repr
> def spam(x, y, ham={}):
> # Way too magical, although it parses currently and might
> # be done with the help of a magic built-in
> def spam(x, y, ham=LATE%{}):
> # wut?
> def spam(x, y, ham=>{}):
> # even worse
> def spam(x, y, ham=->{}):
> etc etc etc. There are
Thank you for raising a good point. I think we should ban referencing variables
not in the nearest outer enclosing scope until best practices regarding
closures emerge. For example:
global_var = 5
class A:
# not ok:
def foo(a:=global_var):
pass
class_var = global_var
# ok:
The "if arg is None: arg = " pattern occurs in the standard library eighty-five
(85) times.
This command was used to find the count:
~/cpython/Lib$ perl -wln -e "/(?s)^(\s*)[^\n]if ([a-zA-Z_]+) is
None:(\n)?\s+\2\s*=\s*/s and print" **
___
"There should be one-- and preferably only one --obvious way to do it."
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Many a python programmer have tired to see code written like:
def bar(a1, a2, options=None):
if options is None:
options = {}
... # rest of function
syntax if argument is not passed, evaluate {} and store to options
def foo(options:={}): pass
syntax if argument is not passed or is
On Wed, Feb 19, 2020 at 5:23 PM FilippoM wrote:
>
> Hi, I've got a Pandas data frame that looks like this
>
> In [69]: data.head
> Out[69]:
> 0 AndroidVIDEO_OK
> 1 Android 4.2.2 VIDEO_OK
> 2 Android 9 VIDEO_OK
> 3 iOS 13.3 VIDEO_OK
> 4
I use macOS, and using Python is very confusing.
- Apple's bundled Python 2.7.
- Anaconda (Python scientific stack package manager) Python and conda.
- Homebrew (3rd party package manager for macOS) Python and pip.
I also believe that there is a PSF Python installer, but I am not sure.
Python,
Ideally, we'd have a functional package manager: one that can delete
binaries when disk space is running low, and recompiles from sources when
the binary is needed again. It could store Python 2 as a series of diffs
against Python 3.
On Thu, Jan 2, 2020, 2:22 AM Abdur-Rahmaan Janhangeer
wrote:
Sent from my iPhone
Begin forwarded message:
> From: James Lu
> Date: July 28, 2019 at 6:22:11 PM EDT
> To: Andrew Barnert
> Subject: Re: [Python-ideas] Utilities for easier debugging
>
>
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert wrote:
>>
>>
Sent from my iPhone
Begin forwarded message:
> From: James Lu
> Date: July 28, 2019 at 6:21:04 PM EDT
> To: Andrew Barnert
> Subject: Re: [Python-ideas] Utilities for easier debugging
>
>
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert wrote:
>>
>> Why
Sent from my iPhone
Begin forwarded message:
> From: James Lu
> Date: July 28, 2019 at 6:22:11 PM EDT
> To: Andrew Barnert
> Subject: Re: [Python-ideas] Utilities for easier debugging
>
>
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert wrote:
>>
>>
Sent from my iPhone
Begin forwarded message:
> From: James Lu
> Date: July 28, 2019 at 6:21:04 PM EDT
> To: Andrew Barnert
> Subject: Re: [Python-ideas] Utilities for easier debugging
>
>
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert wrote:
>>
>> Why
Sent from my iPhone
Begin forwarded message:
> From: James Lu
> Date: July 28, 2019 at 6:23:06 PM EDT
> To: Andrew Barnert
> Subject: Re: [Python-ideas] Utilities for easier debugging
>
>
>> On Jul 28, 2019, at 4:26 PM, Andrew Barnert wrote:
>>
>> Y
Minimal strawman proposal. New keyword debug.
debug EXPRESSION
Executes EXPRESSION when in debug mode.
debug context
Prints all the variables of the enclosing closure and all the variable names
accessed within that block. For example, if in foo you access the global
variable spam, spam
> On Jun 26, 2019, at 7:13 PM, Chris Angelico wrote:
>
> The main advantage of sscanf over a regular expression is that it
> performs a single left-to-right pass over the format string and the
> target string simultaneously, with no backtracking. (This is also its
> main DISadvantage compared
What if we had reverse format strings, i.e. reading formatted input?
x = readf("{:.0%}", "50%")
# => x == 0.50
x = readf("{:.0}", "50")
# => x == 0.50
Readf takes the repr() of its second argument and “un-formats” the string.
___
Python-ideas mailing
Make $ a valid identifier and a singleton.
$ is a useful placeholder in [].
Possible function partial syntax:
def foo(x, y):
print(x, y)
partialized = foo[$, 10]
partialized(5)
# => 5 10
___
Python-ideas mailing list -- python-ideas@python.org
If a function that tends to return a context manager returns None, that should
not mean an error occurred. If an error or unexpected condition occurred, an
exception should be thrown. Errors and exceptions should result in the code
within the with statement not executing.
We could add a new
# regular code
unittest:
# test code goes here
This code would be run when the runtime -unittest flag is passed. It would
function as test usages and example client code. The code within the block
would remain in .pyc, unless the -O switch is passed.
Write "" or ## above a unittest to
> python is not build for speed
Yes, but it scales to speed, letting you speed up your code easily when you
need it. Consider Cython and Nuitka. Consider GraalPython. Consider... consider
that C dylibs can be loaded and used from within Python without any wrappers.
You can create the <-
There is probably some existing python API you can hijack to make custom
locals() and globals() work everywhere. Perhaps pdb and inspect.stack are good
places to start; maybe there’s a PDB API to break on every new stack frame and
maybe you can use inspect to do the proper assignment overrides.
Perhaps you should take a look at Dlang. Using opDispatch and a with statement
and compile time code generation, you may be able to accomplish what you’re
trying to do entirely in D.
> On May 24, 2019, at 4:05 AM, Yanghao Hua wrote:
>
>> On Fri, May 24, 2019 at 1:59 AM Steven D'Aprano wrote:
`if-unless` expressions in Python
if condition1 expr unless condition2
is an expression that roughly reduces to
expr if condition1 and not condition2 else EMPTY
This definition means that expr is only evaluated if `condition1 and not
condition2` evaluates to true. It also means `not
https://github.com/graalvm/graalpython
https://www.python.org/download/alternatives/
GraalPython is an implementation on the Truffle VM, by Oracle Labs. The
Truffle
VM gives Python high-performance interoperability with other languages-
including JVM, LLVM, Ruby, and JavaScript. The Truffle VM is
I think a Python version of longjmp() and setjmp() might be easier to
understand.
On Sun, May 12, 2019 at 6:23 PM David Mertz wrote:
> On Sun, May 12, 2019, 5:36 PM Paul Moore wrote:
>
>> On Sun, 12 May 2019 at 21:06, David Mertz wrote:
>> > I thought of 'as' initially, and it reads well as
Stack-based LL(1) push down automata can be implemented by hand, indeed isn’t
that that a textmateLanguage file is? There’s also the option of using Iro to
generate a tmLanguage.
___
Python-ideas mailing list
Python-ideas@python.org
When
from __future__ import runtime_default_kwargs
Is run,
def a(b=1, c=b+2, d=[]):
pass
behaves as (if the peephole optimizer didn’t exist)
def a(b=None, c=None):
if b is None:
b = 1
if c is None:
c = b + 2
if d is None:
d = []
i.e. the keyword
This is a horrible idea.
I proposed to Mr. Fine earlier that we adopt a << operator.
d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2
overriding keys from d2.
On Sat, Mar 9, 2019 at 4:50 PM Jonathan Fine wrote:
> A good starting point for discussing the main idea is:
>
Now, this belongs as a separate PEP, and I probably will write one, but I
propose:
d1 << d2 makes a copy of d1 and merges d2 into it, and when the keys conflict,
d2 takes priority. (Works like copy/update.)
d1 + d2 makes a new dictionary, taking keys from d1 and d2. If d1 and d2 have a
that, but a large portion of Python users primarily use online
documentation
James Lu
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
By the way, my “no same keys with different values” proposal would not apply to
+=.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
> On Mar 4, 2019, at 11:25 AM, Steven D'Aprano wrote:
>
> The PEP gives a good example of when this "invariant" would be
> unnecessarily restrictive:
>
>For example, updating default configuration values with
>user-supplied values would most often fail under the
>requirement
> On Mon, Mar 04, 2019 at 10:01:23AM -0500, James Lu wrote:
>
> If you want to merge it without a KeyError, learn and use the more explicit
> {**d1, **d2} syntax.
On Mar 4, 2019, at 10:25 AM, Steven D'Aprano wrote:
> In your previous email, you said the {**d ...} synt
> On Mar 4, 2019, at 10:02 AM, Stefan Behnel wrote:
>
> INADA Naoki schrieb am 04.03.19 um 11:15:
>> Why statement is not enough?
>
> I'm not sure I understand why you're asking this, but a statement is "not
> enough" because it's a statement and not an expression. It does not replace
> the
> On Mar 4, 2019, at 3:41 AM, Stefan Behnel wrote:
>
> James Lu schrieb am 04.03.19 um 03:28:
>> I propose that the + sign merge two python dictionaries such that if there
>> are conflicting keys, a KeyError is thrown.
>
> Please, no. That would be really
I propose that the + sign merge two python dictionaries such that if there are
conflicting keys, a KeyError is thrown.
This way, d1 + d2 isn’t just another obvious way to do {**d1, **d2}. The second
syntax makes it clear that a new dictionary is being constructed and that d2
overrides keys
I agree with Storchaka here. The advantage of existing dict merge syntax is
that it will cause an error if the object is not a dict or dict-like object,
thus preventing people from doing bad things.
> On Feb 28, 2019, at 2:16 AM, Serhiy Storchaka wrote:
>
> 27.02.19 20:48, Guido van Rossum
A general rule of thumb is, if Python feels inconvenient or awkward, you’re
doing something wrong.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
Has anyone thought about my proposal yet? I think because it allows chained
function calls to be stored, which is probably something that is a common; if
imagine people turning the same series of chained functions into a lambda of
its own once it’s used more than once in a program.
Arguably,
Sometimes I see threads briefly go into topics that are unrelated to new
features in Python. For example: talking about a writer’s use of
“inhomogeneous” vs “heterogenous” vs “anhomogenous.” We get what the original
author meant, there is no need to fiddle with the little details of language at
Here are some alternate syntaxes.
These are all equivalent to len(print(list)).
(len | print)(list)
(len |> print)(list)
(print <| len)(list)
print <| len << list
list >> print <| len
list >> len |> print
## Traditional argument order
print <| len << list
## Stored functions
print_lengths =
I agree with everything all of you have said in reply to me.
Sent from my iPhone
> On Feb 3, 2019, at 7:34 PM, Ned Batchelder wrote:
>
>> On 2/3/19 6:01 PM, Steven D'Aprano wrote:
>> (1) Taking the group discussion off-list should be done rarely, and
>> usually only for personal messages that
https://www.python.org/download/alternatives/ should possibly mention:
- Cython and Nuitka
- Mention the possibility of compiling Python to WASM
- WASM allows Web and Mobile use of Python at possibly native speed.
Though not mature yet, Pyodide is a working implementation.
>> On Feb 2, 2019, at 7:17 PM, Steven D'Aprano wrote:
>>
>> On Sat, Feb 02, 2019 at 11:12:02AM -0500, James Lu wrote:
>>
>> This list IS hard for newcomers. I wish there was one place where I
>> could read up on how to not feel like a noob.
>
Well, the question wasn’t about any specific proposal but improving
communication in general. I don’t have a specific straw man.
Sent from my iPhone
> On Feb 2, 2019, at 7:00 PM, Steven D'Aprano wrote:
>
>> On Sat, Feb 02, 2019 at 10:59:36AM -0500, James Lu wrote:
>>
growing-so-quickly-future-trends
> https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
> Are there indicators we are missing?
>
> --Ned.
>
>> On 2/2/19 11:56 PM, James Lu wrote:
>> Sent from my iPhone
>>
>>&g
n blog or Facebook account if you feel so strongly about it.
>
> Regards
>
> Antoine.
>
>
> On Sat, 2 Feb 2019 11:04:40 -0500
> James Lu wrote:
>> I want y’all to think about this very carefully. What factors led Guido to
>> quit? And I don’t want you to just r
There is no need for any of you to argue over this small point. Tolerate each
other’s language.
Sent from my iPhone
> On Feb 2, 2019, at 3:58 AM, Steven D'Aprano wrote:
>
>> On Sat, Feb 02, 2019 at 05:10:14AM +, MRAB wrote:
>>> On 2019-02-02 04:32, Steven D'Aprano wrote:
>>> [snip]
>>>
Sent from my iPhone
> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote:
>
>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote:
>>
>>> - the status quo means "no change", so there is no hassle there;
>>
>> Not quite true. There is a constant hassle of "do I need to write
>>
I think we need to step away from the egalitarian ideal and have some way of
knowing that Python committees are python committers. It’s really difficult to
know how well your proposal is doing without having this.
___
Python-ideas mailing list
This list IS hard for newcomers. I wish there was one place where I could read
up on how to not feel like a noob.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
I want y’all to think about this very carefully. What factors led Guido to
quit? And I don’t want you to just reply with the first thing that comes off
your head. The purpose of this question/discussion is to identify problems with
the Python community so we can fix them.
That is the only real
It’s very demotivating to hear just negative feedback on this list.
Was starting this thread useful for y’all?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
> I want the discussion to focus not only on technical solutions like +1 or
> Mailman 3, but also social ones and how to better express oneself.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
It’s difficult to learn anything with a body (such as a loop or a class or a
function) with the built in REPL because you can’t edit lines you’ve already
written.
Sent from my iPhone
> On Feb 1, 2019, at 1:44 PM, Steven D'Aprano wrote:
>
>> On Fri, Feb 01, 2019 at 09:07:14AM -05
How do ideas on this mailing list turn into features? What is the typical
roadmap? Can this process be documented somewhere?___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
A lot of the traffic on this email list is people saying “I don’t understand”
or “that’s not what I meant” or trying to re-explain. A lot of “-1”s are really
“I don’t see the usefulness of this”.
So I want an open discussion on: How can we communicate clearer?
I always use ptipython (ptpython shell over the ipython console) for my
REPLs. The built-in python repl is not *batteries included* in the sense
that it already has what you need to explore the language.
I wonder, what do the python committers think about including a
stripped-down version of
ion, I've been working on an example
implementation I'll send soon for backtick expressions.
I've also been doing the "look for use cases in stdlib" thing that
Johnathan and Steve mentioned.
On Wed, Jan 23, 2019 at 3:02 AM Bruce Leban wrote:
> On Sun, Jan 20, 2019 at 6:43 PM
I’m a little busy recently, so I’ll reply to as much as I can now and reply to
the rest later.
Scratch the stuff I said about scope. Backtick expressions should inherit the
scope normally like any other nested function.
> That's different behaviour from regular functions, where names are only
Later today I will send a working implementation of backtick expressions as a
function call.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
> On Jan 21, 2019, at 1:56 AM, Steven D'Aprano wrote:
>
> It disturbs me that you believe you get to tell everyone what syntax
> highlighting they should use for this feature. That's pretty
> dictatorial, and not in a good BDFL way.
I don’t want to tell anyone how to make their syntax
> On Jan 21, 2019, at 1:56 AM, Steven D'Aprano wrote:
>
> It disturbs me that you believe you get to tell everyone what syntax
> highlighting they should use for this feature. That's pretty
> dictatorial, and not in a good BDFL way.
I don’t want to tell anyone how to make their syntax
So here’s an interesting idea, not a proposal yet.
In C++20, a Concept is a list of Boolean expressions with a name that can be
used in place of a type in a templated (ie type-generic) function.
from typing import Concept
Iterator = Concept(lambda o: hasattr(o, "__iter__", lambda o: iter(o) !=
The file system is really just a b-tree. If you’re concerned about using memory, you can implement a O(log n) map using the file system, where the entires are the different critical sections.Every node is a folder and every file is a leaf. Many package managers implement maps like this. I’d like
I think the confusion would be minimal and not worth the hassle of renaming to
pcontract. People would just say “Python icontract” when it’s ambiguous.
Sent from my iPhone
> On Oct 1, 2018, at 3:28 AM, Marko Ristin-Kaufmann
> wrote:
>
> Hi Cameron,
> A nerdy way to make it sound like a
it will use MockP protocol and otherwise it will check the object is callable
and treat it as a lambda.
Your approach has better type hinting, but I’m not sure if type hinting would
be that useful if you’re adding a contract whilst writing the function.
James Lu
> On Oct 1, 2018, at 1:01 AM, Ma
place for that:
> https://github.com/Parquery/icontract/issues
>
> It reads a bit easier as a discussion rather than a single document -- if
> anybody else needs to follow. What do you think?
>
> On Sun, 30 Sep 2018 at 22:07, James Lu wrote:
>
>> Hi Marko,
>&g
It has a nice GUI for people who spectate a discussion to read emails
without having to subscribe to the list.
http://docs.mailman3.org/en/latest/migration.html
___
Python-ideas mailing list
Python-ideas@python.org
the point may be moot
if the natural indentation also gives the same visual alignment.
Though both should be supported so the best syntax may win.
James Lu
> On Sep 29, 2018, at 3:22 PM, Marko Ristin-Kaufmann
> wrote:
>
> I reread the proposal with MockP. I still don't get
syntax should be supported?
Would
with requiring: assert arg1 < arg2, “message”
Be the code you type or the code that’s actually run?
James Lu
> On Sep 29, 2018, at 2:56 PM, Marko Ristin-Kaufmann
> wrote:
>
> Just
___
Python-ideas mail
Hi Marko,
> If the documentation is clear, I'd expect the user to be able to distinguish
> the two. The first approach is shorter, and uses magic, but fails in some
> rare situations. The other method is more verbose, but always works.
I like this idea.
James Lu
> On Sep 29, 2018
inking an editable document like HackMD where we can label all
the different ideas to keep them straight in our head.
James Lu
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://pyth
Many editors highlight decorators in a different color that makes it easier to
ignore and can also fold decorators.
Contracts can also sometimes actively improve the flow of code.
I personally find a formal contract easier to read than informal documentation.
It also reduces the times where
Let’s get some ideas for how icontract can say “it should throw an exception if
this happens.”
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
me and you can still explain in three-four
>> sentences what happens below the hub in the library's docs. A
>> pycharm/pydev/vim/emacs plugins could hide the verbose parts.
>>
>> I performed a small experiment to test how this solution plays with pylint
>> and it seem
eriment to test how this solution plays with pylint
> and it seems OK that arguments are not used in lambdas.
>
> Cheers,
> Marko
>
>
>> On Thu, 27 Sep 2018 at 12:27, James Lu wrote:
>> Why couldn’t we record the operations done to a special object and replay
>>
> As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are
> items = ["foo", "bar", "quux"]
> items[randrange(3)] .= upper()
>
> Is this equivalent to:
>
> items[randrange(3)] = items[randrange(3)].upper()
>
> ? That would call randrange twice, potentially grabbing one element
> and dropping it into another slot. If it isn't equivalent to that, how
> is
full power of a lambda. It’s arguably more succinct and readable, though YMMV.
I look forward to reading your opinion on this and any ideas you might have.
> On Sep 26, 2018, at 3:56 PM, James Lu wrote:
>
> Hi Marko,
>
>> Actually, following on #A4, you could also w
; for "old" and "P" for parameters in a condition:
> @post(lambda O, P: ...)
> ?
>
> It also has the nice property that it follows both the temporal and the
> alphabet order :)
>
>> On Wed, 26 Sep 2018 at 14:30, James Lu wrote:
>> I still prefe
> It's easy to say that they're boolean expressions. But that's like
> saying that unit tests are just a bunch of boolean expressions too.
> Why do we have lots of different forms of test, rather than just a big
> fat "assert this and this and this and this and this and this"?
> Because the key to
repeat could be only considered a keyword when it’s used as a loop
Sent from my iPhone
> On Sep 26, 2018, at 8:46 AM, Brice Parent wrote:
>
>> Le 26/09/2018 à 14:33, James Lu a écrit :
>> what about “repeat:”?
>>
>> Sent from my iPhone
> I'm not sure it was
I still prefer snapshot, though capture is a good name too. We could use
generator syntax and inspect the argument names.
Instead of “a”, perhaps use “_”. Or maybe use “A.”, for arguments. Some people
might prefer “P” for parameters, since parameters sometimes means the value
received while
> I'm surprised you haven't found
>inspect.getsource(func)
I did. That’s exactly what I was describing in the paragraph. It wouldn’t work
in interactive mode and it includes everything on the same line of the lambda
definition.
___
Python-ideas
at.
>
> Cheers,
> Marko
>
>
>> On Tue, 25 Sep 2018 at 00:35, James Lu wrote:
>> You could disassemble (import dis) the lambda to biew the names of the
>> lambdas.
>>
>> @before(lambda self, key, _, length, get: self.length(), self.get(key)
There is macropy (https://github.com/lihaoyi/macropy) which was suggested on
> the other thread
> (https://groups.google.com/forum/#!topic/python-ideas/dmXz_7LH4GI) that I'm
> currently looking at.
>
> Cheers,
> Marko
>
>
>> On Tue, 25 Sep 2018 at 00:35, James Lu
> Which features of the TC39 committee's ECMAscript (ES) language governance
> model would be helpful to incorporate into the Python language governance
> model?
Having “beta” or “alpha” editions of features, special versions of the
interpreter people can test out to see if they prefer the
Perhaps it’s because fewer Python functions involve transitioning between
states. Web development and statistics don’t involve many state transition.
State transitions are where I think I would find it useful to write contracts
out explicitly.
___
You could disassemble (import dis) the lambda to biew the names of the lambdas.
@before(lambda self, key, _, length, get: self.length(), self.get(key))
Perhaps you could disassemble the function code and look at all operations or
accesses that are done to “old.” and evaluate those expressions
> To my mind, there is one very big reason we should be cautious about
> adopting JS language-design policies, namely, that they have led to a
> very, very poorly designed language. No doubt a good deal of that is
> baggage from early stages in which JS had a poor to nonexistent language
>
> Babel's primary purpose is transpiling to run on older browsers, which isn't
> that much of an issue with Python. It's also complicated a bit by the large
> number of implementations that *must* be developed in sync, again due to
> running in user's browsers.
It’s true that one of Babel’s
JS’ decisions are made by a body known as TC39, a fairly/very small group of JS
implementers.
First, JS has an easy and widely supported way to modify the language for
yourself: Babel. Babel transpires your JS to older JS, which is then run.
You can publish your language modification on the JS
One of the reasons Guido left was the insane volume of emails he had to read on
Python-ideas.
> A tiny bit of discussion is still better than none at all.
> And even if there's no discussion, there's a name attached
> to the message, which makes it more personal and meaningful
> than a "+1"
> It's absence is a big advantage. We're not a social network with
> "likes". We don't need a bunch of argumentless "voting".
Up/ down voting indicates how much consensus we have among the entire
community- an expert might agree with another expert’s arguments but not have
anything else to add,
Were there any productive parts to that conversation?
Sent from my iPhone
> On Sep 20, 2018, at 9:47 AM, Chris Barker wrote:
>
>> On Thu, Sep 20, 2018 at 1:39 PM, James Lu wrote:
>> In a forum, the beautiful is better than ugly issue would be locked. No more
>
> Frankly, I think the bigger issue is all too human -- we get sucked in and
> participate when we really know we shouldn't (or maybe that's just me).
>
That may be why some people misbehave, but we have no way of discouraging that
misbehavior.
> And I'm having a hard time figuring out how
1 - 100 of 126 matches
Mail list logo
