Re: [Python-Dev] [Python-checkins] r84619 - python/branches/py3k/Misc/developers.txt
>> I think that people whose alphabet is for example Cyrillic already use a >> Latin transliteration in those files, so it’s good. > At present, such people have no choice ;-). Right :) So the new policy of real name thanks to UTF-8 + ASCII transliteration is a superset of the existing conditions, which should be fine with everyone (i.e. names can finally be written with whatever characters they require, and people in the old world can read it with non-UTF 8-capable tools). >> Are you also including names using extended Latin alphabets (like >> Łukasz) in your suggestion? > No. Then it’s fine. Thanks for the feedback. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84727 - in python/branches/py3k: Lib/collections.py Misc/NEWS
On Sun, 12 Sep 2010 06:12:42 +0200 (CEST) raymond.hettinger wrote: > > -# Each link is stored as a list of length three: [PREV, NEXT, KEY]. > +# The back links are weakref proxies (to prevent circular references). Are you sure this prevents anything? Since your list is circular, forward links are enough to build a reference cycle. Actually, this is exemplified here: > +self.__root = root = _Link()# sentinel node for the doubly > linked list > +root.prev = root.next = root `root.next = root` is enough to create a cycle, even if you make root.prev a weakref. What you need is to make both prev and next weakrefs. All list nodes all held by the __map dict anyway. If you are bothered about speed, an alternative would be a classic finalization scheme, using a class-wide set of OrderedDict weakrefs that remove themselves and clean up the doubly-linked list when the OrderedDict becomes dead. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
Am 07.09.2010 19:46, schrieb M.-A. Lemburg: > "Martin v. Löwis" wrote: >>> -1 on always using wchar_t as well. Python's default is UCS2 and the >>> stable ABI should not change that. >> >> It's not really Python's default. It is what configure.in does by >> default. Python's default, on Linux, is UCS-4. > > No, the default is UCS2 on all platforms and in configure.in. > > configure.in only uses UCS4 if it finds a TCL installation that > happens to use UCS4 - for some reason I don't know :-) > > However, most Linux distros and more recently also some BSDs > have switched over to using UCS4 for their distribution versions > of Python. Hmm. So UCS4 *is* the default for Linux. The default on the system is not what Python's configure makes it, but what the system vendors make it - they are the ones making the system, after all. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
> I only mandated ./configure-based builds to be PEP 3149 conforming. I have no > objection to expanding the PEP to include Windows builds, but I'm not sure > it's necessary and it would take a Windows build expert to make and test those > changes. > > Does PEP 3149 have any advantage for Windows installations? I think this is resolved by now, responding anyway: I don't see any immediate advantage. The problem that the PEP addresses typically doesn't exist on Windows. >> 2. Why does the PEP recommend installing stuff >> into /usr/share/pyshared? > > It's just a suggestion, but as it turns out, probably an incorrect one. I'll > rephrase this to make it clear that it's up to the distribution as to where > exactly these files get installed. Nothing about this PEP changes the default > from-source installation directory. Is the rephrasing done already? I still wonder why you suggest /usr/share should be used, when the FHS says it should be /usr/lib. This keeps confusing me, despite not being part of the specification. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
Am 07.09.2010 19:48, schrieb M.-A. Lemburg: > "Martin v. Löwis" wrote: >> >>> This sounds like the issues such a mix can cause are mostly >>> theoretical and don't really bother much in practice, so >>> PEP 384 on Windows does have a chance :-) >> >> Actually, the CRT issues (FILE* in particular) have been >> causing real crashes for many years, for many people. > > Do you have some pointers ? You mean, other than FILE* :-? Unfortunately, I don't have time to search for reports, but they had been several on comp.lang.python over the years. As others say, this is *really* easy to reproduce. > I don't remember this being a real practical issue, at least > not for different versions of the MS CRTs. You probably had not been passing FILE* across CRT boundaries, then. Notice that this is an uncommon thing to do, except that the Python API has some functions that expect FILE*. As others have mentioned, CRT file handles are a problem, too, but less so: a) they aren't explicitly passed in any of the Python APIs (except for the obvious os.* functions), b) they don't cause crashes, just outputs to the wrong files, and c) if they are 0/1/2, they actually do the right thing. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 9/7/2010 10:15 AM, Michael Foord wrote: > On 07/09/2010 15:02, [email protected] wrote: >> On 01:33 pm, [email protected] wrote: >>> Hello. Thank you for the offer! >>> >>> On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote: My name is Prashant Kumar and I wish to contribute to the Python development process by helping convert certain existing python over to python3k. Is there anyway I could obtain a list of libraries which need to be ported over to python3k, sorted by importance(by importance i mean packages which serve as a dependency for larger number of packages being more important). >>> >>> As there is already Python 3.2 alpha, the core of Python has already >>> been ported - and this mailing list is for discussion of development >>> of the >>> very Python, not about working on 3rd-party libraries. >> >> How about the email package? > > Right, and there are other standard library modules (cgi, ftplib, > nntplib, etc) that either need fixing or auditing as to how they handle > bytes / strings. > Including, to my certain knowledge, the mailbox handling code, though writing code to read them sequentially is fairly easy. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84744 - python/branches/py3k/Objects/unicodeobject.c
Victor changed this from "return NULL" to "goto fail" in r84730, claiming that it would fix a reference leak. Is the leak somewhere else then? Georg Am 12.09.2010 18:40, schrieb benjamin.peterson: > Author: benjamin.peterson > Date: Sun Sep 12 18:40:53 2010 > New Revision: 84744 > > Log: > use return NULL; it's just as correct > > Modified: >python/branches/py3k/Objects/unicodeobject.c > > Modified: python/branches/py3k/Objects/unicodeobject.c > == > --- python/branches/py3k/Objects/unicodeobject.c (original) > +++ python/branches/py3k/Objects/unicodeobject.c Sun Sep 12 18:40:53 2010 > @@ -769,7 +769,7 @@ > "PyUnicode_FromFormatV() expects an ASCII-encoded format " > "string, got a non-ASCII byte: 0x%02x", > (unsigned char)*f); > - goto fail; > + return NULL; > } > } > /* step 2: allocate memory for the results of -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
> If it's useful on unix like systems, why shouldn't it be useful on > windows? Multiple versions of python can be installed on windows > too. And people might also like to share their packages between > installations. Multiple versions of Python install into distinct directories, so extension modules don't conflict. There is currently no provision for a central directory where Python packages get installed on Windows across Python versions, so the main motivation for the PEP doesn't exist. The secondary motivation, to have both debug and non-debug versions of an extension module in the same folder, is already provided by the _d.pyd mechanism on Windows (which was introduced before the PEP process was established). Of course, somebody could come along and propose that extension modules should install into "\Program Files\Common\Python3" (say), and that Python versions starting from 3.3 (or so) should include that directory in their search path by default. IMO, that would be a separate PEP, and I would hope that *if* such a location is established, the PEP 3149 motivation is not relevant anymore, since extension modules installed into such a location might use the stable ABI, anyway. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84744 - python/branches/py3k/Objects/unicodeobject.c
2010/9/12 Georg Brandl : > Victor changed this from "return NULL" to "goto fail" in r84730, claiming > that it would fix a reference leak. Is the leak somewhere else then? Indeed. He missed my earlier fix, though. :) -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
> On http://bugs.python.org/issue9778 you elaborated on what the PEP would > entail in its current state: > > “No, vice versa. The PEP promises that the ABI won't change until > Python 4. For any change that might break the ABI, either a > backwards-compatible solution needs to be found, or the change be > deferred to Python 4.” > > This sounds like it could be detrimental by blocking desired > improvements (the aforementioned issue is a potential example of this). Notice that it's only potential: in the specific case, there would be an ABI-compatible way of introducing wide hashes, using a second type slot. > Do you think it would complicate things a lot to version the ABI itself? It would miss the point. The ABI deliberately restricts itself to features that really have been stable, and we should be committed to keeping that subset stable. If you think this is too restrictive, please point out specific aspects that you think might need to change in the mid-term future. They should then be excluded from the ABI. > Actually, PYTHON_API_VERSION is already used as some kind of ABI tag > (since it's checked at module load time rather than at compile time). It's too late, though: when the module is being created, the code using the ABI is already running. As I wrote in the issue: the *real* ABI version is "python3.dll". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
On Sun, 12 Sep 2010 19:38:33 +0200 "Martin v. Löwis" wrote: > > On http://bugs.python.org/issue9778 you elaborated on what the PEP would > > entail in its current state: > > > > “No, vice versa. The PEP promises that the ABI won't change until > > Python 4. For any change that might break the ABI, either a > > backwards-compatible solution needs to be found, or the change be > > deferred to Python 4.” > > > > This sounds like it could be detrimental by blocking desired > > improvements (the aforementioned issue is a potential example of this). > > Notice that it's only potential: in the specific case, there would be > an ABI-compatible way of introducing wide hashes, using a second type > slot. Yes, but it would add complication, and be potentially detrimental to performance. > If you think this is too restrictive, please point out specific aspects > that you think might need to change in the mid-term future. They should > then be excluded from the ABI. I have no a priori knowledge of what might happen in the future :) That said, looking at the PEP, I was wondering whether fields such as ob_type, ob_refcnt, ob_size have to be directly accessible, rather than through a macro-turned-into-a-function such as Py_REFCNT(). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer help with porting
On 9/7/2010 11:37 AM, R. David Murray wrote: > On Tue, 07 Sep 2010 18:34:49 +0400, Oleg Broytman wrote: >> On Tue, Sep 07, 2010 at 02:02:59PM -, [email protected] wrote: >>> On 01:33 pm, [email protected] wrote: As there is already Python 3.2 alpha, the core of Python has already been ported >>> >>> How about the email package? >> >>What about email? It is a core library, right? It has been ported AFAIK. >> Or have I missed something? > > Some bug reports, perhaps? > > Email has been "ported" in the sense that all the existing tests pass > under py3k. It is not, however, fully functional: it cannot handle > input that contains binary data with the high bit set. (To put it another > way, the python3 email package currently handles only 7bit clean data.) > This has various unfortunate consequences for other standard library > packages (cgi, nntp, etc) that depend directly or indirectly on the > email package. > > To fix this the email package API and a chunk of the internals needs > to be redesigned so that it can handle bytes while still providing a > string-based interface to the textual data. This is no small task, > since email in python2 has been getting away with all kinds of dirty > tricks because of the lack of a clean bytes/string separation in python2. > > See http://launchpad.net/python-email6 for current status of the project. > > Prashant Kumar, if you would like to help with the email6 project, please > sign up to the email-sig mailing list and introduce yourself there. > All help is welcome! It is not a "porting" project strictly > speaking, but it certainly is interesting :) > And if anyone knows people who would help with *funding* this effort the PSF very much wants to talk to them. This ought logically to include everyone using "Mailman". I would imagine if we had $10 from 1% of its users we would be able to fund the effort comfortably. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
> That said, looking at the PEP, I was wondering whether fields such as > ob_type, ob_refcnt, ob_size have to be directly accessible, rather than > through a macro-turned-into-a-function such as Py_REFCNT(). That they are macros still is primarily for performance reasons. For ob_type, that may be questionable; for Py_INCREF, I hope you agree that it's really desirable for it to be inline. However, more importantly, user-defined objects need to start with the standard object header. I really see no way to let extensions define types without them also being able to access their own struct fields, which in turn requires compile-time (ABI) knowledge of PyObject_HEAD. This is also the reason why Py_TRACE_REFS can't be supported in the ABI: it increases sizeof(PyObject), and thus shifts all user fields in the object. I actually *do* have a priori knowledge of what might happen in the future :-): If we were to change the layout of the object header in a significant way, then the majority of extension modules would break - not only on the binary level, but also on the source level. So any change to this likely justifies calling it Python 4. (I would be that even Python 4 keeps that structure) Regards, Martin ___ Python-Dev mailing list [email protected] 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] r84743 - in python/branches/py3k: Doc/license.rst Misc/NEWS Modules/expat/COPYING
+zlib + + +The :mod:`zlib` extension is built using an included copy of the zlib +sources unless the zlib version found on the system is too old to be +used for the build:: Unless or if? Building with an included copy *if* the system one is too old makes sense to me, not the contrary. Am I not seeing something? Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
