[Python-ideas] Re: Bringing the print statement back

On 10/06/20 1:56 pm, Ricky Teachey wrote: I have a question. Is there a very good reason that the language allows spaces between function names and the parentheses? >>> print           (1,2,3) Python, in common with many other languages, allows whitespace between any pair of lexical tokens.

[Python-ideas] New syntax for dict literals

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. Also some notational bikeshedding. Atsuo Ishimoto writes: > It is sometimes tedious to write a dictionary in

[Python-ideas] Re: [Python-Dev] Making asyncio more thread-friendly

Kyle Stanley writes: > Fundamentally, OS threads and coroutines are two entirely different > models of concurrency; though, we do have interoperability tools in > place and are actively working on making them easier to > utilize. Also, with adequate arguments for specific real-world use >

[Python-ideas] Re: Bringing the print statement back

Gregory P. Smith writes: > I love that the new parser allows us to even explore these > possibilities. We should be very cautious about what syntax > changes we actually adopt. Meter needle wrapped around pin at +1 (twice! :-) BTW: > We aren't Perl, Ruby, Rexx, Lua, Tcl, ... This made me

[Python-ideas] Re: Bringing the print statement back

I think I have almost the same feeling as Naomi and Gregory. After 10+ years of print statement being an error, typing it as one remains my SECOND most common syntax error. My FIRST most common is omitting the colon that introduces blocks... Which we also don't actually need. I've made that

[Python-ideas] Re: PYTHONLOGGING env variable

On Sat, Jun 06, 2020 at 09:31:36PM +0300, Bar Harel wrote: > > > > It's one thing to say that the interpreter takes care of importing > > logging and setting up a basic logger, and that's great, but I still > > have to import logging and call the `logging.info(...)` functions, > > so what does

[Python-ideas] Re: Bringing the print statement back

I have a question. Is there a very good reason that the language allows spaces between function names and the parentheses? >>> print (1,2,3) 1 2 3 Does *anybody* specifically make use of this...? Perhaps I am missing something obvious. Anyway if this were changed so that this kind of

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 9, 2020, 9:33 PM Edwin Zimmerman wrote: > On 6/9/2020 9:21 PM, Jonathan Goble wrote: > > On Tue, Jun 9, 2020, 8:47 PM Edwin Zimmerman > wrote: > >> Wouldn't this break backwards compatibility with everything the whole way >> back to 3.0? I fear a future with where I have to run a

[Python-ideas] Re: Bringing the print statement back

On 6/9/2020 9:21 PM, Jonathan Goble wrote: > On Tue, Jun 9, 2020, 8:47 PM Edwin Zimmerman > wrote: > > Wouldn't this break backwards compatibility with everything the whole way > back to 3.0?  I fear a future with where I have to run a 2to3 type tool on >

[Python-ideas] Re: Bringing the print statement back

Why is this being proposed? I think we would need a very strong reason to consider this, and so far I haven't seen any justification other than "because we can". -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 9, 2020 at 5:49 PM Naomi Ceder wrote: > FWIW... > > As someone who has spent at least the last 5 years trying (unsuccessfully) > to reprogram 15 years of muscle memory of print as a statement, I vote +1 > to print without parens. > > As someone who teaches Python and groans at

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 9, 2020, 8:47 PM Edwin Zimmerman wrote: > Wouldn't this break backwards compatibility with everything the whole way > back to 3.0? I fear a future with where I have to run a 2to3 type tool on > third-party dependencies just to get them to work with my 3.7 code base. > My

[Python-ideas] Re: Bringing the print statement back

FWIW... As someone who has spent at least the last 5 years trying (unsuccessfully) to reprogram 15 years of muscle memory of print as a statement, I vote +1 to print without parens. As someone who teaches Python and groans at explaining exceptions, I'm -0 on print without parens and -1 on other

[Python-ideas] Re: Bringing the print statement back

Wouldn't this break backwards compatibility with everything the whole way back to 3.0?  I fear a future with where I have to run a 2to3 type tool on third-party dependencies just to get them to work with my 3.7 code base. --Edwin On 6/9/2020 8:06 PM, Guido van Rossum wrote: > In Python 3.10 we

[Python-ideas] Re: Bringing the print statement back

