Fredrik Lundh wrote:
> maybe it would be a good idea to add a "use setlocale" flag to the test-
> runner ?
Sure!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
Neal Norwitz wrote:
> I know very little about locale's. /f assigned me a bug
> http://python.org/sf/1391872 which suggests I run all the tests in a
> different locale than C. I think this is a good idea, but when I set
> LANG or LC_ALL or LC_CTYPE in the env't the locale isn't set without
> me c
Neal Norwitz wrote:
> > No. %-formatting should always use the C locale. One should use
> > locale.format to get locale-aware formatting.
>
> I know very little about locale's. /f assigned me a bug
> http://python.org/sf/1391872 which suggests I run all the tests in a
> different locale than C.
Tim Peters wrote:
> We could use the "I" (capital letter eye) length modifier under VC7.1.
> That's good for both size_t and ptrdiff_t formats under VC7.1, where
> ptrdiff_t under VC7.1 is really the same concept as Py_ssize_t.
ptrdiff_t has the advantage of being available on all platforms,
bein
On 1/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
> > >>> "%f" % 1.0
> > '1.00'
> > >>> u"%f" % 1.0
> > u'1,00'
> >
> > Is this intended? This breaks test_format on my box when test_builtin
> > (method
> > test_float_with_comma) is executed first.
>
> No. %-fo
Tim Peters wrote:
> That's no more or less painful than using C99's huge pile of PRId8,
> PRId16, PRId32 (etc, etc) macros, defined there for similar purposes.
Right - and I consider them just as painful.
If you believe that this is really what we should be doing, then, well,
let's do it.
Regar
Samuele Pedroni wrote:
> Ian Bicking wrote:
>
>>I just don't want people to feel discouraged when they try to contribute
>>to the Python community and a PEP 13 could help direct people towards
>>areas where their contributions are more likely to be useful.
>
>
> but people have a lot of optio
> From: "Martin v. Löwis" <[EMAIL PROTECTED]>
>
> So at the moment, I'm quite happy with buildbot. My only wish is that
> it would do static pages, rather than being a web server. I set it up
> as a reverse proxy (so nobody knows what the port number is, but still).
As a bit of history, the build
On 1/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Martin]
> >> But now: who is going to write it? "Guido should write it" clearly won't
> >> work. And no, I'm explicitly not volunteering either.
>
> [Thomas]
> > Well, the PEP will be mostly boilerplate anyway (unless there's a sudden
> > influx o
James Y Knight wrote:
> On Jan 8, 2006, at 1:01 PM, Martin v. Löwis wrote:
>
>> Fred L. Drake, Jr. wrote:
>>
>>> I like the way trial (from twisted) supports this. The test
>>> method is written
>>> normally, in whatever class makes sense. Then the test is marked
>>> with an
>>> attribute to
[Martin]
>> But now: who is going to write it? "Guido should write it" clearly won't
>> work. And no, I'm explicitly not volunteering either.
[Thomas]
> Well, the PEP will be mostly boilerplate anyway (unless there's a sudden
> influx of old ideas) so I'm sure I can whip something up before next
>
On Mon, Jan 09, 2006 at 12:31:46AM +0100, "Martin v. Löwis" wrote:
> Ian Bicking wrote:
> > I just don't want people to feel discouraged when they try to contribute
> > to the Python community and a PEP 13 could help direct people towards
> > areas where their contributions are more likely to be
[Martin v. Löwis]
> On VC7.1, we could use 'L', right?
We could use the "I" (capital letter eye) length modifier under VC7.1.
That's good for both size_t and ptrdiff_t formats under VC7.1, where
ptrdiff_t under VC7.1 is really the same concept as Py_ssize_t. On
32-bit boxes, "I" means 4 bytes, a
[Tim]
>> That handles C99-ish platforms by defalt. Other platforms (like
>> Windows) would need to supply their own expansion in their pyconfig.h.
>> Neal's format would become the god-awful
>> but platform-neutral:
>>
>> "%s() requires a code object with %" Py_SIZE_T_WIDTH "d free vars
Ian Bicking wrote:
> I just don't want people to feel discouraged when they try to contribute
> to the Python community and a PEP 13 could help direct people towards
> areas where their contributions are more likely to be useful.
but people have a lot of options, probably more effective, rangin
Georg Brandl wrote:
> >>> import locale
> >>> locale.setlocale(locale.LC_NUMERIC, "")
> '[EMAIL PROTECTED]'
> >>> "%f" % 1.0
> '1.00'
> >>> u"%f" % 1.0
> u'1,00'
> >>>
>
>
> Is this intended? This breaks test_format on my box when test_builtin (method
> test_float_with_comma) is exec
Ian Bicking wrote:
> I just don't want people to feel discouraged when they try to contribute
> to the Python community and a PEP 13 could help direct people towards
> areas where their contributions are more likely to be useful. Also I
> think it is unfair to use python-list to clarify things
Thomas Wouters wrote:
>>[T]he editorialization that Python isn't going to be a functional language
>>is both rather inaccurate, misses the real reason for statements, and
>>needlessly alienates people who like functional programming
>
>
>>So... maybe Guido or python-dev should write/vet the justi
On Sun, Jan 08, 2006 at 02:43:17PM -0600, Ian Bicking wrote:
> [T]he editorialization that Python isn't going to be a functional language
> is both rather inaccurate, misses the real reason for statements, and
> needlessly alienates people who like functional programming
> So... maybe Guido or py
On 1/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> many test frameworks support "expected failures" for this purpose.
> how hard would it be to add a
>
> unittest.FailingTestCase
>
> class that runs a TestCase, catches any errors in it, and signals an
> error ("test foo passed unexpectedly
> anyone knows anything about support for semantic markup ?
http://meta.wikimedia.org/wiki/Semantic_MediaWiki
not sure a full-blown RDF-in-wiki-syntax is really that optimal,
though ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
Ian Bicking wrote:
> Tim Peters wrote:
>
>>[Thomas Wouters]
>>
>>
>>>My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
>>>the minds of many, many people, not just Python developers) but that it
>>>isn't easily findable and it isn't easily accessible in a single location. I
Tim Peters wrote:
> [Thomas Wouters]
>
>>My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
>>the minds of many, many people, not just Python developers) but that it
>>isn't easily findable and it isn't easily accessible in a single location. I
>>thought PEP's where supposed
Hi,
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, "")
'[EMAIL PROTECTED]'
>>> "%f" % 1.0
'1.00'
>>> u"%f" % 1.0
u'1,00'
>>>
Is this intended? This breaks test_format on my box when test_builtin (method
test_float_with_comma) is executed first.
regards,
Georg
__
On Sun, Jan 08, 2006 at 06:31:35PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
> > the minds of many, many people, not just Python developers) but that it
> > isn't easily findable and it isn't easily accessib
The call to curses.setupterm() leaves my terminal in a bad state.
The reset program outputs:
Erase set to delete.
Kill set to control-U (^U).
Interrupt set to control-C (^C).
Doesn't the setupterm() have to be paired with something like shutdownterm()?
regards,
Georg
___
On Jan 8, 2006, at 1:01 PM, Martin v. Löwis wrote:
> Fred L. Drake, Jr. wrote:
>
>> I like the way trial (from twisted) supports this. The test
>> method is written
>> normally, in whatever class makes sense. Then the test is marked
>> with an
>> attribute to say it isn't expected to pass y
Fred L. Drake, Jr. wrote:
> I like the way trial (from twisted) supports this. The test method is
> written
> normally, in whatever class makes sense. Then the test is marked with an
> attribute to say it isn't expected to pass yet. When the code is fixed and
> the test passes, you get that
Tim Peters wrote:
> Yup. Because the supporting PyString_FromFormatV() doesn't know
> anything about z qualifiers now, if you _tried_ to use %zd then even
> on a C99-platform PyString_FromFormatV() wouldn't do any conversions
> from that point on: it would just copy the format string from the
> f
Tim Peters wrote:
> That handles C99-ish platforms by defalt. Other platforms (like
> Windows) would need to supply their own expansion in their pyconfig.h.
> Neal's format would become the god-awful
> but platform-neutral:
>
> "%s() requires a code object with %" Py_SIZE_T_WIDTH "d fr
On Sunday 08 January 2006 12:19, Martin v. Löwis wrote:
> I don't know how hard it would be, but I would also consider this
> appropriate. Of course, this should work on a case-by-case basis:
> if there are multiple test methods in a class, unexpected passes
> of each method should be reported.
[Tim]
> ...
> I suspect we're going to have other problems when someone gets around
> to passing a size_t-ish value to PyString_Format() or PyErr_Format().
> Maybe we could teach those about the "z" qualifier on all platforms.
Yup. Because the supporting PyString_FromFormatV() doesn't know
anythi
Martin v. Löwis wrote:
> But they might suffer from misunderstandings, such as your
> misunderstanding in how local variables work and whether
> 'self' is looked up in a dictionary.
>
> So it's being dumb - just being uninformed.
Sorry: "*not* being dumb" is what I wanted to say.
Regards,
Martin
Thomas Wouters wrote:
> My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
> the minds of many, many people, not just Python developers) but that it
> isn't easily findable and it isn't easily accessible in a single location.
Why would a single Wiki page not be accessible in
Ralf W. Grosse-Kunstleve wrote:
> The outside world is trying to tell you something; and they are not all dumb
> as
> you suggest in your other posting.
But they might suffer from misunderstandings, such as your
misunderstanding in how local variables work and whether
'self' is looked up in a dic
Fredrik Lundh wrote:
> many test frameworks support "expected failures" for this purpose.
> how hard would it be to add a
>
> unittest.FailingTestCase
>
> class that runs a TestCase, catches any errors in it, and signals an
> error ("test foo passed unexpectedly") if it runs cleanly ?
I don'
[Thomas Wouters]
> My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
> the minds of many, many people, not just Python developers) but that it
> isn't easily findable and it isn't easily accessible in a single location. I
> thought PEP's where supposed to be that, and if I h
[neal.norwitz]
>> PyErr_Format(PyExc_ValueError,
>> - "%s() requires a code object with %d free vars,"
>> - " not %d",
>> + "%s() requires a code object with %ld free vars,"
>> + " not
On Sun, Jan 08, 2006 at 01:35:16PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > Yet if it isn't recorded, people will keep bringing it up. How about a
> > 'rejected ideas' PEP for ideas that are right out no matter how people
> > argue?
> Recorded it is, in the mailing list archive.
At 01:25 PM 1/8/2006 +0100, Thomas Wouters wrote:
>On Sat, Jan 07, 2006 at 05:12:06PM -0800, Guido van Rossum wrote:
> > On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> > > Then simply reject the PEP and the discussion can be stopped on
> > > comp.lang.python too.
>
> > Only in the most severe
At 08:09 AM 1/8/2006 -0800, Ralf W. Grosse-Kunstleve wrote:
>--- Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> > The main difference isn't the lookup of 'self', it's the attribute
> retrieval
> > of 'x' from 'self'.
>
>I see. Thanks!
>If you put 'self' into a special category (with corresponding C
On Sun, Jan 08, 2006 at 08:09:22AM -0800, Ralf W. Grosse-Kunstleve wrote:
> --- Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > The main difference isn't the lookup of 'self', it's the attribute retrieval
> > of 'x' from 'self'.
> I see. Thanks!
> If you put 'self' into a special category (with corr
--- Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Please try the code below to see the performance impact.
>
> oh, please. do you seriously think that if you don't have to type "self"
> yourself, Python will suddenly be able to turn all instance variables into
> local function variables without an
Early bird registration for PyCon TX 2006 ends on January 15th, so
there's only a week left. To register, please go to:
http://us.pycon.org/TX2006/Registration
You can still register after Jan. 15th, but the cost will go up by
US$65 (US$25 for students).
This year PyCon will feature a da
--- Thomas Wouters <[EMAIL PROTECTED]> wrote:
> The main difference isn't the lookup of 'self', it's the attribute retrieval
> of 'x' from 'self'.
I see. Thanks!
If you put 'self' into a special category (with corresponding C code), couldn't
you use the same "indexing" tricks as for local variabl
Ralf W. Grosse-Kunstleve wrote:
> --- Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>>Please try the code below to see the performance impact.
>>
>>oh, please. do you seriously think that if you don't have to type "self"
>>yourself, Python will suddenly be able to turn all instance variables into
>
On Sun, Jan 08, 2006 at 07:35:53AM -0800, Ralf W. Grosse-Kunstleve wrote:
> IIUC, "self" is first looked up in the local dictionary.
No. Local variables are stored in a tuple (more or less,) and indexed by,
er, index. Loading a local variable onto the stack is a fairly fast
operation.
> Please t
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/6/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
> > > There are three different peculiarity in Python 2.x
> > > in respect of 'self' method argument:
> >
> > Yuk! This has b
Ralf W. Grosse-Kunstleve wrote:
> > what dictionary lookup ?
>
> IIUC, "self" is first looked up in the local dictionary.
no, self is a local variable. self.x means that "x" is looked up in the in-
stance dictionary, though.
> Please try the code below to see the performance impact.
oh, please
--- Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Ralf W. Grosse-Kunstleve wrote:
>
> > ***Please*** make Python more selfish. Note that this is also an obvious
> avenue
> > for significant performance increases. If self is implicit you don't have
> to do
> > the dictionary lookup for "self" all the
Neal Norwitz wrote:
> In the past, we haven't checked in tests which are known to be broken.
> There are several good reasons for this. I would prefer you, 1) also
> fix the code so the test doesn't fail, 2) revert the change (there's
> still a bug report open, right?), or 3) generalize tests fo
Georg> I then assumed a different name, partly to anonymize myself as
Georg> others had advised When I realized that I liked the
Georg> community and the development of Python very much, I decided to
Georg> "unveil" myself, but I could never overcome myself -- till now.
Hmmm.
Ralf W. Grosse-Kunstleve wrote:
> ***Please*** make Python more selfish. Note that this is also an obvious
> avenue
> for significant performance increases. If self is implicit you don't have to
> do
> the dictionary lookup for "self" all the time as is the case now.
what dictionary lookup ?
Neal Norwitz wrote:
> [moving to python-dev]
>
>> On 1/7/06, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>> > Well, it is not the test that's broken... it's compiler.
>
> [In reference to:
> http://mail.python.org/pipermail/python-checkins/2006-January/048715.html]
>
> In the past, we haven't
Thomas Wouters wrote:
> > Only in the most severe cases does it make sense to create a PEP
> > specifically to be rejected.
>
> Yet if it isn't recorded, people will keep bringing it up. How about a
> 'rejected ideas' PEP for ideas that are right out no matter how people
> argue? A single PEP, wit
--- Alexander Kozlovsky <[EMAIL PROTECTED]> wrote:
> What do you think about this?
I (who writes Python code for a living) love it! See also:
http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html
***Please*** make Python more selfish. Note that this is also an obvious avenue
for signifi
Donovan Baarda wrote:
> > No, it's a fundamental goal: to support light-weight generation of rendered
> > markup directly from source code, to enable simple tools (CGI scripts, etc)
> > to be able to render reference documentation.
>
> Python is run-time interpreted, but I don't think we need its
Thomas Wouters wrote:
> Yet if it isn't recorded, people will keep bringing it up. How about a
> 'rejected ideas' PEP for ideas that are right out no matter how people
> argue?
Recorded it is, in the mailing list archive.
However, a central place might be better, preferably with referrals to
pron
On Sat, Jan 07, 2006 at 05:12:06PM -0800, Guido van Rossum wrote:
> On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> > Then simply reject the PEP and the discussion can be stopped on
> > comp.lang.python too.
> Only in the most severe cases does it make sense to create a PEP
> specifically to
Respected sir, iam a un knowledged and un experienced person. i have an email to you but no reply. How you find me? i had joined icash business through icashline.com but
i failed. you always giving emails to me where as idoesnt have any know ledge of web and free hosting and linking we
Ian Bicking wrote:
> would have to be translated to this this:
>
>inst = Foo()
>f = Foo.bar
>meth = bind(f, inst)
>print meth(1, 2)
+1 for an explicit "bind unbound method operation", although I
would spell it as
inst = Foo()
f = Foo.bar
meth = f.bind(inst)
print
Hello,
today, when two Python developers here had approached me about the PSF, I
realized that it is time to correct a mistake which I had made over three years
ago, when I discovered Linux, free software, Usenet etc (I was sixteen at that
time).
I then assumed a different name, partly to anonym
Guido van Rossum wrote:
> On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>>Then simply reject the PEP and the discussion can be stopped on
>>comp.lang.python too.
>
>
> Only in the most severe cases does it make sense to create a PEP
> specifically to be rejected.
>>Or why do you think it
63 matches
Mail list logo
