Re: Block return values (myhdl.BlockError)
Henry Gomersall <[email protected]> Tue, 10 May 2016 13:12:41 +0100
| Newsgroups | gmane.comp.python.myhdl |
|---|---|
| Message-ID | <[email protected]> |
On 10/05/16 13:09, Henry Gomersall wrote: > On 10/05/16 12:30, Jan Decaluwe wrote: >> > On 10/05/16 12:02, Henry Gomersall wrote: >>>> >> > On 10/05/16 10:45, Henry Gomersall wrote: >>>>>> >>> >> On 10/05/16 10:32, Jan Decaluwe wrote: >>>>>>>>>> >>>>> >>>> I have considered this issue for some time now >>>>>>>>>> >>>>> >>>> and I have basically decided to leave the constraints >>>>>>>>>> >>>>> >>>> as they are, that is, blocks should only return >>>>>>>>>> >>>>> >>>> block and instantiator objects. >>>>>> >>> >> I think your reasoning is sound. >>>>>> >>> >> >>>>>> >>> >> Do you object to alternative strategies for constructing Block >>>>>> >>> >> operators? This could leave @block as the default usual case, with more >>>>>> >>> >> esoteric cases handled by direct access to the construction of the Block >>>>>> >>> >> object. This could allow the best of both worlds - simple default and >>>>>> >>> >> arbitrary control if desired. >>>> >> > >>>> >> > Actually, a neat solution could be to allow optional decorator arguments >>>> >> > taking the class constructor and allow subclassing of _Block. >>>> >> > >> > Independent of this feature, decorator arguments may be >> > useful, but as you know a decorator without arguments >> > behaves completely differently from a decorator with >> > arguments. >> > >> > Until now, the only way I saw to handle both cases >> > with a single decorator was with some ad-hoc check >> > that I didn't find very elegant. > Yeah this is an issue. There's a somewhat neat way using keyword args > exclusively, but it does require keyword args (which is not overly > restrictive since this would be an "advanced" feature). > > In this case it might work reasonably neatly in the simpler case though > since we can check it's either a callable or a _Block, and reject > anything else. To be clear, what is seen by a naive user need not changed. Both @block and @block(MyCustomBlock) can be made to work. Speaking of that, another solution is to have something like an @custom_block() decorator which _must_ take an argument. Henry ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j