[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE
Hello, Maybe I didn't explain it correctly. What I meant was to do exactly the same that happened with <>/!=. That is, add nobreak in Py3 (allowing the use of both else/nobreak) and only deprecate else in Py4. João Matos On 22/07/2020 22:22, Chris Angelico wrote: On Thu, Jul 23, 2020 at 7:06 AM João Matos wrote: Hello, Why not just use Raymond's suggestion nobreak as a replacement of the else in loops and deprecate the else in Python 4? There is at least a precedent when not equal <> was deprecated in favor of != from Py2 to Py3. We could do the same with else/nobreak between Py3 and Py4. Py2 supported both <> and !=, so code could be completely compatible with both branches just by using !=. You're proposing creating a new way of doing things and then deprecating or removing one of them, which either means there'll be two identical spellings, or you break everyone's code (or both). It's almost the opposite of the <> change. Please, everyone, can we NOT keep coming up with ideas that are basically "let's invent a new spelling for exactly the same thing, with no benefits, and demanding new keywords, so we can break people's code for no reason"? You can always just write your own transpiler to let yourself spell it your preferred way. ChrisA ___ 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/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GSBEBZCVW6DVSS7QW2GBDEZWQ6QYEGKJ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZFEZ2CKFJ67OVNDDPWLKNWZRZESXCPN3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE
Hello,
Why not just use Raymond's suggestion nobreak as a replacement of the
else in loops and deprecate the else in Python 4?
There is at least a precedent when not equal <> was deprecated in favor
of != from Py2 to Py3.
We could do the same with else/nobreak between Py3 and Py4.
João Matos
On 22/07/2020 14:36, Mathew Elman wrote:
On Wed, 22 Jul 2020 at 13:45, Paul Moore <mailto:p.f.mo...@gmail.com>> wrote:
On Wed, 22 Jul 2020 at 13:18, Mathew Elman mailto:mathew.el...@ocado.com>> wrote:
>> Ones that retain else on loops are bad because
>> they end up providing two (typically equally confusing) ways of
doing
>> things.
>
> I don't think this is the case. I agree that adding an
alternative to `else` just to have an alternative is not a good
fix, but adding explicit ways to refer to when breaking from the
loop would make the use of `else` as it already is clearer.
>
> For example, breaking the change into 2 parts:
> 1. Adding `elif` to the `for...else` and `while...else`
statements seems a logical extension. Guido has even said that the
else in loops was invented by reasoning the connection of `if` to
`while` (and then `while` to `for`). Perhaps this should be in its
own discussion so as not to clutter this thread?
IMO, allowing
for ...
elif x == 2:
do something
to mean "if we didn't break out of the loop, and x is 2" would be
really confusing.
I don't think this would be any more confusing than `for...else`
already is, and `while...elif...else` still seems like a logical
extension of `while...else`.
x=0
while x < 10:
delta = get_delta(x)
if delta == 0:
break
x += delta
elif x%2:
print(f"{x} is odd and > 10")
else:
print(f"{x} is even and > 10")
And to have the elif after a loop be limited to a
different set of conditions than "ordinary" elif would *also* be
really confusing.
Absolutely! I would not suggest limiting it to any special cases.
Hence why I split up the change. Adding a way to /also/ use the elif
to check the state of the loop is a separate discussion. Be that by
using `break` as a special boolean or some other way.
> 2. Adding a way to use this new `elif` to check the state of the
loop. Possibly including if it was broken out of or if it was
never entered. Such as having special local variables that are
only defined in the block/frame of the loop.
Same logic here - if we allow "elif not break" (for example), it would
be really confusing to *arbitrarily* only allow that if the elif is
attached to a loop. So we need to define what
if x == 2:
do something
elif not break:
what?
means in general code. And that means inventing rules for the scope of
"break as an expression".
And in a similar vein, what does it mean to
pass "break" to a function?
def invert(flag):
return not flag
for
...
elif invert(break):
...
That is fair enough, like I have said I am not attached (though others
may be) to the idea of using `break` as a special boolean. Would it be
more feasible to have a variable that persists beyond the scope of the
loop and is not `break` but something else? For example, and this is
not 100% serious but something like : `iter.broken`, `iter.enetered` etc.
It's not that any of these things are *reasonable* to do, it's that
all the special cases needed to disallow them would be confusing, and
if we *didn't* disallow them, all of the rules needed to give them
meaning in (conceded) unreasonable places would be confusing.
The trick here is *not* to look at the case that you expect the
construct to be used in - obviously it'll look good to you in that
context, if you like the idea at all. What you need to look at is all
the other ways it could be applied, and verify that the costs justify
the improvement that you saw when you first encountered the idea.
Good point, I think this is a well made argument for *not* making
`break` have a second meaning.
Notice:
This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this
message may not necessarily reflect the opinions and views of the
members of the Ocado Group.
If you are not the intended recipient, please notify us immediately
and delete all copies of this message. Please note that it is your
responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in
England and Wales with number 7098618) and its subsidiary undertakings
(as that expression is defined in the Companies Act 2006) fr
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
Hello, Can't you use eval()? This return eval(expr) instead of return expr.evaluate() Best regards, João Matos On 23/02/2020 23:04, Brendan Barnwell wrote: On 2020-02-23 14:38, Steven D'Aprano wrote: Hi Aaron, and welcome! Your proposal would be a lot more interesting to me if I knew what this binary ~ would actually do, without having to go learn R or LaTeX. You say: I think it would be awesome to have in the language, as it would allow modelling along the lines of R that we currently only get with text, e.g.: smf.ols(formula='Lottery ~ Literacy + Wealth + Region', data=df) With a binary context for ~, we could write the above string as pure Python I'm confused. Why can't you just write 'Lottery ~ Literacy + Wealth + Region' as a literal string? That's an exact copy and paste from your example, and it works for me. I'm not the OP but. . . In R there is a tilde operator that is used to indicate "depends on" when separating the dependent and independent variables in a statistical model formulation. The example given is how it has to be done in Python. In R you just write `Lottery ~ Literacy + Wealth + Region` (i.e., as code with no quotes). That said, the way this works in R depends on additional "features" of R whose absence in Python make it a heavier lift than just adding a tilde. R can magically defer evaluation of names so that you can write something like that tilde expression and pass an additional argument specifying the table whose columns are the given variables (i.e., a table with columns for Lottery, Literacy, etc.), and then it will later evaluate the names by looking them up as columns. This won't work in Python because even if you had the tilde, you couldn't do this: ols(Lottery ~ Literacy + Wealth + Region, data=df) Because that model expression is a function argument, Python semantics require it to be evaluated before the call is made, so you can't defer evaluation and later use the names as column names to look up in the provided table. In order to make it work you'd need something else that I've sometimes wished for, which is a smooth way to create and pass around unevaluated expressions, and then later trigger their evaluation in the context of a given namespace (such as the one where the evaluation is triggered). Right now the only approximation to this is lambda, but lambda closes over variables based on the lexical context where it's defined, not where it's called, so it doesn't really work. In other words, what I'd like is the ability to do something like this: def foo(): expr = deferred(a + b + c) bar(expr) def bar(x): a, b, c = 1, 2, 3 # this should return 6 return expr.evaluate() If such functionality existed, then a tilde operator could indeed be used to create model definitions using deferred evaluations like in R. However, I think deferred evaluation is the more important functionality here. If we had deferred evaluation without the tilde, we could still do what R does by using a different operator instead of tilde, at worst perhaps having to parenthesize the dependent-variable expression (in case our alternative "depends" operator had the wrong precedence). But without deferred evaluation, the tilde operator gains little, at least in terms of providing model-evaluation expressions like those in R. ___ 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/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UFTA3RK7O27VZM3XJZJJJMCUDVQSEFXI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SQL string prefix idea
Hello, Just a quick correction, in case a begginer sees this thread. You can use raw strings for Windows paths, except when they end with a backslash. This works: path = r'somewhere\some\folder' filepath = r'somewhere\some\folder\file.txt' This also works: from os import sep path = r'somewhere\some\folder' + sep This doesn't work: path = r'somewhere\some\folder\' Best regards, João Matos On 22/02/2020 06:26, Steven D'Aprano wrote: On Fri, Feb 21, 2020 at 10:19:37PM -0500, David Mertz wrote: On Fri, Feb 21, 2020 at 9:26 PM Steven D'Aprano wrote: And what's so special about SQL over, say, regular expressions, XML, JSON, YAML, Markdown, ReST, LaTeX, etc? I might want to use the s'' prefix for embedded Scheme code rather than SQL. Um, regular expressions are not precisely the best example there, since we do have raw strings specifically for regular expressions. I mentioned them also in my similar list, but deliberately. *Raw strings* are not per-se for regexen, even if that is one of the more common uses. Actually, in Python, regexes are the primary reason raw strings were added! Raw strings aren't quite fully raw, which is why you can't use raw strings for Windows paths: path = r'somewhere\some\folder\' doesn't work. The reason is that "raw" (semi-cooked?) strings are intended for regexes, not as a general mechanism for disabling string escape codes, and regexes aren't allow to end with a bare backslash. https://docs.python.org/3/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash ___ 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/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/73OWKYN65MXVQO7OFNEENRHXJGVSFRTS/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] contains_any_in and contains_all_in
The objective of the proposal is to increase readability.
IMO using re is even more unreadable than the and/or or any/all I mentioned.
quarta-feira, 24 de Abril de 2019 às 05:47:04 UTC+1, Robert Vanden Eynde
escreveu:
>
> Trivial with re module, which will answer thequestion in one pass.
>>
>
> re.search('|'.join(map(re.escape, ['string1', 'string2', 'string3'])),
> master_string)
>
> For those who might find it non trivial.
>
___
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] contains_any_in and contains_all_in
The objective of the proposal is to increase readability.
IMO your options are even more unreadable than the and/or or any/all I
mentioned.
quarta-feira, 24 de Abril de 2019 às 05:33:12 UTC+1, Terry Reedy escreveu:
>
> On 4/23/2019 4:39 PM, João Matos wrote:
> > Hello,
> >
> > If we want to check if a string contains any/all of several other
> > strings we have to use several or/and conditions or any/all.
> >
> > For any:
> > |if ('string1' in master_string or 'string2' in master_string
> > or 'string3' in master_string):
> > or
> > ifany(item inmaster_string foritem in['string1','string2','string3']):
>
> Trivial with re module, which will answer the question in one pass.
>
>
> > For all:
> > |
> > ||if ('string1' in master_string and 'string2' in master_string
> > and'string3' in master_string):
> > or
> > ||ifall(item inmaster_string foritem in['string1','string2','string3']):
>
> Tougher.
> Are the strings guaranteed to not be prefixes of each other?
> Do you want to allow overlaps?
> Can do in one pass by compiling a new re every time an item is found.
> If overlaps not wanted, re.iterfind will find all occurrence of any, so
> feed to set and see if all found.
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-ideas mailing list
> python...@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>___
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] contains_any_in and contains_all_in
Hello,
If we want to check if a string contains any/all of several other strings
we have to use several or/and conditions or any/all.
For any:
if ('string1' in master_string or 'string2' in master_string
or 'string3' in master_string):
or
if any(item in master_string for item in ['string1', 'string2', 'string3']):
For all:
if ('string1' in master_string and 'string2' in master_string
and'string3' in master_string):
or
if all(item in master_string for item in ['string1', 'string2', 'string3']):
I suggest adding some "sugar" to make it more readable by adding
contains_any_in and contains_all_in to look like this
For any:
if master_string contains_any_in ['string1', 'string2', 'string3']:
For all:
if master_string contains_all_in ['string1', 'string2', 'string3]:
What do you think?
Thanks,
JM
___
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] PEP: Dict addition and subtraction
Hello,
I've just read your PEP 585 draft and have some questions.
When you say
"
Like the merge operator and list concatenation, the difference
operator requires both operands to be dicts, while the augmented
version allows any iterable of keys.
>>> d - {'spam', 'parrot'}
Traceback (most recent call last):
...
TypeError: cannot take the difference of dict and set
>>> d -= {'spam', 'parrot'}
>>> print(d)
{'eggs': 2, 'cheese': 'cheddar'}
>>> d -= [('spam', 999)]
>>> print(d)
{'spam': 999, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}
"
The option d -= {'spam', 'parrot'} where parrot does not exist in
the d dict, will raise an exception (eg. KeyNotFound) or be silent?
The option d -= [('spam', 999)] should remove the pair from the
dict, correct? But the print that follows still shows it there. It's
a mistake or am I missing something?
Best regards,
João Matos
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Dict joining using + and +=
Hello,
Great.
Because I don't program in any other language except Python, I can't
make the PR (with the C code).
Maybe someone who program in C can help?
Best regards,
João Matos
On 27-02-2019 18:48, Guido van Rossum
wrote:
On Wed, Feb 27, 2019 at
10:42 AM Michael Selik <m...@selik.org> wrote:
On Wed, Feb 27, 2019
at 10:22 AM Anders Hovmöller <bo...@killingar.net>
wrote:
I dislike the
asymmetry with sets:
> {1} | {2}
{1, 2}
To me it makes sense that if + works for dict then
it should for set too.
/ Anders
> On 27 Feb 2019, at 17:25, João Matos <jcrma...@gmail.com>
wrote:
>
> Hello,
>
> I would like to propose that instead of using
this (applies to Py3.5 and upwards)
> dict_a = {**dict_a, **dict_b}
>
> we could use
> dict_a = dict_a + dict_b
The dict subclass collections.Counter overrides the
update method for adding values instead of overwriting
values.
https://docs.python.org/3/library/collections.html#collections.Counter.update
Counter also uses +/__add__ for
a similar behavior.
>>> c = Counter(a=3, b=1)
>>> d = Counter(a=1, b=2)
>>> c + d # add two counters
together: c[x] + d[x]
Counter({'a': 4, 'b': 3})
At first I worried that changing base dict would
cause confusion for the subclass, but Counter seems
to share the idea that update and + are synonyms.
Great, this sounds like a good argument for + over |. The
other argument is that | for sets *is* symmetrical, while +
is used for other collections where it's not symmetrical. So
it sounds like + is a winner here.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Dict joining using + and +=
Hello,
I would like to propose that instead of using this (applies to Py3.5
and upwards)
dict_a = {**dict_a, **dict_b}
we could use
dict_a = dict_a + dict_b
or even better
dict_a += dict_b
Best regards,
João Matos
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Option of running shell/console commands inside the REPL
Hello, Consider adding the option of running shell/console commands inside the REPL. Something like !dir Best regards, João Matos smime.p7s Description: S/MIME Cryptographic Signature ___ 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] It would be great if the json module would allow and clear existing comments.
Hello, Comments in JSON files are a great way to document a configuration file for example. Even JSON's Douglas Crockford agrees that it is a helpful thing and it suggests using JSMin before handing it to the JSON parser in here https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr So, I would like to suggest adding that feature do the json module. A simple boolean argument, clear_comments, with the default False to keep previous compatibility. With the clear_comments=True and following JSMin "rules", comments in the // form should be replaced with linefeeds and comments in the /* */ form with spaces. Best regards, JM ___ 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] Give nonlocal the same creating power as global
Hello,
You're correct. The idea is to give nonlocal the same ability, redirect
subsequent bindings if the variable doesn't exist.
No, what I said is that it would only create the var if it didn't exist.
That means that the current behaviour of nonlocal to check all previous
envs (except global) would be the same.
The variable would only be created if it ididn't exist in all parent envs.
The downside of the global example is that it is "poluting" the globals.
The reason it is inside a function is that it is called from another
module. The main module does some checks and only if the checks are ok
it calls the gui module.
Best regards,
João Matos
On 11-09-2017 16:51, Terry Reedy wrote:
On 9/11/2017 10:03 AM, João Matos wrote:
Hello,
I would like to suggest that nonlocal should be given the same
creating power as global.
If I do global a_var it creates the global a_var if it doesn't exist.
The global declaration does not create anything, but it redirects
subsequent binding.
I think it would be great that nonlocal maintained that power.
This way when I do nonlocal a_var
it would create a_var in the imediate parent environment, if it
didn't exist.
'Creating new variables' was discussed and rejected when nonlocal was
added. That may partly be for technical reasons of not nonlocal is
implemented. But there are also problems of ambiguity. Consider this
currently legal code.
def f(a):
def g(): pass
def h():
nonlocal a
a = 1
You proposal would break all such usages that depend on skipping the
immediate parent environment. 'nonlocal a' effectively means 'find
the closest function scope with local name a' and I strongly doubt we
will change that. If you want 'nonlocal a' to bind in g, explicitly
add a to g's locals, such as with 'a = None'.
Without nonlocal creation powers I have to create global variables or
local variables after master=Tk() (in the following example):
There is nothing wrong with either.
from tkinter import StringVar, Tk
from tkinter.ttk import Label
def start_gui():
def change_label():
_label_sv.set('Bye Bye')
def create_vars():
global _label_sv
_label_sv = StringVar(value='Hello World')
def create_layout():
Label(master, textvariable=_label_sv).grid()
def create_bindings():
master.bind('', lambda _: master.destroy())
master.bind('', lambda _: change_label())
master = Tk()
create_vars()
create_layout()
create_bindings()
master.mainloop()
if __name__ == '__main__':
start_gui()
In the version above, you could simplify by removing start_gui and put
the operative code from 'master = Tk()' on down in the main clause.
This is standard practice for non-OOP tkinter code.
With nonlocal creation powers it would become a start_gui local
variable (no global) but I could have a function to create the vars
instead of having to add them after master=Tk():
from tkinter import StringVar, Tk
from tkinter.ttk import Label
def start_gui():
def change_label():
label_sv.set('Bye Bye')
def create_vars():
nonlocal label_sv
label_sv = StringVar(value='Hello World')
def create_layout():
Label(master, textvariable=label_sv).grid()
def create_bindings():
master.bind('', lambda _: master.destroy())
master.bind('', lambda _: change_label())
master = Tk()
create_vars()
create_layout()
create_bindings()
master.mainloop()
if __name__ == '__main__':
start_gui()
Initializing the outer function local, here adding 'label_sv = None',
is the price of wanting to create a class with functions instead of a
class definition.
I know that I could also do it with OOP, but this way is more concise
(OOP would add more lines and increase the lines length, which I
personally dislike)
This example is very simple, but if you imagine a GUI with several
widgets, then the separation between vars, layout and bindings
becomes useful for code organization.
This is what classes are for. Either use 'class' or explicitly name
the local of the outer function acting as a class.
___
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] Give nonlocal the same creating power as global
Hello,
I would like to suggest that nonlocal should be given the same creating
power as global.
If I do
global a_var
it creates the global a_var if it doesn't exist.
I think it would be great that nonlocal maintained that power.
This way when I do
nonlocal a_var
it would create a_var in the imediate parent environment, if it didn't
exist.
Without nonlocal creation powers I have to create global variables or local
variables after master=Tk() (in the following example):
from tkinter import StringVar, Tk
from tkinter.ttk import Label
def start_gui():
def change_label():
_label_sv.set('Bye Bye')
def create_vars():
global _label_sv
_label_sv = StringVar(value='Hello World')
def create_layout():
Label(master, textvariable=_label_sv).grid()
def create_bindings():
master.bind('', lambda _: master.destroy())
master.bind('', lambda _: change_label())
master = Tk()
create_vars()
create_layout()
create_bindings()
master.mainloop()
if __name__ == '__main__':
start_gui()
With nonlocal creation powers it would become a start_gui local variable
(no global) but I could have a function to create the vars instead of
having to add them after master=Tk():
from tkinter import StringVar, Tk
from tkinter.ttk import Label
def start_gui():
def change_label():
label_sv.set('Bye Bye')
def create_vars():
nonlocal label_sv
label_sv = StringVar(value='Hello World')
def create_layout():
Label(master, textvariable=label_sv).grid()
def create_bindings():
master.bind('', lambda _: master.destroy())
master.bind('', lambda _: change_label())
master = Tk()
create_vars()
create_layout()
create_bindings()
master.mainloop()
if __name__ == '__main__':
start_gui()
I know that I could also do it with OOP, but this way is more concise (OOP
would add more lines and increase the lines length, which I personally
dislike)
This example is very simple, but if you imagine a GUI with several widgets,
then the separation between vars, layout and bindings becomes useful for
code organization.
Best regards,
João Matos
___
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] globals should accept parenteses for extending beyond 1 line
Hello, The subject of this topic is a suggestion about the language and not the programming paradigm/style. Why should I repeat global if I can use the line separation character \ (like I mentioned on my 1st email) or parentheses as I suggested? "global existing_graph, expected_duration # "in_sec" is unnecessary" No it is not unnecessary unless sec is the only unit you use (in this case we have several units of duration and thus it is necessary). Best regards, JM On 23-01-2017 20:24, Chris Angelico wrote: On Tue, Jan 24, 2017 at 6:37 AM, João Matos <jcrma...@gmail.com> wrote: One does not need to have 10 global vars. It may have to do with var name length and the 79 max line length. This is an example from my one of my programs: global existing_graph, expected_duration_in_sec, file_size, \ file_mtime, no_change_counter I think you're already running into serious design concerns here. Why are file_size and file_mtime global? Perhaps a better design would involve a class, where this function would become a method, and those globals become "self.file_size" and "self.file_mtime". Then you can have a single global instance of that class for now, but if ever you need two of them, it's trivially easy. You encapsulate all of this global state into a coherent package. But if you MUST use globals, I would split the lines according to purpose: global existing_graph, expected_duration # "in_sec" is unnecessary global file_size, file_mtime global no_change_counter # also probably needs a new name That way, you're unlikely to run into the 80-char limit. ChrisA ___ 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 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] globals should accept parenteses for extending beyond 1 line
Hello, I understand. Python sources are very large. Any pointers to which file defines the global statement syntax? Best regards, JM On 23-01-2017 19:53, Brett Cannon wrote: Actually multi-line import doesn't work: File ".\Untitled.py", line 1 import (tokenize, ^ SyntaxError: invalid syntax I think you're getting this mixed up with parentheses being allowed in `from ... import (...)` syntax. So unless there is another single-word keyword that allows multi-line arguments using parentheses I don't think there's an inconsistency here. Plus, as Guido pointed out, the current syntax isn't preventing you from doing something you can already do. So if you want to add parentheses support to global, nonlocal, and import, you can propose a patch, but it's not a priority to solve without someone providing a solution since it doesn't open up anything new for something people don't use on a regular basis. On Mon, 23 Jan 2017 at 11:39 João Matos <jcrma...@gmail.com <mailto:jcrma...@gmail.com>> wrote: Hello, You are correct, my mistake. I should have written global and not globals. The purpose of using parentheses on the import statement is not (in my view) for operational efficiency but for appearance/cleaness. The same applies to using it to global. One does not need to have 10 global vars. It may have to do with var name length and the 79 max line length. This is an example from my one of my programs: global existing_graph, expected_duration_in_sec, file_size, \ file_mtime, no_change_counter Anyway, the use of global being rare is of no concern. The point of my suggestion is standardization. My opinion is that a standard language is easier to learn (and teach) than one that has different syntax for the same issue, depending on the statement. In short, if the recommended multi-line use for import is import (a, b, c) instead of import a, b, \ c Then the same should apply to global. Best regards, JM On 23-01-2017 19:25, Terry Reedy wrote: > On 1/23/2017 1:43 PM, João Matos wrote: >> Hello, >> >> I would like to suggest that globals should follow the existing rule >> (followed by the import statement, the if statement and in other places) >> for extending beyond 1 line using parentheses. >> Like this: >> globals (var_1, var_2, >> var_3) >> >> instead of what must be done now, which is: >> globals var_1, var_2 \ >> var_3 > > The declaration keyword is 'global'; 'globals' is the built-in > function. In any case > > global var_1, var_2 > global var_3 > > works fine. There is no connection between the names and, unlike with > import, no operational efficiency is gained by mashing the statements > together. > > This issue should be rare. The global statement is only needed when > one is rebinding global names within a function*. If a function > rebinds 10 different global names, the design should probably be > re-examined. > > * 'global' at class scope seems useless. > > a = 0 > class C: > a = 1 > > has the same effect as > a = 0 > a = 1 > class C: pass > ___ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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] globals should accept parenteses for extending beyond 1 line
Hello, You are correct, my mistake. I should have written global and not globals. The purpose of using parentheses on the import statement is not (in my view) for operational efficiency but for appearance/cleaness. The same applies to using it to global. One does not need to have 10 global vars. It may have to do with var name length and the 79 max line length. This is an example from my one of my programs: global existing_graph, expected_duration_in_sec, file_size, \ file_mtime, no_change_counter Anyway, the use of global being rare is of no concern. The point of my suggestion is standardization. My opinion is that a standard language is easier to learn (and teach) than one that has different syntax for the same issue, depending on the statement. In short, if the recommended multi-line use for import is import (a, b, c) instead of import a, b, \ c Then the same should apply to global. Best regards, JM On 23-01-2017 19:25, Terry Reedy wrote: On 1/23/2017 1:43 PM, João Matos wrote: Hello, I would like to suggest that globals should follow the existing rule (followed by the import statement, the if statement and in other places) for extending beyond 1 line using parentheses. Like this: globals (var_1, var_2, var_3) instead of what must be done now, which is: globals var_1, var_2 \ var_3 The declaration keyword is 'global'; 'globals' is the built-in function. In any case global var_1, var_2 global var_3 works fine. There is no connection between the names and, unlike with import, no operational efficiency is gained by mashing the statements together. This issue should be rare. The global statement is only needed when one is rebinding global names within a function*. If a function rebinds 10 different global names, the design should probably be re-examined. * 'global' at class scope seems useless. a = 0 class C: a = 1 has the same effect as a = 0 a = 1 class C: pass ___ 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] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
Hello, What I propose is not a = +5 (see the space between the = and + sign) but a =+ 5 (no space between the = and + sign, and there is a space between + and 5) Exactly the same notation (only reversed) as the current assignment operators. Best regards, JM On 12-11-2016 20:15, אלעזר wrote: On Sat, Nov 12, 2016 at 10:08 PM João Matos <jcrma...@gmail.com <mailto:jcrma...@gmail.com>> wrote: What I would like to propose is the creation of the reverse: a =+ c is the same as a = c + a a =+5 already means a becomes 5 a =- c is the same as a = c - a a =-5 already means a becomes -5 Elazar ___ 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] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
Hello, I would like to propose some reversed assignment operators. Python already has some assignment operators: a += c is the same as a = a + c a -= c is the same as a = a - c a *= c is the same as a = a * c a /= c is the same as a = a / c a //= c is the same as a = a // c a %= c is the same as a = a % c a **= c is the same as a = a ** c What I would like to propose is the creation of the reverse: a =+ c is the same as a = c + a a =- c is the same as a = c - a a =* c is the same as a = c * a a =/ c is the same as a = c / a a =// c is the same as a = c // a a =% c is the same as a = c % a a =** c is the same as a = c ** a For addition (+= and =+), multiplication (*= and =*) and subtraction (-= and =-) of numbers it would give the same result, but addition (+= and =+) and multiplication (*= and =*) when used with strings return a different result. All the other operations (=/, =%, =** and =//) return a different result. I think it is simple and easy to understand, therefore pythonic. :) Best regards, JM ___ 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] pip enhancements: check for dependent packages before uninstalling and store installation date to allow listing by it
Hello, I believe it would be helpful if pip checked if there are any dependent packages before uninstalling a package. If there were, it should: 1. Warn the user by listing the dependent packages; 2. Require a specific option, eg. --alldeps to uninstall all dependent packages before uninstalling the specified package; 3. Require a specific option, eg. --force to continue with the uninstall w/o uninstalling the dependent packages (which could be dangerous, but it's the current behaviour and may be useful in specific situations). This is similar to what happens with package managers in Linux. This should also work on venvs. By storing the installation date of all packages, it should allow the list command to be ordered by it. Best regards, JM ___ 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] Suggestion: Clear screen command for the REPL
Hello, I tried on Python 2.7.10 and Python 3.5.2 and Ctrl-L doesn't work on both. I tried on 2 PCs with Windows 7 and none of them worked. What is your Windows version? Are you trying on the cmd.exe console or PS? Best regards, JM quinta-feira, 29 de Setembro de 2016 às 08:09:13 UTC+1, Stephan Houben escreveu: > Hi all, > > I just tried with this official Python binary: > Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 > bit (Intel)] on win32 > > and CTRL-L for sure does clear the window. It just doesn't then move the > prompt to the top, so you end up with a bunch of empty lines, followed by > the prompt. > > Stephan > > 2016-09-29 8:50 GMT+02:00 João Matos <jcrm...@gmail.com >: > >> Hello, >> >> Yes, Ctrl-L doesn't clear the screen on Windows. >> Making Ctrl-L clear the screen would be a good solution (no need for a >> clear screen command). >> >> >> Best regards, >> >> JM >> >> quinta-feira, 29 de Setembro de 2016 às 03:06:26 UTC+1, Steven D'Aprano >> escreveu: >> >>> On Tue, Sep 27, 2016 at 10:05:16AM -0700, João Matos wrote: >>> > Hello, >>> > >>> > >>> > It doesn't work in Windows. >>> >>> What is "it"? Are you talking about Ctrl-L to clear the screen? >>> >>> >>> Perhaps we should start by adding Ctrl-L as a standard way to clear the >>> Python REPL, in the same way that Ctrl-C is the standard way to >>> interrupt the interpreter regardless of whether you are using Linux, Mac >>> or Windows. >>> >>> (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows >>> is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?) >>> >>> >>> -- >>> Steve >>> ___ >>> Python-ideas mailing list >>> python...@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> ___ >> Python-ideas mailing list >> python...@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > >___ 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] Suggestion: Clear screen command for the REPL
Hello, Yes, Ctrl-L doesn't clear the screen on Windows. Making Ctrl-L clear the screen would be a good solution (no need for a clear screen command). Best regards, JM quinta-feira, 29 de Setembro de 2016 às 03:06:26 UTC+1, Steven D'Aprano escreveu: > On Tue, Sep 27, 2016 at 10:05:16AM -0700, João Matos wrote: > > Hello, > > > > > > It doesn't work in Windows. > > What is "it"? Are you talking about Ctrl-L to clear the screen? > > > Perhaps we should start by adding Ctrl-L as a standard way to clear the > Python REPL, in the same way that Ctrl-C is the standard way to > interrupt the interpreter regardless of whether you are using Linux, Mac > or Windows. > > (Also, it seems a shame that Ctrl-D is EOF in Linux and Mac, but Windows > is Ctrl-Z + Return. Can that be standardized to Ctrl-D everywhere?) > > > -- > Steve > ___ > Python-ideas mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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] Suggestion: Clear screen command for the REPL
Hello, It doesn't work in Windows. Best regards, JM terça-feira, 27 de Setembro de 2016 às 16:40:42 UTC+1, Dennis Brakhane via Python-ideas escreveu: > I don't know if it works on Windows, but at least in Linux pressing > Ctrl-L will do exactly what you describe (as long as the REPL uses > readline) > > On 17.09.2016 12:51, João Matos wrote: > > Hello, > > > > I would like to suggest adding a clear command (not function) to Python. > > It's simple purpose would be to clear the REPL screen, leaving the >>> > > prompt at the top left of the screen. > > > > This is something very basic but also very useful for newbies learning > > Python from the REPL. > > After some trial and errors it is best to start with a clean screen. > > Clearing the screen helps clear your mind. > > > > Historically it is a common command in interpreted languages. > > > > Best regards, > > > > JM > > > > ___ > > Python-ideas mailing list > > python...@python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > >___ 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] Suggestion: Clear screen command for the REPL
Hello, You are correct. Thanks for the explanation. Best regards, JM terça-feira, 20 de Setembro de 2016 às 02:56:57 UTC+1, Steven D'Aprano escreveu: > On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote: > > Hello, > > > > I don't see why creating a clear command would interfere with > dict.clear() > > which is a function/method. > > For the same reason that you can't have a method called foo.while or > foo.if or foo.raise. If clear is a "command" (a statement) it would need > to be a keyword, like while, if and raise. > > > -- > Steve > ___ > Python-ideas mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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] Suggestion: Clear screen command for the REPL
Hello,
I don't see why creating a clear command would interfere with dict.clear()
which is a function/method.
Although my first idea was a clear command, I have no problem if it is a
clear() function from site.py.
I didn't suggest cls because it is normally used to mean class.
I use Windows and tested a simple (possibly not the best of course)
solution that seems to work in REPL (but not in IDLE).
import os
import sys
def clear():
if sys.platform == 'win32':
os.system('cls')
else:
os.system('clear')
Best regards,
JM
segunda-feira, 19 de Setembro de 2016 às 03:33:45 UTC+1, Steven D'Aprano
escreveu:
> On Sat, Sep 17, 2016 at 11:51:16AM +0100, João Matos wrote:
> > Hello,
> >
> > I would like to suggest adding a clear command (not function) to Python.
>
> While technically "clear" could be a command, I think it should not be.
>
> First off, making clear a reserved keyword, and a statement, like print
> in Python 2, raise or import, would be a major backwards compatibility
> break. It would mean dict.clear() has to be renamed, and it would break
> lots of existing code.
>
> So making clear a keyword is not going to happen.
>
> If could be a pseudo-built-in, like help(), quit() and exit(), added to
> built-ins by the site module. In that case, it is *technically* possible
> to have it operate without the parentheses:
>
> class ClearType:
> def __repr__(self):
> # code to clear the screen here
> ...
>
> clear = ClearType()
>
> so that when you enter clear at the interactive interpreter, __repr__ is
> called and it clears the screen. But I would argue against it. Instead,
> it is better to use the same convention that executable code that has
> side-effects should be implemented as a function call.
>
> So I suggest following the design of exit() and quit():
>
> py> exit
> Use exit() or Ctrl-D (i.e. EOF) to exit
>
>
> class ClearType:
> def __repr__(self):
> return "Use clear() or Ctrl-L (i.e. FF) to clear the screen"
> def __call__(self):
> # clear screen code goes here
>
> clear = ClearType() # or possibly cls ?
>
>
>
> That is, *if* we add this function at all.
>
> Personally, I agree with you. There are many different ways of clearing
> the screen, but they depend on the specific terminal used, whether
> readline is active or not, the operating system, etc. I think that
> interactive use is important enough that we should have a standard way
> of clearing the screen. I personally often find myself just holding down
> the Enter key until I have a blank screen.
>
> In this ticket:
>
> http://bugs.python.org/issue27771
>
> Raymond Hettinger mentions that it is an often-requested feature by
> learners, and I believe that IDLE has an active task for this feature:
>
> http://bugs.python.org/issue6143
>
> but I don't see any tasks for a clear screen command for the default
> REPL.
>
> I'm in favour of adding a clear() *function* to the site.py module,
> similar to exit/quit/help, but not making it "magical" or a keyword that
> doesn't require brackets. But I don't know how to implement it for the
> large variety of terminals and operating systems supported by Python.
>
> (The fallback if all else fails is easy: get the height of the terminal,
> in lines, and print that many blank lines.)
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> python...@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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] (Windows-only - calling Steve Dower) Consider addinga symlink to pip in the same location as the py launcher
Hello, Ok, thanks for the feedback. Best regards, JM domingo, 18 de Setembro de 2016 às 13:52:44 UTC+1, Steve Dower escreveu: > I'd like to add a launcher in the same style as py.exe, but that would > upset people who manually configure their PATH appropriately. > > Personally, I find "py.exe -m pip" quite okay, but appreciate the idea. > I'm thinking about this issue (also for other scripts). > > Top-posted from my Windows Phone > ------ > From: João Matos > Sent: 9/17/2016 3:57 > To: python...@python.org > Subject: [Python-ideas] (Windows-only - calling Steve Dower) Consider > addinga symlink to pip in the same location as the py launcher > > Hello, > > If Py3.5 is installed in user mode instead of admin (all users) and we > follow your advice that we shouldn't add it to the PATH env var, we can > execute Python using the py launcher, but we can't use pip. > Please consider adding a pip symlink in the same location as the py > launcher. > > Best regards, > > JM > > ___ > Python-ideas mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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] (Windows-only - calling Steve Dower) Is Python forWindows using PGO? If not consider this a suggestion.
Hello, Ok, thanks for the feedback. Best regards, JM domingo, 18 de Setembro de 2016 às 13:53:44 UTC+1, Steve Dower escreveu: > > It was disable previously because of compiler bugs. 3.6.0b1 64-bit has PGO > enabled, but we'll disable it again if there are any issues. > > Top-posted from my Windows Phone > -- > From: João Matos > Sent: 9/17/2016 4:02 > To: python...@python.org > Subject: [Python-ideas] (Windows-only - calling Steve Dower) Is Python > forWindows using PGO? If not consider this a suggestion. > > Hello, > > Is Python for Windows using PGO (Profile Guided Optimizations)? If not > consider this a suggestion. > > Best regards, > > JM > > ___ > Python-ideas mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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] Suggestion: Clear screen command for the REPL
Hello,
I searched and found several possible solutions to clear the screen in
the CPython REPL, but all are, in my opinion, complex for a newbie.
The existence of a clear command would be a simple and obvious,
therefore accessible to newbies.
Best regards,
JM
On 17-09-2016 14:34, eryk sun wrote:
On Sat, Sep 17, 2016 at 11:11 AM, João Matos <jcrma...@gmail.com> wrote:
On 17-09-2016 12:07, Oleg Broytman wrote:
Pressing [Ctrl]+[L] works for me.
Doesn't work on Windows.
Windows 10 added VT100 support to the console, so you can create a
little cls() function to clear the screen:
cls = lambda: print('\x1b[1J', end='', flush=True)
VT100 support isn't enabled by default. However, cmd.exe always
enables this mode. So run doskey.exe via os.system to enable VT100
mode while setting a convenient "cls" alias:
import os
os.system(r'doskey /exename=python.exe cls=cls()')
This alias substitutes "cls()" for "cls" at the beginning of a line.
This saves you from having to type "()" all the time. The alias isn't
active for other programs; e.g. if you execute
subprocess.call('powershell'), then "cls" will be the PowerShell alias
for Clear-Host.
You can also use ctypes instead of os.system and doskey.exe:
import ctypes
kernel32 = ctypes.WinDLL('kernel32')
hStdOut = kernel32.GetStdHandle(-11)
# enable VT100 mode
mode = (ctypes.c_uint * 1)()
kernel32.GetConsoleMode(hStdOut, mode)
kernel32.SetConsoleMode(hStdOut, mode[0] | 4)
# define a cls() function and set a console alias
cls = lambda: print('\x1b[1J', end='', flush=True)
kernel32.AddConsoleAliasW('cls', 'cls()', 'python.exe')
For older versions of Windows you can use ANSICON or ConEmu, which use
DLL injection to extend the console API. Python's colorama and
pyreadline modules should also work for this.
___
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 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] Suggestion: Clear screen command for the REPL
Hello, I know about those IPython commands and I searched and found several possible solutions to clear the screen in the CPython REPL, but all are, in my opinion, complex for a newbie. The existence of a clear command would be simple and obvious, therefore accessible to newbies. Best regards, JM On 17-09-2016 14:15, Wes Turner wrote: With IPython, there are a number of ways to reset the terminal display: clear # %clear !cls #windows !reset - http://stackoverflow.com/questions/6892191/clearing-the-screen-in-ipython - Ctrl-L is a readline binding - http://pythonhosted.org/pyreadline/usage.html#pyreadline-with-python-interpreter - https://anaconda.org/anaconda/pyreadline - https://pypi.python.org/pypi/pyreadline - IPython >= 5 no longer uses pyreadline (instead, python prompt toolkit) - https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt_toolkit/shortcuts.py #def clear - http://unix.stackexchange.com/questions/124762/how-does-clear-command-work - http://urwid.org/reference/display_modules.html#urwid.raw_display.Screen.clear - https://rosettacode.org/wiki/Terminal_control/Clear_the_screen#Python On Saturday, September 17, 2016, João Matos <jcrma...@gmail.com <mailto:jcrma...@gmail.com>> wrote: Hello, In other interpreted programming languages the clear screen command (whatever it is) also does not clear the session. It just clears the screen clutter. As I said, this would be very useful for newbies, which don't know anything about usercustomize or sitecustomize. Best regards, JM On 17-09-2016 12:07, Chris Angelico wrote: On Sat, Sep 17, 2016 at 8:51 PM, João Matos <jcrma...@gmail.com> wrote: I would like to suggest adding a clear command (not function) to Python. It's simple purpose would be to clear the REPL screen, leaving the >>> prompt at the top left of the screen. This is something very basic but also very useful for newbies learning Python from the REPL. After some trial and errors it is best to start with a clean screen. Clearing the screen helps clear your mind. I'm not sure that it _is_ helpful, given that you're starting with a clean screen but not restarting the session (so you'll still have all the state from your previous work). If you want a completely fresh start, just exit Python, clear the screen with a shell command, and re-enter. The easiest way to play around with this would be to create a pure Python clear() function in your usercustomize or sitecustomize, and then try it in your own workflow - see whether it annoys you that it doesn't change the interpreter state. Maybe it will, maybe it won't. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
