Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Perhaps because people don't understand it? They don't accept it even more than they don't understand it. This leads to repeated guesses that the object model might perhaps change in Py3K with respect to explicit self [1]. It's not all just an educational issue. If this is not a severe case where an autoritarian decision should be made and also be made visible at a central and recoverable place I don't know what? Regards Kay [1] See e.g. Bruce Eckels postings on this page: http://www.artima.com/forums/flat.jsp?forum=106thread=141312start=75msRange=15 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Birkenfeld's gone
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 anonymize myself as others had advised. When I came across Python, I instantly liked it, and since I had interest in Open Source development in general, I wanted to try and contribute to the development. And, as a matter of course, I used my different name for that. When I realized that I liked the community and the development of Python very much, I decided to unveil myself, but I could never overcome myself -- till now. I'm really sorry, and I hope you could at least partly understand what caused me to act so irrational. regards, Georg PS: I'm quite prepared now for the PSU to visit my place and interrog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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, 2) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 29, Issue 111
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 web pages and ee business and mass mailing softwere. please reply first and then give other supports. thanking you.please stop mails from you! . i will inform to you then you send. ok. due to i am unable to view my computor for some period. may be3 months from now. thanking you.Send instant messages to your online friends http://in.messenger.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 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 oneliners to describe ideas, one or two lines to explain 'why not', references to the python-list or python-dev discussions, if any, and a sign in big friendly letters saying if you really must discuss these subjects, do it on python-list, not python-dev. Some of the stuff that could be in there: - implicit rather than explicit self: invalidates too many tricks - omitting () on functioncalls: like implicit self - changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language - methods for tuples: tuples are records, not collections; use lists instead - sigils to indicate 'self.' (e.g. @foo): loses readability, wins too little - '?' and other non-alphanumerical characters in identifiers: like sigils - strict private/public accessing: 'fake' protection; use closures instead etc. No need to come up with them all, I'm sure all the prize ideas will pop back up eventually ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 pronouncements or other discussion. A Wiki comes to mind... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] that library reference, again
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
documentation to be.
Are you sure ?
help(help)
From the pythondoc/lib goal list:
Support tighter (and 2-way) integration between the library reference
and help tools (pydoc, help, inspect, etc) and documentation generators
(epydoc, pythondoc, etc).
trivial is a relative term.
When I say trivial in this context, I mean that any programmer should
be capable of writing a Python tool that does some kind of basic processing
of the source format from scratch. The easier it is to do this, the more
likely it is that someone will come up with a new way to use the information
(Web 2.0, you know...)
As a some-times developer not really interested in writing
documentation, I must admit I really like ReST. It looks like plain
text, so I can write and use it as plain text, but it also can magically
transform to other formats and look pretty good.
Lots of looks like plain text if you squint formats can produce output
that looks pretty good.
The problem is semantics; I haven't seen any format that looks like plain
text but provides the amount of machine-readable semantic information
that we have today. And I want more semantics, not less.
I hate writing XML/HTML, and my only experience with LaTex was brief and
painful too. If I was forced to choose, I'd probably pick LaTex even
though I don't know it as well as XML/HTML (I'd rather face an unknown
evil than that particular devil I know).
Familiarity breeds contempt ? We're not talking about well-formed XML
here, nor 1996-era hand-rolled web sites. If you look at typical Java-
Doc or PythonDoc markup, or the translated samples, you'll notice that
the source code contains very few HTML tags.
(I seriously doubt that your problems with XML/HTML is the use of in-
stead of {...)
I'm not going to write docs for stuff I didn't write myself. I'm not
going to submit patches to Javadoc, LaTex or XML/HTML, but I might post
vague change this to... bug reports.
Writing good documentation is hard (which is why I prefer to leave it to
others if I can), but fixing almost good documentation doesn't have to
be /.../
Since I'm focussed on the library reference, I'm a lot more interested in
the fixers than the essay writers. Give people a way to find things to fix,
and a way to fix it, and they will.
It's the workflow that's the real problem here, but you cannot fix the
workflow
without fixing the markup.
I must say I disagree with this statement... changing the markup will
not change the workflow at all, just shave 3-6 mins off the compile-test
step. I don't do this enough to really know if that's worth it.
Do you think wikipedia would be what it is today if the edit/save process
included a 3-6 minute regenerate site pass ?
Heck, I've discovered dozens of bogosities in the current library reference
while working on the translation tools, and I have the sources and full SVN
access, but I find that the overhead discourages me from doing anything
about them (maybe later). I simply don't have time to fix anything but
very minor typos within a standard 15-minute let's improve python time
slot, and I sure don't think I'm unique in this respect.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- 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 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. Good luck with your battle! Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 oneliners to describe ideas, one or two lines to explain 'why not', references to the python-list or python-dev discussions, if any, and a sign in big friendly letters saying if you really must discuss these subjects, do it on python-list, not python-dev. Some of the stuff that could be in there: - implicit rather than explicit self: invalidates too many tricks - omitting () on functioncalls: like implicit self - changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language - methods for tuples: tuples are records, not collections; use lists instead - sigils to indicate 'self.' (e.g. @foo): loses readability, wins too little - '?' and other non-alphanumerical characters in identifiers: like sigils - strict private/public accessing: 'fake' protection; use closures instead etc. No need to come up with them all, I'm sure all the prize ideas will pop back up eventually ;) the FAQ touches many of these. maybe a couple of clarifications to the relevant FAQ texts (explaining things in terms of design tradeoffs, rather than absolute truths) would be good enough ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py
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 tests which are known to be broken. Okay. I apologize. I originally intended to fix it, but I found that I don't have the time to search the bug. 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 known bugs. I strongly prefer #1, but have been thinking about adding #3. There are many open bug reports that fall into two broad categories: incorrect behaviour and crashers. I've been thinking about adding two tests which incorporate these bugs as a way of consolidating where the known problems are. Also, it's great when we have test cases that can be moved to the proper place once the fix has been checked in. I'm proposing something like add two files to Lib/test: outstanding_bugs.py and outstanding_crashes.py. Both would be normal test files with info about the bug report and the code that causes problems. This test in test_compiler should be moved to outstanding_bugs.py. I added outstanding_bugs.py and this initial test. regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Birkenfeld's gone
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... How do we know Reinhold Birkenfeld and Georg Brandl are the same person? In fact, how do we know GB didn't overcome RB in some nefarious way and that RB isn't swimming with the fishes in the Rhein or buried deep in the Black Forest? Different first name, different last name, different ISP. From here it appears your hair color may have changed as well. Only the -nospam in your email addresses is the same... I'm sure the PSU will be able to ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
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 known bugs. I strongly prefer #1, but have been thinking about adding #3. There are many open bug reports that fall into two broad categories: incorrect behaviour and crashers. I've been thinking about adding two tests which incorporate these bugs as a way of consolidating where the known problems are. Also, it's great when we have test cases that can be moved to the proper place once the fix has been checked in. 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 ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- 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 the case now. what dictionary lookup ? IIUC, self is first looked up in the local dictionary. Please try the code below to see the performance impact. As an alternative to a copy/paste exercise try this: wget http://cci.lbl.gov/~rwgk/python/self_lookup.py python self_lookup.py The output with Python 2.4.1/Fedora3/Opteron is: loop_function: 13.10 loop_class: 17.11 Cheers, Ralf import time def loop_function(x, n): result = 0 for i in xrange(n): result += x return result class loop_class: def __init__(self, x, n): self.x = x self.n = n def __call__(self): result = 0 for i in xrange(self.n): result += self.x return result def run(x=3.1415, n=10**8): t0 = time.time() loop_function(x=x, n=n) print loop_function: %.2f % (time.time() - t0) t0 = time.time() loop_class(x=x, n=n)() printloop_class: %.2f % (time.time() - t0) if (__name__ == __main__): run() __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 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 performance overhead ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- 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 again and again already. *Please* move this discussion to comp.lang.python. Yes please. This is a death penalty, even without your explicit rejection. No professional person has the time to sift through that volume of noise. This won't change. The outside world is trying to tell you something; and they are not all dumb as you suggest in your other posting. I suggest creating [EMAIL PROTECTED] Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 the code below to see the performance impact. As an alternative to a copy/paste exercise try this: wget http://cci.lbl.gov/~rwgk/python/self_lookup.py python self_lookup.py The output with Python 2.4.1/Fedora3/Opteron is: loop_function: 13.10 loop_class: 17.11 The main difference isn't the lookup of 'self', it's the attribute retrieval of 'x' from 'self'. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 variables without any performance overhead ? Yes, exactly, since you can make the local namespace vs. instance attribute distinction in C. Cheers, Ralf that indeed proves why this discussion for whatever value it has, belongs to comp.lang.python. This is not a place to clarify people how Python currently works, or to have discussions made of guesses and half-formed speculations. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- 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 and make 'self.x' just as fast as 'x'? Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon TX 2006: Early-bird registration ends Jan. 15!
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 day of tutorials before the three days of regular presentations. Course outlines for all the tutorials have been posted; see http://wiki.python.org/moin/PyCon2006/Tutorials All of the PyCon tutorials are still open for new registrations, but space is limited. Don't forget to book your hotel room, too. PyCon TX 2006 is being held at a Dallas/Addison hotel, and we have negotiated a special low rate of $79 plus applicable taxes: http://us.pycon.org/Addison/Hotels We hope to see you in Texas! Regards, A.M. Kuchling [EMAIL PROTECTED] Chair, PyCon 2006 http://us.pycon.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- 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 performance overhead ? Yes, exactly, since you can make the local namespace vs. instance attribute distinction in C. Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 corresponding C code), couldn't you use the same indexing tricks as for local variables and make 'self.x' just as fast as 'x'? No need to make 'self' magical for that. You do, however, need to make the *object* magical for that. It works for local namespaces because the Python compiler knows exactly which names are local and which aren't. There are two cases where the compiler can't know for sure (using 'exec' without 'in' and using 'from module import *') and in those cases, Python doesn't optimize local variable access all the way. This all won't work for objects and their attributes because too much is possible at runtime for the current compiler to handle. The compiler could, of course, check everything in the whole program, keeping track of what could possibly adjust which attributes of what object where. That would be 'type inferencing' and has been (and is being, I guess) attempted by various people in various projets. However, if your compiler is so smart, it won't have _any_ problems taking an exlicit self into account :) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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), couldn't you use the same indexing tricks as for local variables and make 'self.x' just as fast as 'x'? It's not nearly that simple. See e.g.: http://mail.python.org/pipermail/python-dev/2002-February/019854.html Note, however, that such a speedup is entirely independent of the syntax. Trying to link the syntax with the performance is completely bogus. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
[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, PyString_AsString(op-func_name), nclosure, nfree); [Martin v. Löwis] I'm not sure whether this is the right fix. This says nclosure and nfree are longs; this is true on most 32-bit systems (where ssize_t is int and int and long have the same width), and on some 64-bit systems (where ssize_t and long are the same). It does not work for Win64 (where ssize_t is larger than long). Ya, that doesn't work. We'll have similar problems with obmalloc debug output if obmalloc is changed to escape 32-bitness on Win64 -- and anywhere else we need to format one of these things. I'm tempted to use %zd in these places, but fear that it isn't portable enough (it *is* part of C99). MS VC 7.1 doesn't support the z length qualifier, and I expect that kills it right there. So we need a macro, say Py_SIZE_T_WIDTH, in pyport.h: /* Length qualifier for use in formats when printing size_t or Py_ssize_t values. */ #ifndef Py_SIZE_T_WIDTH # define Py_SIZE_T_WIDTH z #endif 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, not % Py_SIZE_T_WIDTH d 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
[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 a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. ... And I would like to point out how hard it is to google or grep for ideas like this. For instance, the 'x, y, *rest = someseq' syntax. I wouldn't know what to call it (or what others would call it, and you can't google for the syntax (since the variables can be named anything). If PEP 13 grows large enough, won't be easy to find there either. But it will be easy to remember _where_ to look. ... And a PEP titled 'Rejected Ideas' would certainly be the first place to look ;) Too bland ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
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 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. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 single location? Why is the FAQ not accessible in a single location? I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Right. However, I doubt you would look in the rejected ideas PEP. I guess a Wiki'd work, but then I wonder, why aren't all PEPs in a Wiki instead? There might be several reasons - one is that a PEP is supposed to get posted to mailing lists and newsgroups, something that is not readily possible with Wiki pages. And I would like to point out how hard it is to google or grep for ideas like this. For instance, the 'x, y, *rest = someseq' syntax. I agree that collecting them in a single place is a good idea. Whether this is a PEP, a Wiki page, or the FAQ is nearly irrelevant, except: - it is strange to call it a Python Enhancement Proposal - in either the FAQ or the PEP, it will stay in its initial form forever, since nobody but the original author will edit it (that could be true of a Wiki page as well, but on a Wiki page, people *know* they are meant to edit it if they want to say something) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
[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 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 z onward into the output buffer, and ignore the trailing inputs. The good news is that we could teach it about z (but would still need a macro or some such to implement z correctly across platforms). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re : [Python-checkins]r41940 - python/trunk/Lib/test/ test_compiler.py
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 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 information in trial's output, and can unmark the test. This avoids having to refactor test classes just to update the status of a test. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
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, not % Py_SIZE_T_WIDTH d That's too ugly, IMO. So I could accept to write %s() requires a code object with %ld free vars, not %ld, PyString_AsString(op-func_name), (long)nclosure, (long)nfree); instead. Alternatively, if there is a real chance that it overflows LONG_MAX (which there isn't, AFAIK - we don't support that many free vars), we could also write %s() requires a code object with %ld free vars, not %ld, PyString_AsString(op-func_name), Py_long_ceil(nclosure), Py_long_ceil(nfree)); with #define Py_long_ceil(n) ((n) LONG_MAX ? LONG_MAX : \ (n) LONG_MIN ? LONG_MIN : (n)) On most platforms, the compiler should notice that the conditions are both known false, and collaps this to (n). If this ever overflows, somebody will have to remember that this is really +/- infinity. Regards, Martin P.S. Proposals for a different macro name are thankfully accepted. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
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 z onward into the output buffer, and ignore the trailing inputs. The good news is that we could teach it about z (but would still need a macro or some such to implement z correctly across platforms). On VC7.1, we could use 'L', right? On other platforms, we could check whether sizeof(size_t) is sizeof(long), and use 'l', else we could refuse compilation (I doubt this would rule out any relevant system). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
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 information in trial's output, and can unmark the test. This avoids having to refactor test classes just to update the status of a test. So how is the mark added? I would suggest @xfail def test_foo(self): self.assertEquals(0,1) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
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 code is fixed and the test passes, you get that information in trial's output, and can unmark the test. This avoids having to refactor test classes just to update the status of a test. So how is the mark added? I would suggest @xfail def test_foo(self): self.assertEquals(0,1) def test_foo(self): self.assertEquals(0,1) test_foo.todo = Why this test fails description message. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_curses
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 single location. Why would a single Wiki page not be accessible in a single location? Why is the FAQ not accessible in a single location? Unless either of those would replace PEPs (or include all information from all PEPs), they would be a second location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Right. However, I doubt you would look in the rejected ideas PEP. You may have the luxury of that doubt, but I don't :) I'm sorry if my comments sounded hypothetical; they weren't. I did wonder about (among other things) 'x, y, *rest = l', and because I didn't know the name, I did browse the PEP list. A 'Rejected Ideas' PEP would've caught my eye even if I didn't have a hunch Guido would reject 'x, y, *r = l'. I agree that collecting them in a single place is a good idea. Whether this is a PEP, a Wiki page, or the FAQ is nearly irrelevant, except: - it is strange to call it a Python Enhancement Proposal They are proposals to enhance Python, though. That's exactly why I argue they should be in a PEP, not in some other location: it's all neatly bundled together. It's just not a PEP per single proposal. - in either the FAQ or the PEP, it will stay in its initial form forever, since nobody but the original author will edit it (that could be true of a Wiki page as well, but on a Wiki page, people *know* they are meant to edit it if they want to say something) I don't think the rejected-ideas collection should be publically editable either. It's not a discussion forum, it's not meant to get people to persuade Guido to change his mind, it's a list of these things just aren't going to happen, deal with it. A Meta-PEP like Tim suggested seems most appropriate to me, even if it isn't purely Meta; practicality beats purity and all that. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] locale and LC_NUMERIC
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. +1. I think it's rather patronizing to send things back to python-list when you know people are wasting their time discussing them because they will never be accepted. People on python-list have useful things to do too, they don't just read to waste their time. I would prefer PEP form over a wiki page, as I'd rather this be truly authoritative, and only Guido can really completely reject an idea. Justifying the rejections can be done by anyone though; maybe each idea could link to a wiki page on the topic. I think it's also important to be clear on what's being rejected. Often these rejected ideas address a real issue, and if you think about the issue from another angle you might be able to solve that without falling into the trap that the oft-rejected proposal fell into. But it's easy to confuse that the issue or use case is being explicitly ignored, rather than the particulars. For instance, Thomas said changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language -- and that's what shouldn't be in the PEP. All statements aren't going to be expressions; the 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 (and they have been *needlessly* alienated by discussions about lambda and filter). So... maybe Guido or python-dev should write/vet the justifications too. When you are putting up walls and specifically discouraging community participation on certain issues, it should be done in a sensitive way. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. +1. I think it's rather patronizing to send things back to python-list when you know people are wasting their time discussing them because they will never be accepted. Well, the problem is that most of these proposers think that their proposal deserve attention, is valuable no matter what, but python-dev is not the place to defuse/clarify that in a gentle way for the proposer. Of course some people do exactly that here out of kindness etc., I personally don't think it's a good approach. python-list is a better place to get clarifications about the way Python is, will stay. Half-baked, not well thought out ideas, as huge threads in the past going nowhere have proven, are not healthy to python-dev s/n ratio. Even with such a valuable PEP in place, I expect some people to need clarification discussions and python-list will still be the right place to have them. People on python-list have useful things to do too, they don't just read to waste their time. I would prefer PEP form over a wiki page, as I'd rather this be truly authoritative, and only Guido can really completely reject an idea. Justifying the rejections can be done by anyone though; maybe each idea could link to a wiki page on the topic. I think it's also important to be clear on what's being rejected. Often these rejected ideas address a real issue, and if you think about the issue from another angle you might be able to solve that without falling into the trap that the oft-rejected proposal fell into. But it's easy to confuse that the issue or use case is being explicitly ignored, rather than the particulars. For instance, Thomas said changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language -- and that's what shouldn't be in the PEP. All statements aren't going to be expressions; the 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 (and they have been *needlessly* alienated by discussions about lambda and filter). So... maybe Guido or python-dev should write/vet the justifications too. When you are putting up walls and specifically discouraging community participation on certain issues, it should be done in a sensitive way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] that library reference, again
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 python-dev should write/vet the justifications too. Oh, none of my examples were anything but that. Particularly the justification. These were just quick ramblings from my side; all actual pronouncements should be made channeling or being Guido, and the editorial review to ease sensitive minds is a group effort. (On the topic you quoted, though, I do feel that if people are using Python while they are waiting for Python to turn into a functional language, they're waiting for the wrong thing. Or at least, I hope so, or *I'm* waiting for the wrong thing. So I'm not sure what's wrong about the editorialization, but perhaps I'm just too insensitive towards functional programming disciples. And I'm usually quite in tune with sensitive minds. But we can discuss that off-list ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 too. Oh, none of my examples were anything but that. Particularly the justification. These were just quick ramblings from my side; all actual pronouncements should be made channeling or being Guido, and the editorial review to ease sensitive minds is a group effort. I was also just using your example as an example ;) As another similar example, around the discussions of the deprecation of map and filter I see a lot of misunderstandings. People confused the deprecation of two Lisp functions with Guido wanting to discourage functional program in general. The whole thing is based on several misconceptions, but the misunderstanding has become very widespread. A big part of what happened (I think) is that people who defended the decision added editorialization that became confused with the original intentions. And that consisted of things like functional programming is hard/confusing, so it's not appropriate in Python. I think putting these kinds of decisions on a wiki would generally lead to these kinds of confusions. When rejecting an idea altogether I think it should be clear exactly what is being rejected, and not imply that anything extra is being rejected. People read a lot I think there is a valid perception that the Python community is not very open to many ideas about changing the language. I think that's okay -- it's this way *because* of the participation and discussion that has occurred in the past, because these are old ideas that have been rejected and we are trying to move on. But it leaves people in an awkward situation, because how can you really know what is open for discussion? I don't think people on python-list really know this either, so asking there won't clarify that. I doubt there's general consensus on python-dev about what is open for change. 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 that python-dev is not willing to clarify itself. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 that python-dev is not willing to clarify itself. But now: who is going to write it? Guido should write it clearly won't work. And no, I'm explicitly not volunteering either. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
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 should always use the C locale. One should use locale.format to get locale-aware formatting. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 from writing great applications in Python, great libraries ... plus implementation work before they are left with the hard option that is language design to contribute to the community. Also I think it is unfair to use python-list to clarify things that python-dev is not willing to clarify itself. notice that the intersection is not empty yet. Also PEP 1 contains PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list@python.org and/or python-dev@python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, setting up a wiki page, etc. PEP authors should use their discretion here. in the past it often happened that water testing, honing for a PEP happend on python-list before any long discussion went on on python-dev. Basically I think that throwing half-cooked ideas at python-dev, especially for people with no track-record of language design contributions to Python, is just a recipe for frustration. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
[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, not % Py_SIZE_T_WIDTH d [Martin] That's too ugly, IMO. So I could accept to write %s() requires a code object with %ld free vars, not %ld, PyString_AsString(op-func_name), (long)nclosure, (long)nfree); instead. Alternatively, if there is a real chance that it overflows LONG_MAX (which there isn't, AFAIK - we don't support that many free vars), we could also write %s() requires a code object with %ld free vars, not %ld, PyString_AsString(op-func_name), Py_long_ceil(nclosure), Py_long_ceil(nfree)); with #define Py_long_ceil(n) ((n) LONG_MAX ? LONG_MAX : \ (n) LONG_MIN ? LONG_MIN : (n)) On most platforms, the compiler should notice that the conditions are both known false, and collaps this to (n). If this ever overflows, somebody will have to remember that this is really +/- infinity. I think you're trying to solve a different problem. I'm not trying to special-case the snot out of Neil's specific line of code, along the lines of well, yes, the types here were changed from int to Py_ssize_t, but that was basically bizarre since in fact plain old int was big enough to hold all plausible values to begin with, so let's find a way to pass Py_ssize_t arguments in cases where they're really ints or longs. If that's what's going on here, it's a symptom of changing type declarations with little thought just to shut up compiler warnings. If `int` or `long` are in fact big enough to hold all plausible values for these variables, then that's what they should be declared as. The problem I am trying to solve is formatting values that are of types size_t or Py_ssize_t for _good_ reason: in effect, they really need to be 64 bits on 64-bit boxes, and unsigned long/long aren't good enough for that on all 64-bit platforms. In these cases, using %ld is wrong, and truncating bits is also wrong. These cases need a platform-correct format code. The pain of separating out the width modifier could be reduced by defining a few type-oriented macros instead; e.g., #define PyFORMAT_ssize_t %zd /* on C99 boxes */ If it made sense to use Py_ssize_t to begin with in that code, then: %s() requires a code object with PyFORMAT_ssize_t free vars, not PyFORMAT_ssize_t, PyString_AsString(op-func_name), nclosure, free); 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
[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 on 64-bit boxes I means 8 bytes. On other platforms, we could check whether sizeof(size_t) is sizeof(long), and use 'l', else we could refuse compilation (I doubt this would rule out any relevant system). Assuming that's a lowercase letter el (I really can't see any difference between upper-eye and lower-el in gmail's font), I think that would be fine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
[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 weekend. I'll probably keep the actual list of rejected items to implicit self (which started the whole discussion), upgrading the Python parser beyond a simple LL(1), and maybe implicit ()'s for functioncalls, if I feel inspired. The exact wording, and additional rejects, can be discussed at length by those interested. I'll help with this. That means I want to and intend to, and will discover that I can't actually make any time for it. With two of us putting it off indefinitely, it should get done in half the time ;-). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
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. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
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 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 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 calling locale.setlocale(). Shouldn't we maintain the value from the env't? The problem I found is in Python/pythonrun.c. At least I think that's the problem. Around line 230-240 we call setlocale(NULL), then call setlocale(). Then later on we restore the locale by calling setlocale() with the return result from setlocale(NULL). The man page on my box (gentoo) says that passing NULL returns the current locale() while passing sets the locale from the env't variable. Should we just capture the results of setlocale()? If my understanding is wrong, how can I start python with the correct locale? It seems like that I'm confused since this problem hasn't seemed to come up before. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.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 part of C89 (IIRC). Should we use ptrdiff_t instead of Py_ssize_t? Formally, ptrdiff_t could be different from size_t (in width); reportedly, there are 8086 compilers which had a 16-bit size_t (maximum size of a segment), but a 32-bit ptrdiff_t (allowing for cross-segment differences, something that apparently became undefined in C99). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
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 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 calling locale.setlocale(). Shouldn't we maintain the value from the env't? the locale is a global program setting, and should only be activated when it's actually needed. my rationale for running the tests with a non-US locale was to increase the chance of catching bugs where the external locale setting affects Python's behaviour. maybe it would be a good idea to add a use setlocale flag to the test- runner ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
