[Python-ideas] Re: Bringing the print statement back
On 2020-06-11 22:15, Ethan Furman wrote: On 06/11/2020 01:18 PM, Rob Cliffe via Python-ideas wrote: If the new super-duper all-singing-and-dancing-and-make-the-tea parser can cope with 'print' without parens, it can cope with print followed by nothing. Good addition to the proposal, actually. :-) (Repeated for clarity: I'm in favour of the proposition for 'print' only.) If print prints a blank line, how are you going to access the "print" function as an object? Context: it's in a statement, on its own, just the name "print". An academic question at this point as Guido has withdrawn the proposal. ___ 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/FIMRTBATHF2C47YF33MLM2STISE7IYPM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
>
> instead of prefixing a letter, we may be able to omit the key of
> items inside dict display.
d = {:name, :addr, ’tel': '123-4567’}
>
This is my favorite variation on the notation so far. I'll give it a +1
On Wed, Jun 10, 2020 at 10:49 AM Atsuo Ishimoto wrote:
> Hi
> Thank you for comments
>
> 2020年6月10日(水) 12:12 Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp>:
> > DTRTs. How often would locals() be usable in this way? Note: in the
> > case of requests, this might be a vulnerability, because the explicit
> > dict display would presumably include only relevant items, while
> > locals() might inherit private credentials from the arguments, which
> > need to be explicitly del'ed from d.
>
> And in case of locals() is useful, the code may eventually become
> unsafe someday later.
>
> > I understand that this was done for ease of your POC implementatation,
> > and you prefer a letter. But I'd like to emphasize: Please don't use
> > $ for this. Among other things, it is both in appearance and
> > historically based on "S" for "set"!
> >
>
> I don't like it, either. But choice of valid letters are limited to
> such as “$", "'" and "?".
> So I think '$' is the best choice among these letters ;)
>
> > Also, please use dict display syntax (':' not '=').
> >
>
> Ah, this is a typo. I use ':' in my implementation.
>
> > If you're going to use prefix characters, I suggest 'd' for "dict",
> > and maybe 's' for "set" as well (to allow the use case 's{}' for the
> > empty set, though that's not terribly useful vs. set(). I'm mostly
> > proposing it so I be the first to say "-1" on 's{}'. :-)
> >
>
> 'd{}' would be a nice choice.
> >
> > It occurs to me there's an alternative syntax with even less notation:
> >
> > d = {'tel' : '123-456-789', first, last, addr1, addr2}
> >
>
> This is acceptable, but I prefer prefixed dict better.
>
> Or, instead of prefixing a letter, we may be able to omit the key of
> items inside dict display.
>
> d = {:name, :addr, ’tel': '123-4567’}
>
> Thoughts?
> ___
> 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/6Y3NSEBKALWJSB63MWMXRA6KTZ46CMD3/
> 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/RNKJWIYYWFXEWJGBWCI47CY7RVDMY26H/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
I like Atsou's suggestion of omitting the key for literals:
d = {:name, :addr, ’tel': '123-4567’}
but using empty kwargs feels gross:
d = dict(=name, =addr, tel='123-456')
And this feels like it could easily lead to confusion:
d = dict(name, addr, tell='123-456')
On Thu, Jun 11, 2020 at 4:05 PM Abe Dillon wrote:
> Stephen J. Turnbull
>
>> d = {first : first, last, addr1, addr2}
>
>
> I'm not a huge fan of this solution. It feels a bit like a hack instead of
> an intended syntax. Since prefixing characters on strings is already a
> thing, I lean more towards that solution. It's slightly easier to search
> (e.g. if the notation was d{literal1, literal2, etc}, one might search for
> "python d-dict"). However, If the above notation gains favor, perhaps it
> would be better to allow an empty ':' followed by a comma:
>
> d = {:, first, last, addr1, addr2}
>
> I don't much like the Perlyness of that syntax, but it's similar to using
> a prefix and it might lead to more explicit empty literals like {:} and {,}
> for dict and set respectively. I'm pretty sure that notation for empty
> literals has been discussed and rejected before, so I apologize if this
> brings up well-trodden ground. I'm pretty neutral on the proposal in
> general.
>
> It may also be possible to add a constructor to dict like:
>
> d = dict.from_locals('first', 'last', 'addr1', 'addr2')
> d['tel'] = '123-456-789'
>
> It might require a bit of stack inspection or some other magic, but it
> should be possible. It might be difficult for IDEs to recognize and hint
> and it might also be a blind-spot for re-factoring (if you change the name
> of a local variable).
>
> On Wed, Jun 10, 2020 at 3:06 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> Chris Angelico writes:
>> > On Wed, Jun 10, 2020 at 1:15 PM Stephen J. Turnbull
>> > wrote:
>> > >
>> > > Executive summary:
>> > >
>> > > Dicts are unordered, so we can distinguish dict from set by the first
>> > > item (no new notation), and after that default identifiers to (name :
>> > > in-scope value) items.
>> >
>> > Be careful with this assumption. Python's dictionaries DO retain
>> > order,
>>
>> Thank you for the reminder! I did forget that point.
>>
>> > even if you can't easily talk about "the fifth element" [1], so
>> > anything that imposes requirements on the entry listed
>> > syntactically first may have consequences.
>>
>> No requirements imposed! If iteration order matters and you want to
>> take advantage of abbreviation, you might have to write
>>
>> d = {first : first, last, addr1, addr2, tel='123-456-789'}
>>
>> but frequently it would just work naturally:
>>
>> d = {first : first, last, addr1, addr2}
>>
>> Admittedly this distinction may be even more subtle than grit on Tim's
>> screen, or randomizing the hash seed per process. And I suspect that
>> people who want this feature will prefer the d{} notation for
>> consistency inside the braces.
>>
>> Steve
>> ___
>> 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/ENXYVRXOAEOBWHN6SQK5K4IJUTRHHXLB/
>> 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/F2DDRMDOQOMCWATOV2CN3AZTYT3FPVTA/
> 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/TF3R55FVQJFNRXJLTQGLRXC5LPBNQQ42/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
On 06/11/2020 01:18 PM, Rob Cliffe via Python-ideas wrote: If the new super-duper all-singing-and-dancing-and-make-the-tea parser can cope with 'print' without parens, it can cope with print followed by nothing. Good addition to the proposal, actually. :-) (Repeated for clarity: I'm in favour of the proposition for 'print' only.) If print prints a blank line, how are you going to access the "print" function as an object? An academic question at this point as Guido has withdrawn the proposal. -- ~Ethan~ ___ 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/JB6ESKJMEEA4VC5Y4FOCOC4LHMRH4VG2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
On 11/06/2020 16:45, Steven D'Aprano wrote: On Wed, Jun 10, 2020 at 08:00:26PM -0400, Jonathan Crall wrote: I wouldn't mind if this *only *worked for the specific characters "print". I would. What's so special about print? It's just a function. I use `iter` much more than print. Should we make a special exception for only 'iter' too? Or instead? `print` is especially problematic, because zero-argument form of print is possible. This makes it a landmine waiting for the unwary: print x, y, z # works print x # works # now print a blank line print # silent failure That's especially going to burn people who remember Python 2, where it did print a blank line instead of evaluating to the `print` object. No problem! If the new super-duper all-singing-and-dancing-and-make-the-tea parser can cope with 'print' without parens, it can cope with print followed by nothing. Good addition to the proposal, actually. :-) (Repeated for clarity: I'm in favour of the proposition for 'print' only.) ___ 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/LRGW2REB6TIOA36N4OJQS67O7XRQAKGW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
Stephen J. Turnbull
> d = {first : first, last, addr1, addr2}
I'm not a huge fan of this solution. It feels a bit like a hack instead of
an intended syntax. Since prefixing characters on strings is already a
thing, I lean more towards that solution. It's slightly easier to search
(e.g. if the notation was d{literal1, literal2, etc}, one might search for
"python d-dict"). However, If the above notation gains favor, perhaps it
would be better to allow an empty ':' followed by a comma:
d = {:, first, last, addr1, addr2}
I don't much like the Perlyness of that syntax, but it's similar to using a
prefix and it might lead to more explicit empty literals like {:} and {,}
for dict and set respectively. I'm pretty sure that notation for empty
literals has been discussed and rejected before, so I apologize if this
brings up well-trodden ground. I'm pretty neutral on the proposal in
general.
It may also be possible to add a constructor to dict like:
d = dict.from_locals('first', 'last', 'addr1', 'addr2')
d['tel'] = '123-456-789'
It might require a bit of stack inspection or some other magic, but it
should be possible. It might be difficult for IDEs to recognize and hint
and it might also be a blind-spot for re-factoring (if you change the name
of a local variable).
On Wed, Jun 10, 2020 at 3:06 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Chris Angelico writes:
> > On Wed, Jun 10, 2020 at 1:15 PM Stephen J. Turnbull
> > wrote:
> > >
> > > Executive summary:
> > >
> > > Dicts are unordered, so we can distinguish dict from set by the first
> > > item (no new notation), and after that default identifiers to (name :
> > > in-scope value) items.
> >
> > Be careful with this assumption. Python's dictionaries DO retain
> > order,
>
> Thank you for the reminder! I did forget that point.
>
> > even if you can't easily talk about "the fifth element" [1], so
> > anything that imposes requirements on the entry listed
> > syntactically first may have consequences.
>
> No requirements imposed! If iteration order matters and you want to
> take advantage of abbreviation, you might have to write
>
> d = {first : first, last, addr1, addr2, tel='123-456-789'}
>
> but frequently it would just work naturally:
>
> d = {first : first, last, addr1, addr2}
>
> Admittedly this distinction may be even more subtle than grit on Tim's
> screen, or randomizing the hash seed per process. And I suspect that
> people who want this feature will prefer the d{} notation for
> consistency inside the braces.
>
> Steve
> ___
> 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/ENXYVRXOAEOBWHN6SQK5K4IJUTRHHXLB/
> 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/F2DDRMDOQOMCWATOV2CN3AZTYT3FPVTA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
> What's so special about print? It's just a function. I'd argue it's a pretty special function given its history. Just because it's used less frequently that something else doesn't mean it's not "special" in some sense. `iter x` never worked, whereas `print x` used to work, which is the only reason I'm giving it special status. Regardless, I'd rather not have this feature. As you said it's not 100% backwards compatible, so the usefulness is limited. On Thu, Jun 11, 2020 at 11:49 AM Steven D'Aprano wrote: > On Wed, Jun 10, 2020 at 08:00:26PM -0400, Jonathan Crall wrote: > > I wouldn't mind if this *only *worked for the specific characters > "print". > > I would. What's so special about print? It's just a function. > > I use `iter` much more than print. Should we make a special exception > for only 'iter' too? Or instead? > > `print` is especially problematic, because zero-argument form of print > is possible. This makes it a landmine waiting for the unwary: > > print x, y, z # works > print x # works > # now print a blank line > print # silent failure > > > That's especially going to burn people who remember Python 2, where it > did print a blank line instead of evaluating to the `print` object. > > -- > Steven > ___ > 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/ICVRZKRAPKRCNY7BTMQY7GRYV37ADQRA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- -Dr. Jon Crall (him) ___ 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/4QNJB2JDVS7F2MMPYYV4HJXMG62GTIEJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
On Tue, Jun 9, 2020 at 8:11 PM Guido van Rossum wrote:
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
> prototype:
>
> Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> >>> print 2+2
> 4
> >>> print "hello world"
> hello world
> >>> print "hello", input("Name:")
> Name:Guido
> hello Guido
> >>> print 1, 2, 3, sep=", "
> 1, 2, 3
> >>>
>
> But wait, there's more! The same syntax will make it possible to call
> *any* function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>
> Really, *any* method:
>
> >>> class C:
> ... def foo(self, arg): print arg
> ...
> >>> C().foo 2+2
> 4
> >>>
>
> There are downsides too, though. For example, you can't call a method
> without arguments:
>
> >>> print
>
> >>>
>
> Worse, the first argument cannot start with a parenthesis or bracket:
>
> >>> print (1, 2, 3)
> 1 2 3
> >>> C().foo (1, 2, 3)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: C.foo() takes 2 positional arguments but 4 were given
> >>> print (2+2), 42
> 4
> (None, 42)
> >>> C().foo [0]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'method' object is not subscriptable
> >>>
>
> No, it's not April 1st. I am seriously proposing this (but I'll withdraw
> it if the response is a resounding "boo, hiss"). After all, we currently
> have a bunch of complexity in the parser just to give a helpful error
> message to people used to Python 2's print statement:
>
Boo! Hiss!
> >>> print 1, 2, 3
> File "", line 1
> print 1, 2, 3
> ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1,
> 2, 3)?
> >>>
>
> And IIRC there have been a number of aborted attempts at syntactic hacks
> to allow people to call functions (like print) without parentheses,
> although (I think) none of them made it into a PEP. The PEG parser makes
> this much simpler, because it can simply backtrack -- by placing the
> grammar rule for this syntax (tentatively called "call statement") last in
> the list of alternatives for "small statement" we ensure that everything
> that's a valid expression statement (including print() calls) is still an
> expression statement with exactly the same meaning, while still allowing
> parameter-less function calls, without lexical hacks. (There is no code in
> my prototype that checks for a space after 'print' -- it just checks that
> there's a name, number or string following a name, which is never legal
> syntax.)
>
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype
> does not support things like this:
>
> >>> a = (len "abc")
> File "", line 1
> a = (len "abc")
> ^
> SyntaxError: invalid syntax
> >>>
>
> I think that strikes a reasonable balance between usability and reduced
> detection of common errors.
>
> I could also dial it back a bit, e.g. maybe it's too much to allow
> 'C().foo x' and we should only allow dotted names (sufficient to access
> functions in imported modules and method calls on variables). Or maybe we
> should only allow simple names (allowing 'len x' but disallowing
> 'sys.getrefcount x'. Or maybe we should really only bring back print
> statements.
>
> I believe there are some other languages that support a similar grammar
> (Ruby? R? Raku?) but I haven't investigated.
>
> Thoughts?
>
I think its really interesting to see how flexible the new parser can be.
Regardless of any actual merits, this is a really cool demonstration of
that.
However, I have a few immediate negatives to draw from this as an actual
proposal.
First, ambiguity is a factor that Python has always done a really great job
of avoiding for the sake of its users. I think this kind of implied call
syntax is absolutely the kind of ambiguity that makes a language hard to
debug, hard to read, and hard to learn.
Second, I don't think we should discount a certain marketing aspect to a
change like this. Like it or not, Python 3's changes were contentious for a
lot of users. It took way longer than some of us thought to drag the
community into the modern incarnation of the language, and there isn't only
a small portion of the community that might still be a little bitter about
it. Or, who still have to deal with the split between 2 and 3 even today,
EOL be damned.
What message do we send if we undo one of the most visible changes *now*?
We'd send a message that it was all a mistake, and because of the
visibility of such a quintessential line of
[Python-ideas] Re: Bringing the print statement back
On Wed, Jun 10, 2020 at 08:00:26PM -0400, Jonathan Crall wrote: > I wouldn't mind if this *only *worked for the specific characters "print". I would. What's so special about print? It's just a function. I use `iter` much more than print. Should we make a special exception for only 'iter' too? Or instead? `print` is especially problematic, because zero-argument form of print is possible. This makes it a landmine waiting for the unwary: print x, y, z # works print x # works # now print a blank line print # silent failure That's especially going to burn people who remember Python 2, where it did print a blank line instead of evaluating to the `print` object. -- Steven ___ 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/ICVRZKRAPKRCNY7BTMQY7GRYV37ADQRA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: New syntax for dict literals
I find this interesting, another solution would be for locals() to take
arguments:
dict(tel='1337-1337', **locals('name', 'surname'))
___
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/SCUS4D53C43EPFS4ZNUT75O2TNI3BFRZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
Of course ipython has a %autocall magic which, if set to 1: Lets you type `print 42, 43, 46, sep='-'` and have it work. Shows you the actual call so you can paste it If you use the %save magic to output to a file saves the actual call, (with parenthesis). You can set this as your preference. There are other benefits as well. So I would suggest simply pip install ipython and type one extra letter when starting your python REPL. Steve Barnes -Original Message- From: Greg Ewing Sent: 11 June 2020 07:51 To: python-ideas@python.org Subject: [Python-ideas] Re: Bringing the print statement back I seem to remember reading somewhere that some very early Lisp systems had a REPL that allowed you to omit the parentheses around a top-level call. But that feature seems to have sunk without trace in the swamps of history. I can't see a good reason for Python to refloat it. -- Greg ___ 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/T7OJHUDIPSF7M4OKBPP7DUQQD62BCXY7/ 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/IFL6M7X7V3RIWCRKIKJOJLKMYGTQCOLK/ Code of Conduct: http://python.org/psf/codeofconduct/
