Re: [Python-Dev] Packaging in Python 2 anyone ?
On Thu, Aug 18, 2011 at 5:17 AM, Fred Drake wrote: > On Wed, Aug 17, 2011 at 11:00 PM, Nick Coghlan wrote: >> It's actually for the same reason that unittest changes are backported >> under the unittest2 name - the distutils2 name can be used in the >> future to get Python 3.4 packaging features in Python 3.3, but that >> would be difficult if the backport shadowed the standard library name. > > Ah, yes... the old "too bad we stuck it in the standard library" problem. > > For some things, an easy lament, but for foundational packaging-related > things, it's hard to get around. Yeah exactly. And the good thing about packaging and distutils2 is that for the regular usage (package your project) you don't type any code, just define options in setup.cfg. IOW there's no "import packaging" or "import distutils2". Cheers Tarek > > > -Fred > > -- > Fred L. Drake, Jr. > "A person who won't read has no advantage over one who can't read." > --Samuel Langhorne Clemens > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ 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] Packaging in Python 2 anyone ?
On Thu, Aug 18, 2011 at 12:30 AM, Vinay Sajip wrote: ... > Okay, I had a bit of spare time today, and here's as far as I've got: Awesome, thanks a lot ! > > Step 1 - done. > Step 2 - done. > Step 3 - On Python 2.6 most of the tests pass: > > Ran 322 tests in 12.148s > > FAILED (failures=3, errors=4, skipped=39) > > See the detailed test results (for Linux) at https://gist.github.com/1152791 > > The code is at https://bitbucket.org/vinay.sajip/du2/ > > stdlib dependency code is either moved to util.py or test/support.py as > appropriate. You need to test in a virtualenv with unittest2 installed. No > work > has been done on packaging the project. > > I'm not sure if I'll have much more time to spend on this, but it's there in > case someone else can look at the remaining test failures, plus Steps 4 and 5; > hopefully I've broken the back of it :-) Thank you very much ! Ideally, if you could push this to hg.python.org/distutils2 (overwriting the existing stuff). Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Packaging in Python 2 anyone ?
Tarek Ziadé gmail.com> writes: > Ideally, if you could push this to hg.python.org/distutils2 > (overwriting the existing stuff). Okay, done. I've overwritten existing files and added new ones, only removing/renaming things like index -> pypi and mkcfg -> create. I haven't touched existing code e.g. the top-level test scripts or the _backport directory. The added test_distutils2.py is what I used to run the tests. Regards, Vinay Sajip ___ 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] Packaging in Python 2 anyone ?
On Thu, 18 Aug 2011 09:16:21 + (UTC) Vinay Sajip wrote: > Tarek Ziadé gmail.com> writes: > > > Ideally, if you could push this to hg.python.org/distutils2 > > (overwriting the existing stuff). > > Okay, done. I've overwritten existing files and added new ones, only > removing/renaming things like index -> pypi and mkcfg -> create. I haven't > touched existing code e.g. the top-level test scripts or the _backport > directory. The added test_distutils2.py is what I used to run the tests. Impressive work! That said, I'm not sure it was the best moment to backport, since test_packaging currently fails under Windows (I think Éric is supposed to look at it). Regards Antoine. ___ 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] Packaging in Python 2 anyone ?
On Thu, Aug 18, 2011 at 11:26 AM, Antoine Pitrou wrote: > On Thu, 18 Aug 2011 09:16:21 + (UTC) > Vinay Sajip wrote: >> Tarek Ziadé gmail.com> writes: >> >> > Ideally, if you could push this to hg.python.org/distutils2 >> > (overwriting the existing stuff). >> >> Okay, done. I've overwritten existing files and added new ones, only >> removing/renaming things like index -> pypi and mkcfg -> create. I haven't >> touched existing code e.g. the top-level test scripts or the _backport >> directory. The added test_distutils2.py is what I used to run the tests. > > Impressive work! > That said, I'm not sure it was the best moment to backport, since > test_packaging currently fails under Windows (I think Éric is supposed > to look at it). > Frankly, I think there's no best moment for this. We'll need to backport everything we do in packaging/ in distutils2/ (Yeah, painful...) > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ 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] Packaging in Python 2 anyone ?
On Thu, Aug 18, 2011 at 11:16 AM, Vinay Sajip wrote: > Tarek Ziadé gmail.com> writes: > >> Ideally, if you could push this to hg.python.org/distutils2 >> (overwriting the existing stuff). > > Okay, done. I've overwritten existing files and added new ones, only > removing/renaming things like index -> pypi and mkcfg -> create. I haven't > touched existing code e.g. the top-level test scripts or the _backport > directory. The added test_distutils2.py is what I used to run the tests. Thanks again > Regards, > > Vinay Sajip > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ 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
[Python-Dev] memoryview: "B", "c", "b" format specifiers
Hello,
during my work on PEP-3118 fixes I noticed that memoryview does not handle
the "B" format specifier according to the struct module documentation:
Here's what struct does:
>>> b = bytearray([1,2,3])
>>> struct.pack_into('B', b, 0, b'X')
Traceback (most recent call last):
File "", line 1, in
struct.error: required argument is not an integer
>>> struct.pack_into('c', b, 0, b'X')
>>> b
bytearray(b'X\x02\x03')
Here's what memoryview does:
>>> b = bytearray([1,2,3])
>>> m = memoryview(b)
>>> m.format
'B'
>>> m[0] = b'X'
>>> m[0] = 3
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' does not support the buffer interface
So, memoryview does exactly the opposite of what is specified. It should
reject the bytes object but accept the integer.
I would like to fix this in the features/pep-3118 repository as follows:
- memoryview should respect the format specifiers.
- bytearray and friends should set the format specifier to "c"
in their getbuffer() methods.
- Introduce a new function PyMemoryView_FromBytes() that can be used
instead of PyMemoryView_FromBuffer(). PyMemoryView_FromBuffer()
is usually used in conjunction with PyBuffer_FillInfo(), which
sets the format specifier to "B".
Are there any general objections to this?
Stefan Krah
___
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] Packaging in Python 2 anyone ?
Antoine Pitrou pitrou.net> writes: > That said, I'm not sure it was the best moment to backport, since > test_packaging currently fails under Windows (I think Éric is supposed > to look at it). Plus, there are at least half a dozen issues which would need to be addressed in packaging before final release, but they are not complete show-stoppers and won't preclude 2.x users giving useful feedback. Regards, Vinay Sajip ___ 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] memoryview: "B", "c", "b" format specifiers
On Thu, 18 Aug 2011 18:22:54 +0200 Stefan Krah wrote: > > So, memoryview does exactly the opposite of what is specified. It should > reject the bytes object but accept the integer. Well, memoryview is quite dumb right now. It ignores the format and just considers its underlying memory a bytes sequence. > I would like to fix this in the features/pep-3118 repository as follows: > > - memoryview should respect the format specifiers. > > - bytearray and friends should set the format specifier to "c" > in their getbuffer() methods. > > - Introduce a new function PyMemoryView_FromBytes() that can be used > instead of PyMemoryView_FromBuffer(). PyMemoryView_FromBuffer() > is usually used in conjunction with PyBuffer_FillInfo(), which > sets the format specifier to "B". What would PyMemoryView_FromBytes() do? The name suggests it takes a bytes object, but you can already use PyMemoryView_FromObject() for that. (I personnaly think the general bytes-as-sequence-of-ints behaviour is a mistake, so I wouldn't care much about an additional C API to enforce that behaviour :-)) Regards Antoine. ___ 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] memoryview: "B", "c", "b" format specifiers
Antoine Pitrou wrote: > > I would like to fix this in the features/pep-3118 repository as follows: > > > > - memoryview should respect the format specifiers. > > > > - bytearray and friends should set the format specifier to "c" > > in their getbuffer() methods. > > > > - Introduce a new function PyMemoryView_FromBytes() that can be used > > instead of PyMemoryView_FromBuffer(). PyMemoryView_FromBuffer() > > is usually used in conjunction with PyBuffer_FillInfo(), which > > sets the format specifier to "B". > > What would PyMemoryView_FromBytes() do? The name suggests it takes a > bytes object, but you can already use PyMemoryView_FromObject() for > that. Oh no, the name isn't quite right then. It should be a replacement for the combination PyBuffer_FillInfo()/PyMemoryView_FromBuffer() and it should temporarily wrap a C-string. Also, unlike that combination, it would set the format specifier to "c". Perhaps this name is better: PyObject * PyMemoryView_FromCString(char *s, Py_ssize_t size, int flags); 'flags' is just PyBUF_READ or PyBUF_WRITE. In the Python source tree, it could completely replace PyBuffer_FillInfo() and PyMemoryView_FromBuffer(). Stefan Krah ___ 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
[Python-Dev] PyPy 1.6 released
PyPy 1.6 - kickass panda
We're pleased to announce the 1.6 release of PyPy. This release brings a lot
of bugfixes and performance improvements over 1.5, and improves support for
Windows 32bit and OS X 64bit. This version fully implements Python 2.7.1 and
has beta level support for loading CPython C extensions. You can download it
here:
http://pypy.org/download.html
What is PyPy?
=
PyPy is a very compliant Python interpreter, almost a drop-in replacement for
CPython 2.7.1. It's fast (`pypy 1.5 and cpython 2.6.2`_ performance comparison)
due to its integrated tracing JIT compiler.
This release supports x86 machines running Linux 32/64 or Mac OS X. Windows 32
is beta (it roughly works but a lot of small issues have not been fixed so
far). Windows 64 is not yet supported.
The main topics of this release are speed and stability: on average on
our benchmark suite, PyPy 1.6 is between **20% and 30%** faster than PyPy 1.5,
which was already much faster than CPython on our set of benchmarks.
The speed improvements have been made possible by optimizing many of the
layers which compose PyPy. In particular, we improved: the Garbage Collector,
the JIT warmup time, the optimizations performed by the JIT, the quality of
the generated machine code and the implementation of our Python interpreter.
.. _`pypy 1.5 and cpython 2.6.2`: http://speed.pypy.org
Highlights
==
* Numerous performance improvements, overall giving considerable speedups:
- better GC behavior when dealing with very large objects and arrays
- **fast ctypes:** now calls to ctypes functions are seen and optimized
by the JIT, and they are up to 60 times faster than PyPy 1.5 and 10 times
faster than CPython
- improved generators(1): simple generators now are inlined into the caller
loop, making performance up to 3.5 times faster than PyPy 1.5.
- improved generators(2): thanks to other optimizations, even generators
that are not inlined are between 10% and 20% faster than PyPy 1.5.
- faster warmup time for the JIT
- JIT support for single floats (e.g., for ``array('f')``)
- optimized dictionaries: the internal representation of dictionaries is now
dynamically selected depending on the type of stored objects, resulting in
faster code and smaller memory footprint. For example, dictionaries whose
keys are all strings, or all integers. Other dictionaries are also smaller
due to bugfixes.
* JitViewer: this is the first official release which includes the JitViewer,
a web-based tool which helps you to see which parts of your Python code have
been compiled by the JIT, down until the assembler. The `jitviewer`_ 0.1 has
already been release and works well with PyPy 1.6.
* The CPython extension module API has been improved and now supports many
more extensions. For information on which one are supported, please refer to
our `compatibility wiki`_.
* Multibyte encoding support: this was of of the last areas in which we were
still behind CPython, but now we fully support them.
* Preliminary support for NumPy: this release includes a preview of a very
fast NumPy module integrated with the PyPy JIT. Unfortunately, this does
not mean that you can expect to take an existing NumPy program and run it on
PyPy, because the module is still unfinished and supports only some of the
numpy API. However, barring some details, what works should be
blazingly fast :-)
* Bugfixes: since the 1.5 release we fixed 53 bugs in our `bug tracker`_, not
counting the numerous bugs that were found and reported through other
channels than the bug tracker.
Cheers,
Hakan Ardo, Carl Friedrich Bolz, Laura Creighton, Antonio Cuni,
Maciej Fijalkowski, Amaury Forgeot d'Arc, Alex Gaynor,
Armin Rigo and the PyPy team
.. _`jitviewer`:
http://morepypy.blogspot.com/2011/08/visualization-of-jitted-code.html
.. _`bug tracker`: https://bugs.pypy.org
.. _`compatibility wiki`: https://bitbucket.org/pypy/compatibility/wiki/Home
___
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] Packaging in Python 2 anyone ?
Le 18/08/2011 18:19, Vinay Sajip a écrit : > Antoine Pitrou pitrou.net> writes: >> That said, I'm not sure it was the best moment to backport, since >> test_packaging currently fails under Windows (I think Éric is supposed >> to look at it). I will; any help is welcome, especially if you have a machine with the same Windows version (see #12678). I caught Georg’s message on python-committers but could not do anything in time; I only have Internet access at a public library so I can’t be as responsive as I would. > Plus, there are at least half a dozen issues which would need to be addressed > in > packaging before final release, but they are not complete show-stoppers and > won't preclude 2.x users giving useful feedback. Yes, there are a few dozen bugs that need addressing before 1.0 (i.e. Python 3.3), but there’s time. Alpha and beta releases of distutils2 would be useful. 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] cpython (3.2): NUL -> NULL
On Thu, 18 Aug 2011 17:49:28 +0200 benjamin.peterson wrote: > -PyErr_SetString(PyExc_TypeError, "embedded NUL character"); > +PyErr_SetString(PyExc_TypeError, "embedded NULL character"); Are you sure? IIRC, NUL is the little name of ASCII character 0 (while NULL would be the NULL pointer). Regards Antoine. ___ 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] cpython (3.2): NUL -> NULL
On 08/18/2011 02:19 PM, Antoine Pitrou wrote: > On Thu, 18 Aug 2011 17:49:28 +0200 > benjamin.peterson wrote: >> -PyErr_SetString(PyExc_TypeError, "embedded NUL character"); >> +PyErr_SetString(PyExc_TypeError, "embedded NULL character"); > > Are you sure? IIRC, NUL is the little name of ASCII character 0 > (while NULL would be the NULL pointer). That's my understanding, too. Eric. ___ 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] Packaging in Python 2 anyone ?
Hi Tarek, > Doing an automated conversion turned out to be a nightmare, and I was > about to go ahead and maintain a fork of the packaging package, with > the few modules that are needed (sysconfig, etc) within a standalone > release. Can you give us more info? Do you have a repo somewhere, or notes? A related question: what is the minimum 2.x version that we should support? 2.6 would be a dream, thanks to bytes literal and all that, but I’m sure it’s not realistic; 2.5 would be nice for the with statement and hashlib, otherwise 2.4 is okay. When I talked with Łukasz in private email about backports and 3to2, we agreed that there were some serious bugs in 3to2 and we wanted to work on patches. I also wanted to make the command-line driver more flexible, so that it would be easy to run a command to apply only 3.3→3.2 fixes, then another for 3.2→2.7, etc. Maybe your problems were caused by the state of the packaging codebase. The conversion to 3.x was a little messy: in some cases there were parallel code branches for 2.x and 3.x, on other cases 2to3 was run, and in many cases the conversion had to be cleaned up (esp. bytes/str madness). Even now that the code runs and the tests pass, there may still be things in need of a cleanup in the codebase, and maybe they trip up 3to2. > I am looking for someone that has some free time and that is willing > to lead this work. Well, free time is scarce with all these distutils bugs on my plate, but I am definitely interested in heading the backport, as I stated earlier. I think the key point is to avoid making the same work over and over again, and I see a few ways of managing that. The first way is to start with a 2.x-converted codebase (thanks Vinay!) and manually port all cpython/packaging changesets to distutils2, like I used to do. This is just as annoying as backporting to 2.7, and just as simple. The second way is to work on a conversion tool instead of working on changesets. The idea is to make a robust tool based on 3to2 that copies code and converts it. This would not be the easiest way, as shown by your experience, but surely the less cumbersome in the long term. The third way is to use a new Mercurial repo converted from the cpython repo, so that we can run “hg convert” again to pull new changesets. Convert, test and commit. The advantage is that it’s not required to port each changeset: the convert-merge dance can be done once a month, or just for new releases. The fourth way is hybrid: start from a 2.x-converted codebase, and each month, make a diff for cpython/Lib/packaging and apply to distutils2. I fear that such diffs would be painful to apply, and consist mostly of rejects. With idea #3, we get to use a merge tool, which is much better. After writing out these ideas, I think the first one is certainly the simplest thing that could work with minimum pain. Le 18/08/2011 00:30, Vinay Sajip a écrit : > stdlib dependency code is either moved to util.py or test/support.py as > appropriate. We need sysconfig, shutil, tarfile, hashlib... Surely that’s a lot to put in util.py. > I'm not sure if I'll have much more time to spend on this, but it's there in > case someone else can look at the remaining test failures, plus Steps 4 and 5; > hopefully I've broken the back of it :-) I join my thanks to Tarek’s, and volunteer to follow on :) 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] cpython (3.2): NUL -> NULL
2011/8/18 Antoine Pitrou : > On Thu, 18 Aug 2011 17:49:28 +0200 > benjamin.peterson wrote: >> - PyErr_SetString(PyExc_TypeError, "embedded NUL character"); >> + PyErr_SetString(PyExc_TypeError, "embedded NULL character"); > > Are you sure? IIRC, NUL is the little name of ASCII character 0 > (while NULL would be the NULL pointer). NUL is the abbreviation of the "Null character". -- 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] cpython (3.2): NUL -> NULL
Antoine Pitrou wrote: > On Thu, 18 Aug 2011 17:49:28 +0200 > benjamin.peterson wrote: > > -PyErr_SetString(PyExc_TypeError, "embedded NUL character"); > > +PyErr_SetString(PyExc_TypeError, "embedded NULL character"); > > Are you sure? IIRC, NUL is the little name of ASCII character 0 > (while NULL would be the NULL pointer). Yes, that's the traditional name. I was surprised that the C99 standard uses "null character" in almost all cases. Example: "The construction '\0' is commonly used to represent the null character." So I think it should be either NUL or "null character" with the lower case spelling. Stefan Krah ___ 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] Packaging in Python 2 anyone ?
On Thu, Aug 18, 2011 at 8:27 PM, Éric Araujo wrote: > Hi Tarek, > >> Doing an automated conversion turned out to be a nightmare, and I was >> about to go ahead and maintain a fork of the packaging package, with >> the few modules that are needed (sysconfig, etc) within a standalone >> release. > > Can you give us more info? Do you have a repo somewhere, or notes? I tried using relative imports, but that made the whole thing complicated and not working under older 2.x then there are a lot of spots where the word 'packaging' is used for other things than modules. then there are spots when we needed to change the bytes/str behavior depending on the py version, making everything complex to maintain I guess it's the addition of the three that made it too complex : transparent renaming + 3to2 + 3.xto3.x > > A related question: what is the minimum 2.x version that we should > support? 2.6 would be a dream, thanks to bytes literal and all that, > but I’m sure it’s not realistic; 2.5 would be nice for the with > statement and hashlib, otherwise 2.4 is okay. 2.5 sounds good. I am sold on dropping 2.4 frankly. Maybe we can drop 2.5 in a few months ;) > > When I talked with Łukasz in private email about backports and 3to2, we > agreed that there were some serious bugs in 3to2 and we wanted to work > on patches. I also wanted to make the command-line driver more > flexible, so that it would be easy to run a command to apply only > 3.3→3.2 fixes, then another for 3.2→2.7, etc. > > Maybe your problems were caused by the state of the packaging codebase. > The conversion to 3.x was a little messy: in some cases there were > parallel code branches for 2.x and 3.x, on other cases 2to3 was run, and > in many cases the conversion had to be cleaned up (esp. bytes/str > madness). Even now that the code runs and the tests pass, there may > still be things in need of a cleanup in the codebase, and maybe they > trip up 3to2. I think that's not worth the effort frankly. keeping a clean fully py3 code without worrying about making it 3to2 friendly, make all contributors life easier ihmo. The tradeoff is that we will have to backport to distutils2 changes. That's what was done for a while between the Python trunk and the Py3k branch, so I guess it's doable -- if all packaging contributors agree to do this backport work. > >> I am looking for someone that has some free time and that is willing >> to lead this work. > > Well, free time is scarce with all these distutils bugs on my plate, but > I am definitely interested in heading the backport, as I stated earlier. > I think the key point is to avoid making the same work over and over > again, and I see a few ways of managing that. > > The first way is to start with a 2.x-converted codebase (thanks Vinay!) > and manually port all cpython/packaging changesets to distutils2, like I > used to do. This is just as annoying as backporting to 2.7, and just as > simple. > > The second way is to work on a conversion tool instead of working on > changesets. The idea is to make a robust tool based on 3to2 that copies > code and converts it. This would not be the easiest way, as shown by > your experience, but surely the less cumbersome in the long term. > > The third way is to use a new Mercurial repo converted from the cpython > repo, so that we can run “hg convert” again to pull new changesets. > Convert, test and commit. The advantage is that it’s not required to > port each changeset: the convert-merge dance can be done once a month, > or just for new releases. > > The fourth way is hybrid: start from a 2.x-converted codebase, and each > month, make a diff for cpython/Lib/packaging and apply to distutils2. I > fear that such diffs would be painful to apply, and consist mostly of > rejects. With idea #3, we get to use a merge tool, which is much better. > > After writing out these ideas, I think the first one is certainly the > simplest thing that could work with minimum pain. I think so too. The automatic conversion sounded like a great thing, but the nature of the project makes it too hard, Cheers -- Tarek Ziadé | http://ziade.org ___ 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] memoryview: "B", "c", "b" format specifiers
Antoine Pitrou wrote: > (I personnaly think the general bytes-as-sequence-of-ints behaviour is > a mistake, so I wouldn't care much about an additional C API to enforce > that behaviour :-)) I don't want to abolish the "c" (bytes of length 1) format. :) I think there are use cases for well defined arrays of small signed/unsigned integers. Say you want to send a log-ngram array of unsigned chars over the network. There shouldn't be a bytes object involved in that process. You would pack the array with ints and unpack as ints. Unless the struct module and PEP-3118 grow support for int8_t and uint8_t, I think "b" and "B" should probably be restricted to integers. Stefan Krah ___ 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] memoryview: "B", "c", "b" format specifiers
On Thu, 18 Aug 2011 18:57:00 +0200 Stefan Krah wrote: > > Oh no, the name isn't quite right then. It should be a replacement > for the combination PyBuffer_FillInfo()/PyMemoryView_FromBuffer() > and it should temporarily wrap a C-string. Ah, nice. > PyObject * PyMemoryView_FromCString(char *s, Py_ssize_t size, int flags); It's not really a C string, since it's not null-terminated. PyMemoryView_FromMemory? (that would mirror PyUnicode_FromUnicode, for example) > 'flags' is just PyBUF_READ or PyBUF_WRITE. Why do we have these in addition to PyBUF_WRITABLE already? Regards Antoine. ___ 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] Packaging in Python 2 anyone ?
Éric Araujo netwok.org> writes: > Le 18/08/2011 00:30, Vinay Sajip a écrit : > > stdlib dependency code is either moved to util.py or test/support.py as > > appropriate. > We need sysconfig, shutil, tarfile, hashlib... Surely that’s a lot to > put in util.py. Well sysconfig.py/sysconfig.cfg have been copied as is. I've only copied over specific things we need from shutil/functools/os, etc. so far to util.py. I haven't looked at 2.4/2.5 support yet: things like hashlib would probably need to be treated the same way Django handles this sort of backport of functionality. > I join my thanks to Tarek’s, and volunteer to follow on :) That's good news :-) Regards, Vinay Sajip ___ 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] memoryview: "B", "c", "b" format specifiers
Antoine Pitrou wrote: > On Thu, 18 Aug 2011 18:57:00 +0200 > Stefan Krah wrote: > > > > Oh no, the name isn't quite right then. It should be a replacement > > for the combination PyBuffer_FillInfo()/PyMemoryView_FromBuffer() > > and it should temporarily wrap a C-string. > > Ah, nice. > > > PyObject * PyMemoryView_FromCString(char *s, Py_ssize_t size, int flags); > > It's not really a C string, since it's not null-terminated. > PyMemoryView_FromMemory? > > (that would mirror PyUnicode_FromUnicode, for example) I see, yes. PyMemoryView_FromStringAndSize()? No, too much typing. I prefer PyMemoryView_FromMemory(). > > 'flags' is just PyBUF_READ or PyBUF_WRITE. > > Why do we have these in addition to PyBUF_WRITABLE already? That's a bit involved, this is how I see it: There are four buffer *request* flags that can be sent to a buffer provider and that indicate the amount of complexity that a consumer can handle (in decreasing order): PyBUF_INDIRECT -> suboffsets (PIL-style) PyBUF_STRIDES -> strides (Numpy-style) PyBUF_ND-> C-contiguous, but possibly multi-dimensional PyBUF_SIMPLE-> contiguous, one-dimensional, unsigned bytes Each of those flags can be mixed freely with two additional flags: PyBUF_WRITABLE PyBUF_FORMAT All other buffer request flags are simply combinations of those. For example, if you use PyBUF_WRITABLE as the only flag, logically it should be seen as PyBUF_WRITABLE|PyBUF_SIMPLE (this works since PyBUF_SIMPLE is defined as 0). PyBUF_READ and PyBUF_WRITE are so far only used for PyMemoryView_GetContiguous(). The PEP still has a flag named PyBUF_UPDATEIFCOPY, but that didn't make it into object.h. I thought it might be appropriate to use PyBUF_READ and PyBUF_WRITE to underline the fact that you cannot send a fine grained buffer request to PyMemoryView_FromMemory()[1]. Also, PyBUF_READ is easier to understand than PyBUF_SIMPLE. But I'd be equally happy with PyBUF_SIMPLE/PyBUF_WRITABLE. Stefan Krah [1] The terminology might sound funny, but there is a function that can act a micro buffer provider: int PyBuffer_FillInfo(Py_buffer *view, PyObject *obj, void *buf, Py_ssize_t len, int readonly, int infoflags) An exporter can use this function as a building block for a getbuffer() method for unsigned bytes, since it reacts correctly to *all* possible buffer requests in 'infoflags'. ___ 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] cpython (3.2): NUL -> NULL
On Fri, Aug 19, 2011 at 4:51 AM, Stefan Krah wrote: > So I think it should be either NUL or "null character" with the lower > case spelling. +1 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
