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 should be
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
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 meth(1,
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
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 be
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
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
--- 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
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, with
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 checked in
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 ?
/F
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...
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 for
--- 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 time as is
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. do
--- 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 been discussed
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 try
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
local function
--- 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 variables
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
--- 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 any
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
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 code),
[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 %ld,
[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 have
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't know how
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 a
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
[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
anything
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.
I
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 free vars,
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
first
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
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 yet. When
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 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 accessible in a
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
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 to be
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
thought PEP's
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 ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
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
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 justifications
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
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 executed first.
No. %-formatting
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, ranging
[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,
[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, and
[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
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.
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. %-formatting should always use the 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,
being
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. I think
52 matches
Mail list logo
