On Wed, May 28, 2008 at 5:12 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> >> - Add ``'%a'`` string format operator. ``'%a'`` converts any python
>> >> object to string using ``repr()`` and then hex-escape all non-ASCII
>> >> characters. ``'%a'`` operator generates same string as ``'%r'`` in
On Tue, May 27, 2008 at 10:06 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> * Characters defined in the Unicode character database as "Separator"
>> (Zl, Zp, Zs) other than ASCII space(0x20).
>
> Please put in a note that Zl and Zp refer only to two specific
> unicode characters, not to what
I actually read a good portion of the thread that PEP 3099 refers to,
so I thought I had read up on the subject before making my suggestion.
I had also perused that PEP and didn't realize there was no way my
suggestion could be accepted.
I suppose it's too late, but I think it's too bad that a neg
Travis Oliphant wrote:
> Stefan Behnel wrote:
>> Anyway, my point is that this part of the protocol actually implies
>> setting a
>> lock on the buffer *provider* rather than the buffer itself, as the
>> buffer
>> provider cannot distinguish between different buffers based on a NULL
>> pointer
>
>
It's been decided to go w/ the "nonlocal" keyword to declare outer
variables (ala the "global" keyword) rather than using an alternate
assignment operator (which was one of the competing proposals). It's
too late to make a change such as your suggestion because PEP 3104 (
http://www.python.org/dev/
I'm confused by the section on "no alternate binding operator" in PEP
3099. On the one hand, it says no alternative binding operator will be
considered; yet the link provided shows that Guido is in favor of
developing a syntax for non-local assignment. Please excuse me if this
post violates that ru
Indeed. Thank you, Guido.
On 5/28/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Apart from the missing comma after 'big' this is already supported.
>
> The time machine strikes again!
>
> --Guido
>
> On Wed, May 28, 2008 at 6:23 PM, Daniel Wong <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Are there
I just looked through the official tutorial and Dive into Python, and
didn't find anything about it in either of those places. While this
feature is documented in the language reference, it does not seem to
be a well-known feature (another example: at least one other person
did not know about it).
Apart from the missing comma after 'big' this is already supported.
The time machine strikes again!
--Guido
On Wed, May 28, 2008 at 6:23 PM, Daniel Wong <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Are there plans for introducing syntax like this:
>
> (a, (b[2], c)) = ('big' ('red', 'dog'))
>
> It seems
The issues related to PEP 3108 now total 14. With the beta
(supposedly) in a week, I am hoping the last minor details can be
pulled together or decisions made on what can be postponed and what
should definitely be considered a release blocker.
Issue 2847 - the aifc module still imports the cl modu
Well, I'm sorry for bothering his majesty with such a stupid idea. At
least one other person didn't know about it either...
On 5/28/08, Mike Klaas <[EMAIL PROTECTED]> wrote:
>
> On 28-May-08, at 6:23 PM, Daniel Wong wrote:
>
>> Currently, I must do the following instead:
>>
>> for n, pair in enume
On 28-May-08, at 6:23 PM, Daniel Wong wrote:
Currently, I must do the following instead:
for n, pair in enumerate(list_of_pairs):
a, b = pair
...
<>
Thoughts?
I find it hard to believe that you have even attempted this, which has
been valid in python for ages:
>>> for x, (a, b) in enu
Hi Daniel,
At the moment, we are preparing to ship betas, so this kind of
proposal is a little late for 2.6/3.0. Also, I would recommend to try
this on the python-ideas mailing list first.
--
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
_
Hi,
Are there plans for introducing syntax like this:
(a, (b[2], c)) = ('big' ('red', 'dog'))
It seems quite doable, because Professor Hillfinger at UC Berkeley
created pyth, a dialect of Python, which has this feature. See page 10
of the spec he created for his students to implement the languag
Lisandro Dalcin wrote:
You emit a
Comm.Recv_init() call with the pointer to the buffer receiving the
message (then you have to ask the object for the buffer pointer).
... Then when you initiate the communication, we should
lock the object
No, you can't rely on a buffer pointer returned earlier
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
>
> How can it be that we allow major C API chang
On Wed, May 28, 2008 at 10:08 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I'm beginning to wonder whether I'm the only one who cares about
>> the Python 2.x branch not getting cluttered up with artifacts caused
>> by a broken forward merge strategy.
>
> I share your concern. Seems to me that pe
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to back-port from 3.x, and the concern ab
On 5/27/08, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Travis Oliphant wrote:
>
> > Obviously, if you haven't provided a Py_buffer structure to fill in, then
> you are only asking to lock the object's buffer from other access.
> >
>
> What's the use case for that? Why would you ever want
> to lock a
M.-A. Lemburg wrote:
You are probably talking about the great renaming between 1.4 and 1.5.
That was different, since it changes almost all C APIs in Python.
And it used the standard practice... from rename2.h in Python 1.5:
/* This file contains a bunch of #defines that make it possible to use
On 2008-05-28 14:02, Christian Heimes wrote:
M.-A. Lemburg schrieb:
I have a feeling that we should be looking for better merge
tools, rather than implement code changes that cause more trouble
than do good, just because our existing tools aren't smart
enough.
We don't have better tools at our
On 2008-05-28 14:29, Paul Moore wrote:
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I care, but I struggle to und
On 28/05/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I care, but I struggle to understand the implications and/or what
M.-A. Lemburg schrieb:
> I have a feeling that we should be looking for better merge
> tools, rather than implement code changes that cause more trouble
> than do good, just because our existing tools aren't smart
> enough.
We don't have better tools at our hands. I don't think we'll get any
tools
On Tue, May 27, 2008 at 10:48 PM, Carl Johnson <[EMAIL PROTECTED]> wrote:
> - - - -
>
> Potential downside #1: Don't try to print an infinite object, like
> itertools.count().
>
> Other potential downside #2: This makes "".join(l) obsolete.
No, it wouldn't. What is people want to join sequences wi
On Wed, May 28, 2008 at 12:14:50AM +0400, Oleg Broytmann wrote:
>I have wrote the PEP.
I'm discussing the PEP with Jim Jewett - more motivation and better
wording - so the PEP will be published a bit later.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTEC
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
How can it be that we allow major C API changes such as the renaming
of the PyString APIs to go into the trunk without discussi
27 matches
Mail list logo
