Daniel Wong wrote:
Ironic that you should mention it. He already mentioned it.
The time machine thing is pretty much a standard
joke in the Python community, which goes to show
how common it is for people to be pleasantly
surprised by what Python already does.
I think everyone's being a bit ha
wesley chun wrote:
On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
Marcin 'Qrczak' Kowalczyk wrote:
Except that it works incorrectly for negative numbers.
wow, that is a great point. i didn't think of this either. it makes
it very inconvenient (see below) and makes it more difficult to say
On 29/05/2008, at 14:32, Brett Cannon wrote:
On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <[EMAIL PROTECTED]>
wrote:
Issue 2848 - mimetools has been deprecated for a while, but it is
still used in a bunch of places. Since this has been deprecated in
PEP
4 for a long time, should we add
On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
> > Except that it works incorrectly for negative numbers.
wow, that is a great point. i didn't think of this either. it makes
it very inconvenient (see below) and makes it more difficult to say
we've completed r
Eric Smith wrote:
Marcin ‘Qrczak’ Kowalczyk wrote:
2008/5/29 Eric Smith <[EMAIL PROTECTED]>:
I don't see it as a big problem. You can now use any prefix you want,
instead of the hard coded values that # supplied.
Except that it works incorrectly for negative numbers.
Excellent point. If
M.-A. Lemburg wrote:
* Why can't we have both PyString *and* PyBytes exposed in 2.x,
with one redirecting to the other ?
We do have that - the PyString_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymore - everything
in the Python core will us
Daniel Wong wrote:
Are there plans for introducing syntax like this:
(a, (b[2], c)) = ('big' ('red', 'dog'))
I think you'll find Guido has made another trip
in the time machine for this one:
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyri
On Thu, May 29, 2008 at 04:04:43PM -0500, Benjamin Peterson wrote:
> On Thu, May 29, 2008 at 2:57 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> > Any objection if I demand it be properly registered, assigned a number
> > and then rejected?
>
> I've added it for you. See r63794.
Thank you!
On Thu, May 29, 2008 at 2:57 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Thu, May 29, 2008 at 12:31:17PM -0700, Guido van Rossum wrote:
>> Let me just save everyone a lot of time and say that I'm opposed to
>> this change, and that I believe that it would cause way too much
>> disturbance to
On Thu, May 29, 2008 at 1:49 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>
>> Issue 2854 - gestalt needs to be added back into 3.0. This is
>> Benjamin's issue. =)
>
> Is that your way of say "Check in the patch!" ? :
On Wed, May 28, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> Issue 2854 - gestalt needs to be added back into 3.0. This is
> Benjamin's issue. =)
Is that your way of say "Check in the patch!" ? :)
--
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
[EMAIL PROTECTED] writes:
> 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:
> > I find it hard to believe that you have even attempted this, which has
> > bee
On Thu, May 29, 2008 at 12:31:17PM -0700, Guido van Rossum wrote:
> Let me just save everyone a lot of time and say that I'm opposed to
> this change, and that I believe that it would cause way too much
> disturbance to be accepted this close to beta.
>
> On Thu, May 29, 2008 at 12:21 PM, Oleg Bro
Jim Jewett writes:
> On 5/26/08, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > Jim Jewett writes:
>
> > > The only reason for this change is that __repr__ gets used when
> > > __str__ *should* be used instead.
>
> > That's not what the advocates say.
>
> I still haven't seen a
Marcin ‘Qrczak’ Kowalczyk wrote:
2008/5/29 Eric Smith <[EMAIL PROTECTED]>:
I don't see it as a big problem. You can now use any prefix you want,
instead of the hard coded values that # supplied.
Except that it works incorrectly for negative numbers.
Excellent point. If only this had been
Let me just save everyone a lot of time and say that I'm opposed to
this change, and that I believe that it would cause way too much
disturbance to be accepted this close to beta.
--Guido
On Thu, May 29, 2008 at 12:21 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> Hello. A draft for a discussion
Hello. A draft for a discussion.
PEP: XXX
Title: str(container) should call str(item), not repr(item)
Version: $Revision$
Last-Modified: $Date$
Author: Oleg Broytmann <[EMAIL PROTECTED]>,
Jim Jewett <[EMAIL PROTECTED]>
Discussions-To: python-3000@python.org
Status: Draft
Type: Standards Tr
On Thu, May 29, 2008 at 10:51 AM, <[EMAIL PROTECTED]> wrote:
> This is in response to Stefan Behnel, who wrote
>
>
>
> Tutorial section on "tuples and sequences", not quite the most hidden place in
> the universe.
>
> http://docs.python.org/tut/node7.html#SECTION00730
>
> Stef
2008/5/29 Eric Smith <[EMAIL PROTECTED]>:
> I don't see it as a big problem. You can now use any prefix you want,
> instead of the hard coded values that # supplied.
Except that it works incorrectly for negative numbers.
--
Marcin Kowalczyk
[EMAIL PROTECTED]
http://qrnik.knm.org.pl/~qrczak/
__
Christian,
so far you have not responded to any of the suggestions made on
this thread, only defended your checkin. That's not very helpful
in getting to some conclusion.
* What's so hard about going with a proper, standard solution that
doesn't involve using your preprocessor hack ?
* Why can'
> wesley chun wrote:
>>
>> i have to resort to the uglier:
>> >>> 'dec: {0}/oct: 0o{0:o}/hex: 0X{0:X}'.format(i)
>> 'dec: 45/oct: 0o55/hex: 0X2D'
[Nick Coghlan <[EMAIL PROTECTED]>]:
> Is being explicit about the displayed prefix really that much uglier? The
> old # alternative display formats wer
This is in response to Stefan Behnel, who wrote
Tutorial section on "tuples and sequences", not quite the most hidden place in
the universe.
http://docs.python.org/tut/node7.html#SECTION00730
Stefan
I just read that section twice and no where does it mention that
Pyt
On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
>>
>> 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 w
M.-A. Lemburg schrieb:
> Well, first of all, it is a change in the C API:
> APIs have different names now, they live in different files,
> the Python documentation doesn't apply anymore, books have to
> be updated, programmers trained, etc. etc. That's fine for
> 3.x, it's not for 2.x.
No, that's
On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote:
>
>
>>Issue 2847 - the aifc module still imports the cl module in 3.0.
>>Problem is that the cl module is gone. =) So it seems silly to have
>>the imports lying about. This can probably be changed to
Issue 2847 - the aifc module still imports the cl module in 3.0.
Problem is that the cl module is gone. =) So it seems silly to have
the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc
On 2008-05-28 22:47, Gregory P. Smith wrote:
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 ca
On 2008-05-28 19:08, Bill Janssen 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 perhaps (not sure, but
perhaps) the rush to
Stefan Behnel schrieb:
Christian Heimes wrote:
Stefan Behnel schrieb:
M.-A. Lemburg wrote:
If you use PyBytes APIs, you expect to find PyBytes functions in
the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
In Pyth
wesley chun wrote:
hi,
i'm looking to duplicate this string format operator '#' functionality
with the new format(). here it is using the old string format
operator:
i = 45
'dec: %d/oct: %o/hex: %X' % (i, i, i) # no "#" means no leading "0" or
"0x/X"
'dec: 45/oct: 55/hex: 2D'
'dec:
On Thu, May 29, 2008 at 9:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
>
>> 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 wh
Stefan Behnel wrote:
Nick Coghlan wrote:
Stefan Behnel wrote:
Besides, how likely is it that users set a breakpoint on the
PyBytes/PyString functions?
Not very likely at all - but it would still be nice if the PyBytes_*
symbols were visible to the linker as well as the preprocessor.
Right, t
Christian Heimes wrote:
> Stefan Behnel schrieb:
>> M.-A. Lemburg wrote:
>>> If you use PyBytes APIs, you expect to find PyBytes functions in
>>> the libs and also set breakpoints on these.
>> AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
>> here.
>
> In Python 2.6
2008/5/29 Nick Coghlan <[EMAIL PROTECTED]>:
> it would still be nice if the PyBytes_* symbols
> were visible to the linker as well as the preprocessor.
If this is not a strict requirement but a useful extra, then it might
be done in an unportable way. GCC has an 'alias' attribute:
http://gcc.gnu.
Stefan Behnel schrieb:
> M.-A. Lemburg wrote:
>> If you use PyBytes APIs, you expect to find PyBytes functions in
>> the libs and also set breakpoints on these.
>
> AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
> here.
In Python 2.6 the PyBytes_* functions are only
Stefan Behnel schrieb:
> Christian Heimes wrote:
>> * add a new file stringobject.h which contains the aliases PyString_ ->
>> PyBytes_
>
> Just a quick note that that file is still missing from SVN, so it's kind of
> hard to compile existing code against the current branch state...
No, the file
Stefan Behnel wrote:
M.-A. Lemburg wrote:
If you use PyBytes APIs, you expect to find PyBytes functions in
the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
The PyBytes_* functions appear to be there, but a preproc
wesley chun wrote:
i have to resort to the uglier:
'dec: {0}/oct: 0o{0:o}/hex: 0X{0:X}'.format(i)
'dec: 45/oct: 0o55/hex: 0X2D'
Is being explicit about the displayed prefix really that much uglier?
The old # alternative display formats were somewhat arbitrary.
is this functionality being
[EMAIL PROTECTED] wrote:
> I just looked through the official tutorial and Dive into Python, and
> didn't find anything about it in either of those places.
Tutorial section on "tuples and sequences", not quite the most hidden place in
the universe.
http://docs.python.org/tut/node7.html#SECTION007
hi,
i'm looking to duplicate this string format operator '#' functionality
with the new format(). here it is using the old string format
operator:
>>> i = 45
>>> 'dec: %d/oct: %o/hex: %X' % (i, i, i) # no "#" means no leading "0"
>>> or "0x/X"
'dec: 45/oct: 55/hex: 2D'
>>> 'dec: %d/oct:
this work, (a, (b[2], c)) = ('big', ('red', 'dog'))
but this not (a, (b[2], c)) += ('big' ('red', 'dog'))
paul bedaride
On Thu, May 29, 2008 at 6:52 AM, <[EMAIL PROTECTED]> wrote:
> Indeed. Thank you, Guido.
>
> On 5/28/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Apart from the missing c
M.-A. Lemburg wrote:
> If you use PyBytes APIs, you expect to find PyBytes functions in
> the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
Besides, how likely is it that users set a breakpoint on the PyBytes/PyString
f
Lisandro Dalcin wrote:
> Chistian, I've posted some weeks ago some observation about the status
> of PyNumberMethods API. The thread link is below, I t did not received
> much atention.
>
> http://mail.python.org/pipermail/python-3000/2008-May/013594.html
>
> Now I sumarize that post
>
> * 'nb_n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
| If you use PyBytes APIs, you expect to find PyBytes functions in
| the libs and also set breakpoints on these.
Very good point.
- --
Jesus Cea Avion _/_/ _/_/_/_/_/_/
[EMAIL PROTECTED] - ht
Christian Heimes wrote:
> * add a new file stringobject.h which contains the aliases PyString_ ->
> PyBytes_
Just a quick note that that file is still missing from SVN, so it's kind of
hard to compile existing code against the current branch state...
Stefan
_
45 matches
Mail list logo
