Ron Adam <[EMAIL PROTECTED]> wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should. The various use cases involve multi-part transactions and
> > such.
>
> I think so now too, I had thought as Nick does earlier this week that
> the non-looping version
Ron Adam wrote:
> There seems to be some confusion as to weather or
> not 'for's will do finalizing. So I was trying to stress I think
> regular 'for' loops should not finalize. They should probably give an
> error if an object with an try-finally in them or an __exit__ method.
But if the for
[Michele Simionato]
> Is there in the plans any facility to copy functions? Currently I am
doing
>
> def copyfunc(func):
> "Creates an independent copy of a function."
> c = func.func_code
> nc = new.code(c.co_argcount, c.co_nlocals, c.co_stacksize,
c.co_flags,
> c.co
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should. The various use cases involve multi-part transactions and
> > such.
[snip looping block discussion]
> For the one good use case for a user d
Ron Adam <[EMAIL PROTECTED]> wrote:
> There's also the possibility to use conditional looping based on the
> value returned from the generator.
>
> do VAR from EXPR if VAR==CONST:
> BLOCK
>
> This is a bit verbose, but it reads well. :-)
Reading well or not, this is not really an option fo
Nicholas Bastin wrote:
>> Again, patches are welcome. I was opposed to Nick's proposed changes,
>> since they explicitly said that you are not supposed to know what
>> is in a Py_UNICODE. Integrating the essence of PEP 261 into the
>> main documentation would be a worthwhile task.
>
>
> You can't
On 5/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> In this case, the informally-discussed proposal is to add a mutable
> __signature__ to functions, and have it be used by inspect.getargspec(), so
> that decorators can copy __signature__ from the decoratee to the decorated
> function.
Is there
Nicholas Bastin wrote:
> It's not always 2 bytes on Windows. Users can alter the config options
> (and not unreasonably so, btw, on 64-bit windows platforms).
Did you try that? I'm not sure it even builds when you do so, but if it
does, you will lose the "mbcs" codec, and the ability to use Unico
Nicholas Bastin wrote:
>> Changing the documentation that goes along with the option
>> would be fine.
>
>
> That is exactly what I proposed originally, which you shot down. Please
> actually read the contents of my messages. What I said was "change the
> configure option and related documentat
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>>I should have said "...should not finalize at the end of the for loop".
>> With generators, you may not want them to finalize before you are done
>>with them, and the same with class's.
>
>
> So you don't use them with a structur
Josiah Carlson wrote:
> The argument over whether blocks should loop, I believe has been had;
> they should. The various use cases involve multi-part transactions and
> such.
The number of good use cases for a looping block statement currently stands at
exactly 1 (auto_retry). Every other use ca
Jp Calderone <[EMAIL PROTECTED]> writes:
> If such a construct is to be introduced, the ideal spelling would seem to
> be:
>
> for [VAR in] EXPR:
> BLOCK1
> finally:
> BLOCK2
Does this mean that adding
finally:
pass
to a for block would make the for loop
Josiah Carlson wrote:
> The argument over whether blocks should loop, I believe has been had;
> they should. The various use cases involve multi-part transactions and
> such.
Then it is not so much looping but more pushing forward the state of
the state of the block's life-cycle?
This might by a
Josiah Carlson wrote:
> Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
>> end. The list itself remains untouched.
>
> My mistake, I did not understand your use of pronouns.
And, rereading my post, I used an ambigous reference.
My
Nick Coghlan wrote:
> Iterating over a sequence. If it's single-pass (and always single pass), you
> should use a user defined statement instead.
> That's the technique suggested for the single-pass user defined statements.
> However, a 'for loop with finalisation' is *still fundamentally an i
On May 8, 2005, at 1:44 PM, Martin v. Löwis wrote:
> Shane Hathaway wrote:
>> Fair enough. The original point is that the documentation is unclear
>> about what a Py_UNICODE[] contains. I deduced that it contains either
>> UCS2 or UCS4 and implemented accordingly. Not only did I guess wrong,
>
On May 8, 2005, at 5:28 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> All of my proposals for what to change the documention to have been
>> shot down by Martin. If someone has better verbiage that they'd like
>> to see, I'd be perfectly happy to patch the doc.
>
> I don't look into the
On May 8, 2005, at 5:15 AM, Martin v. Löwis wrote:
> 'configure takes an option --enable-unicode, with the possible
> values "ucs2", "ucs4", "yes" (equivalent to no argument),
> and "no" (equivalent to --disable-unicode)'
>
> *THIS* documentation would break. This documentation is factually
> co
Shane Hathaway wrote:
> Fair enough. The original point is that the documentation is unclear
> about what a Py_UNICODE[] contains. I deduced that it contains either
> UCS2 or UCS4 and implemented accordingly. Not only did I guess wrong,
> but others will probably guess wrong too. Something in t
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
> end. The list itself remains untouched.
My mistake, I did not understand your use of pronouns.
- Josiah
___
Python-Dev mailing list
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > It's not a matter of 'will they be finalized', but instead a matter of
> > 'will they be finalized in a timely manner'. From what I understand;
> > upon garbage collection, any generator-based resource will be finalized
> > via __exi
M.-A. Lemburg wrote:
> All this talk about UTF-16 vs. UCS-2 is not very useful
> and strikes me a purely academic.
>
> The reference to possibly breakage by slicing a Unicode and
> breaking a surrogate pair is valid, the idea of UCS-4 being
> less prone to breakage is a myth:
Fair enough. The or
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>
>>Josiah Carlson wrote:
>>
I think a completely separate looping or non-looping construct would be
better for the finalization issue, and maybe can work with class's with
__exit__ as well as generators.
>>>
>>>From what I
Nick Coghlan wrote:
> The whole PEP draft can be found here:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
I've updated this based on the feedback so far. The biggest change is that I've
dropped the 'del' idea in favour of an optional 'finally' clause on for loops
that finalises th
Paul Moore wrote:
> On 5/8/05, Jp Calderone <[EMAIL PROTECTED]> wrote:
>
>> If such a construct is to be introduced, the ideal spelling would seem to
>> be:
>>
>>for [VAR in] EXPR:
>>BLOCK1
>>finally:
>>BLOCK2
>
>
> While I have not been following this discussion at all
On 5/8/05, Jp Calderone <[EMAIL PROTECTED]> wrote:
> If such a construct is to be introduced, the ideal spelling would seem to
> be:
>
> for [VAR in] EXPR:
> BLOCK1
> finally:
> BLOCK2
While I have not been following this discussion at all (I don't have
the energy or ti
Ron Adam wrote:
> Question: Is the 'for' in your case iterating over a sequence? or is it
> testing for an assignment to determine if it should continue?
Iterating over a sequence. If it's single-pass (and always single pass), you
should use a user defined statement instead.
> The difference i
Josiah Carlson wrote:
> Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> I don't know. Using 'del' in that place seems ackward to me.
>> Why not use the following rule:
>> for [VAR in] EXPR:
>> SUITE
>> If EXPR is an iterator, no finalisation is done.
>> If EXPR is not an iterator, it
Nicholas Bastin wrote:
> All of my proposals for what to change the documention to have been
> shot down by Martin. If someone has better verbiage that they'd like
> to see, I'd be perfectly happy to patch the doc.
I don't look into the specific wording - you speak English much better
than I do
Nicholas Bastin wrote:
>> -1. This breaks existing documentation and usage, and provides only
>> minimum value.
>
>
> Have you been missing this conversation? UTF-16 is *WHAT PYTHON
> CURRENTLY IMPLEMENTS*. The current documentation is flat out wrong.
> Breaking that isn't a big problem in my
Ron Adam <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >>I think a completely separate looping or non-looping construct would be
> >>better for the finalization issue, and maybe can work with class's with
> >>__exit__ as well as generators.
> >
> > From what I understand, the entire c
Nicholas Bastin wrote:
> I don't consider either alternative useless (well, I consider UCS-2 to
> be largely useless in the general case, but as we've already discussed
> here, Python isn't really UCS-2). However, I would be a lot happier if
> we just chose *one*, and all Python's used that one.
M.-A. Lemburg wrote:
> I believe that it would be more appropriate to adjust the _tkinter
> module to adapt to the TCL Unicode size rather than
> forcing the complete Python system to adapt to TCL - I don't
> really see the point in an optional extension module
> defining the default for the interp
M.-A. Lemburg wrote:
> Unicode has many code points that are meant only for composition
> and don't have any standalone meaning, e.g. a combining acute
> accent (U+0301), yet they are perfectly valid code points -
> regardless of UCS-2 or UCS-4. It is easily possible to break
> such a combining seq
34 matches
Mail list logo
