Paul Prescod <paulp@ActiveState.com> writes:
> Michael Hudson wrote:
> >
> >...
> > I propose adding a fourth, optional, "flags" argument to the
> > builtin "compile" function. If this argument is omitted, there
> > will be no change in behaviour from that of Python 2.1.
> >
> > If it is present it is expected to be an integer, representing
> > various possible compile time options as a bitfield.
>
> Nit: What is the virtue to using a C-style bitfield? The efficiency
> isn't much of an issue. I'd prefer either keyword arguments or a list of
> strings.
Err, hadn't really occured to me to do anything else, to be honest!
At one point I was going to use the same bits as are used in the
code.co_flags field, which was probably where the bitfield idea
originated.
By "keyword arguments" do you mean e.g:
compile(source, file, start_symbol, generators=1, division=0)
? I think that would be mildly painful for the one use I had in mind
(the additions to codeop), and also mildly painful to implement.
compile(source, file, start_symbol,{'generators':1, 'division':0})
would be better from my point of view. I think this is a bit of a
propeller-heads-only feature, to be honest, so I'm not that inclined
to worry aobut the API.
Cheers,
M.
--
3. Syntactic sugar causes cancer of the semicolon.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4