If f and g are unary functions, f g 0 is evaluated as f(g(0))? Asking because you didn't mention composition. That is, could we have `print "hello", input "Name:"` instead of `print "hello", input("Name:")`? Overall, I am against this because I like the "explicitness" of using parenthesis for

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 9, 2020 at 8:08 PM Guido van Rossum wrote: > I believe there are some other languages that support a similar grammar > (Ruby? R? Raku?) but I haven't investigated. > Lua has a similar feature: a name (including a dotted name or index[ing], which are identical in Lua) immediately

[Python-ideas] Re: Bringing the print statement back

Hi Guido, Excited about the possibilities of the new PEG parser ! Have there been any consideration to allow this new call syntax to actually quote the expression given as parameter ? Or have a different meaning than a normal call ? In IPython/Jupyter we use the fact that this is not valid

[Python-ideas] Re: Bringing the print statement back

On 06/09/2020 05:06 PM, Guido van Rossum wrote: 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: >>> print 2+2 4 >>> print "hello world" hello world There are downsides too, though.

[Python-ideas] Bringing the print statement back

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

[Python-ideas] Re: [Python-Dev] Making asyncio more thread-friendly

I would like to clarify that asyncio *does* most certainly provide support for programs that use multiple event loops and interact with a number of different threads. So, asyncio can definitely be used outside of a purely "single-process, single-threaded, single-event-loop approach". However, a

[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes

On 09/06/2020 19:04, Vinay Sharma wrote: The main reason why I requested this enhancement was to ensure that multiple processes can read/write a shared memory segment without corrupting that data in it. To ensure the same shared semaphores came to mind. Each shared memory segment, can have a

[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes

> Is it worth broadening out the discussion to other sorts of named objects? > Named Pipes particularly spring to my mind... The main reason why I requested this enhancement was to ensure that multiple processes can read/write a shared memory segment without corrupting that data in it. To

[Python-ideas] Re: Add close method to queue

Accidentally responded off list. On Tue, Jun 9, 2020 at 1:06 PM Андрей wrote: > Thank you for your comment. > > > > This feature is very needed for > https://github.com/mosquito/aio-pika/pull/327. > > > > PS How to send response on this message? I don’t see this message on > *mail.python.org >

[Python-ideas] Re: Add close method to queue

> On 9 Jun 2020, at 13:20, Kazantcev Andrey wrote: > > I have a problem with notifying all current subscribers and new subscribers > about the closure of the queue and the reason. For example, I have a producer > that reads messages from websocket or something else and send this to a >

[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes

On 09/06/2020 17:16, Vinay Sharma wrote: Hi, I posted this here because a core Developer (Tal Einat), asked me to, although I am not sure what is the protocol from here. Does this enhancement request look reasonable ? If yes, I would love to open a PR. If not, any suggestions, feedback is

[Python-ideas] Re: Shared Semaphores for synchronisation across unrelated processes

Hi, I posted this here because a core Developer (Tal Einat), asked me to, although I am not sure what is the protocol from here. Does this enhancement request look reasonable ? If yes, I would love to open a PR. If not, any suggestions, feedback is very welcome. > On 06-Jun-2020, at 9:56 AM,

[Python-ideas] Re: New syntax for dict literals

Hi there! This request is a close cousin of the recent discussion about optional keywords arguments, which you can find in the archives at https://mail.python.org/archives/list/python-ideas@python.org/thread/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/ A lot of the same comments for and against apply

[Python-ideas] New syntax for dict literals

Hello, It is sometimes tedious to write a dictionary in Python. For example, def register_user(first, last, addr1, addr2): d = {'first': first, 'last': last, 'addr1': addr1, 'addr2': addr2, 'tel': '123-456-789'}

[Python-ideas] Add close method to queue

I have a problem with notifying all current subscribers and new subscribers about the closure of the queue and the reason. For example, I have a producer that reads messages from websocket or something else and send this to a queue, and several consumers (I do not know how many). If any

[Python-ideas] Re: [Python-Dev] Making asyncio more thread-friendly

Fortunately, Guido has jumped in. He's the authority on asyncio. I recommend you consider his advice very carefully. Here are a couple more commments that I had already written when I saw his post. Celelibi writes: > But that doesn't mean we can't try to design asyncio to be more >