Re: [Python-Dev] Modifying Grammar/grammar and other foul acts
On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind wrote:
> Python-devs,
>
> I'm writing to you for some help in understanding the Python grammar. As an
> excuse to deep dive into Python's tokenizer / grammar, I decided (as a
> hideous, hideous joke) to want to allow braces where colons are allowed (as
> flow control).
>
> Starting from PEP 306 (and branch r311), I hacked on Grammar/Grammer
>
> As a first example:
>
> funcdef: ('def' NAME parameters ['->' test] ':' suite |
> 'def' NAME parameters ['->' test] '{' suite '}' )
>
> I reran Parser/pgen and the dfa changes, but python (3.1) when recompiled,
> throws errors on things like:
>
> def a() { None }
>
> Strangely enough:
>
> lambdef: ( 'lambda' [varargslist] ':' test |
> 'lambda' [varargslist] '{' test '}' )
>
> works fine! I this simplely some difference between "test" and "suite".
>
> I have tried tackling this with gdb, looking at err_input clearly isn't
> enough.
>
> (gdb) break err_input
> (gdb) break PyParser_ASTFromString
> import sys
> b = compile("def a() {pass}","sys.stdout","single")
> # yet a simple grammar fix is enough for this!
> c = compile("lambda x {None}","sys.stdout","single")
>
> I'm in over my head!
You don't say what errors occur when you try to compile strings in
your new language. You may have changed the Grammar, which allows you
to tokenize the input. That isn't enough to get the input to compile.
You also need to change the compiler to understand the new tokens.
Jeremy
> Any insights / help would be appreciated. Full-on flaming is also
> appropriate, but would be less appreciated.
>
> Specific questions
>
> 1.) I assume the Grammar/grammar is read top to bottom. Confirm?
> 2.) More help figuring out how to debug what python *thinks* it's seeing
> when it see "def a() {pass}". It's not getting to the ast construction
> stage, as near as I can tell. What additional breakpoints can I set to see
> where it's failing.
>
> Gregg L.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.6.5 rc 2
Hi Python hackateers! It looks like we finally have no more release blockers for 2.6.5rc2. I would like to tag the tree tonight for rc2 so that Martin can build the Windows installer for a release tomorrow. I am also moving the final release back to Friday March 19. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building thread-safe sqlite3 with Python 2.6.5rc1
That worked great Oleg! Thank you! On Tue, 2010-03-09 at 01:52 +0300, Oleg Broytman wrote: > On Mon, Mar 08, 2010 at 05:28:10PM -0500, Darren Govoni wrote: > > ProgrammingError: SQLite objects created in a thread can only be used in > > that same thread.The object was created in thread id -1217128768 and > > this is thread id -1218753680 > >Darren, try to pass check_same_thread=False when creating a connection. > > Oleg. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FWD: http://www.python.org/dev/patches/
- Forwarded message from Bob Vadnais - > Date: Tue, 09 Mar 2010 00:37:33 -0500 > From: Bob Vadnais > To: [email protected] > Subject: http://www.python.org/dev/patches/ > > > Submit documentation patches the same way. When adding the patch, be > > sure to set the "Category" field to "Documentation". > > There doesn't appear to be a field named "Category". Perhaps there used > to be? The correct field name now appears to be "Components". - End forwarded message - -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important." --Henry Spencer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
Le Mon, 08 Mar 2010 21:11:45 -, [email protected] a écrit : > > Getting rid of the process-global state like this simplifies testing > (both testing of the executors themselves and of application code > which uses them). It also eliminates the unpleasant interpreter > shutdown/module globals interactions that have plagued a number of > stdlib systems that keep global state. +1. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On 3/8/2010 4:39 PM, Greg Ewing wrote: Terry Reedy wrote: Looking more close, I gather that the prime results will be printed 'in order' (waiting on each even if others are done) while the url results will be printed 'as available'. Seems to me that if you care about the order of the results, you should be able to just wait for each result separately in the order you want them. Something like task1 = start_task(proc1) task2 = start_task(proc2) task3 = start_task(proc3) result1 = task1.wait_for_result() result2 = task2.wait_for_result() result3 = task3.wait_for_result() *If* I understand the first example correctly, this is effectively what the first example does with two loops. But I was hoping for clarification and amplification in the PEP. This would also be a natural way to write things even if you don't care about the order, but you need all the results before proceeding. You're going to be held up until the longest-running task completes anyway, so it doesn't matter if some of them finish earlier and have to sit around waiting for you to collect the result. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern wrote:
> On 2010-03-08 15:20 PM, Greg Ewing wrote:
> > Mark Russell wrote:
> >> Boolean flags are a common enough case that I'd be inclined to add a
> >> wrapper method,
> >>
> >> parser.add_bool_argument('--plot')
> >
> > +1, this looks good.
>
> I've added it to the argparse bugtracker, along with my suggested spelling
> add_flag():
>
>http://code.google.com/p/argparse/issues/detail?id=62
Shouldn't argparse bugs/enhancement tickets be going to bugs.python.org
now?
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On Tue, Mar 9, 2010 at 11:31, R. David Murray wrote:
> On Mon, 08 Mar 2010 15:35:46 -0600, Robert Kern wrote:
>> On 2010-03-08 15:20 PM, Greg Ewing wrote:
>> > Mark Russell wrote:
>> >> Boolean flags are a common enough case that I'd be inclined to add a
>> >> wrapper method,
>> >>
>> >> parser.add_bool_argument('--plot')
>> >
>> > +1, this looks good.
>>
>> I've added it to the argparse bugtracker, along with my suggested spelling
>> add_flag():
>>
>> http://code.google.com/p/argparse/issues/detail?id=62
>
> Shouldn't argparse bugs/enhancement tickets be going to bugs.python.org
> now?
Probably. Having used the the argparse tracker before, though, it was
the first place I thought to file it.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On Mon, Mar 8, 2010 at 2:11 PM, wrote: > Getting rid of the process-global state like this simplifies testing (both > testing of the executors themselves and of application code which uses > them). It also eliminates the unpleasant interpreter shutdown/module > globals interactions that have plagued a number of stdlib systems that keep > global state. Ok the new patch is submitted @ http://code.google.com/p/pythonfutures/issues/detail?id=1 *note there are 2 tests that fail and 1 test that dead locks on windows even without this patch, the deadlock test I am skipping in the patch and the two that fail do so for a reason that does not make sense to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
