On Aug 26, 2011, at 8:51 PM, Terry Reedy wrote:
On 8/26/2011 8:42 PM, Guido van Rossum wrote:
On Fri, Aug 26, 2011 at 3:57 PM, Terry Reedytjre...@udel.edu wrote:
My impression is that a UFT-16 implementation, to be properly called such,
must do len and [] in terms of code points,
On Fri, Aug 26, 2011 at 8:47 PM, Steven D'Aprano st...@pearwood.infowrote:
Antoine Pitrou wrote:
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg drsali...@gmail.com wrote:
If you add regex as import regex, and the new regex module doesn't work
out, regex might be harder to get rid of.
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's worth. It's really bad if only one developer fully
understands the regex implementation.
Regards,
Martin
On 8/26/2011 8:23 PM, Antoine Pitrou wrote:
I would only agree as long as it wasn't too much worse
than O(1). O(log n) might be all right, but O(n) would be
unacceptable, I think.
It also depends a lot on *actual* measured performance
Amen. Some regard O(n*n) sorts to be, by definition,
I can't either, but ISTR hearing that from __future__ import was started
with such an intent.
No, not at all. The original intention was to enable features that would
definitely would be added, not just right now. Tim Peters always
objected to claims that future imports were talking about
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
Will the re module need porting also?
--
Terry Jan Reedy
___
Python-Dev mailing list
Am 27.08.2011 08:33, schrieb Terry Reedy:
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
Will the re module need porting also?
That's a quality-of-implementation issue (in
Terry Reedy wrote:
On 8/26/2011 8:23 PM, Antoine Pitrou wrote:
I would only agree as long as it wasn't too much worse
than O(1). O(log n) might be all right, but O(n) would be
unacceptable, I think.
It also depends a lot on *actual* measured performance
Amen. Some regard O(n*n) sorts to
Am 27.08.2011 09:40, schrieb Steven D'Aprano:
Terry Reedy wrote:
On 8/26/2011 8:23 PM, Antoine Pitrou wrote:
I would only agree as long as it wasn't too much worse
than O(1). O(log n) might be all right, but O(n) would be
unacceptable, I think.
It also depends a lot on *actual* measured
On Sat, Aug 27, 2011 at 4:01 PM, Dan Stromberg drsali...@gmail.com wrote:
You're talking technically, which is important, but wasn't what I was
suggesting would be helped.
Politically, and from a marketing standpoint, it's easier to withdraw a
feature you've given with a Play with this, see
On 26 Aug 2011, at 16:53, Antoine Pitrou wrote:
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it uses internally to manage queues, etc. Removing that
ability would require a
On Sat, 27 Aug 2011 09:18:14 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
Am 27.08.2011 08:33, schrieb Terry Reedy:
On 8/26/2011 9:56 PM, Antoine Pitrou wrote:
Another interesting question is whether it's easy to port to the PEP
393 string representation, if it gets accepted.
On Sat, 27 Aug 2011 08:02:31 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's worth. It's really bad if only one developer
Hi all,
About multithreading models: I recently made an observation which
might be obvious to some, but not to me, and as far as I know not to
most of us either. I think that it's worth being pointed out :-)
http://mail.python.org/pipermail/pypy-dev/2011-August/008153.html
A bientôt,
Armin.
On 26 Aug, 09:45 pm, gu...@python.org wrote:
I just made a pass of all the Unicode-related bugs filed by Tom
Christiansen, and found that in several, the response was this is
fixed in the regex module [by Matthew Barnett]. I started replying
that I thought that we should fix the bugs in the re
On Sat, Aug 27, 2011 at 8:45 PM, Armin Rigo ar...@tunes.org wrote:
Hi all,
About multithreading models: I recently made an observation which
might be obvious to some, but not to me, and as far as I know not to
most of us either. I think that it's worth being pointed out :-)
Hi Nick,
On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan ncogh...@gmail.com wrote:
1. How does the patch interact with C code that explicitly releases
the GIL? (e.g. IO commands inside a with atomic: block)
As implemented, any code in a with atomic is prevented from
explicitly releasing and
Hello all,
I'd like to propose the addition of a new module in Python 3.3. The 'lzma'
module will provide support for compression and decompression using the LZMA
algorithm, and the .xz and .lzma file formats. The matter has already been
discussed on the tracker http://bugs.python.org/issue6715,
I'd like to propose the addition of a new module in Python 3.3. The 'lzma'
module will provide support for compression and decompression using the LZMA
algorithm, and the .xz and .lzma file formats. The matter has already been
discussed on the tracker http://bugs.python.org/issue6715, where
On Sat, 27 Aug 2011 15:08:36 +0200
Armin Rigo ar...@tunes.org wrote:
Hi Nick,
On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan ncogh...@gmail.com wrote:
1. How does the patch interact with C code that explicitly releases
the GIL? (e.g. IO commands inside a with atomic: block)
As
The implementation will also be similar to bz2 - basic compressor and
decompressor classes written in C, with convenience functions and a file
interface implemented on top of those in Python.
When I reviewed lzma, I found that this approach might not be
appropriate. lzma has many more options
On Sat, Aug 27, 2011 at 4:50 PM, Martin v. Löwis mar...@v.loewis.de wrote:
The implementation will also be similar to bz2 - basic compressor and
decompressor classes written in C, with convenience functions and a file
interface implemented on top of those in Python.
When I reviewed lzma, I
As for file formats, these are handled by liblzma itself; the extension module
just selects which compressor/decompressor initializer function to use
depending
on the value of the format argument. Our code won't contain anything along
the
lines of GzipFile; all of that work is done by the
On Sat, Aug 27, 2011 at 5:15 PM, Martin v. Löwis mar...@v.loewis.de wrote:
As for file formats, these are handled by liblzma itself; the extension
module
just selects which compressor/decompressor initializer function to use
depending
on the value of the format argument. Our code won't
On Sun, Aug 28, 2011 at 1:15 AM, Martin v. Löwis mar...@v.loewis.de wrote:
This is exactly what I worry about. I think adding file I/O to bz2 was a
mistake, as this doesn't integrate with Python's IO library (it used
to, but now after dropping stdio, they were incompatible. Indeed, for
Python
It is not my intention for the _lzma C module to do I/O - that will be done by
the LZMAFile class, which will be written in Python. My comparison with bz2
was
in reference to the state of the module after it was rewritten for issue 5863.
Ok. I'll defer my judgement then until actual code is
On Sun, 28 Aug 2011 01:36:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Aug 28, 2011 at 1:15 AM, Martin v. Löwis mar...@v.loewis.de wrote:
This is exactly what I worry about. I think adding file I/O to bz2 was a
mistake, as this doesn't integrate with Python's IO library (it used
On Sun, Aug 28, 2011 at 1:40 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 28 Aug 2011 01:36:50 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Aug 28, 2011 at 1:15 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
This is exactly what I worry about. I think adding file I/O to bz2
On Sat, Aug 27, 2011 at 5:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Not sure whether you already have this: supporting the tarfile module
would be nice.
Yes, got that - issue 5689. Also of interest is issue 5411 - adding .xz
support to distutils. But I think that these are separate
On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda nadeem.va...@gmail.com wrote:
On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
It's acceptable for the Python version to use ctypes in the case of
wrapping an existing library, but the Python version should still
exist.
I'm
Hi Antoine,
You then risk deadlocks. Say:
(...)
Yes, it is indeed not a solution that co-operates transparently and
deadlock-freely with regular locks. You risk the same kind of
deadlocks as you would when using only locks. The reason is similar
to threads that try to acquire two locks in
On Fri, Aug 26, 2011 at 11:01 PM, Dan Stromberg drsali...@gmail.com wrote:
[Steven]
Have then been any __future__ features that were added provisionally?
I can't either, but ISTR hearing that from __future__ import was started
with such an intent. Irrespective, it's hard to import something
On Sat, Aug 27, 2011 at 9:19 AM, Guido van Rossum gu...@python.org wrote:
On Fri, Aug 26, 2011 at 11:01 PM, Dan Stromberg drsali...@gmail.com
wrote:
[Steven]
Have then been any __future__ features that were added provisionally?
I can't either, but ISTR hearing that from __future__ import
On Sun, 28 Aug 2011 01:52:51 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The plausible story being that we basically wrap an existing library?
I don't think PyPy et al have pure Python versions of the zlib or
OpenSSL, do they?
If we start taking PEP 399 conformance to such levels, we
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g. introduces
a new keyword) so that for 1 (sometimes more) releases we require the
users to use the
PEP 399 also comes into play - we need a pure Python version for PyPy
et al (or a plausible story for why an exception should be granted).
No, we don't. We can grant an exception, which I'm very willing to do.
The PEP lists wrapping a specific C-based library as a plausible reason.
It's
Hi Armin,
This is basically dangerous, because it corresponds to taking lock
GIL and lock L, in that order, whereas the thread B takes lock L and
plays around with lock GIL in the opposite order. I think a
reasonable solution to avoid deadlocks is simply not to use explicit
locks inside
Am 27.08.2011 12:10, schrieb Antoine Pitrou:
On Sat, 27 Aug 2011 08:02:31 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a review of
tests).
I think it's
On Sat, 27 Aug 2011 18:50:40 +0200
Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 28 Aug 2011 01:52:51 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The plausible story being that we basically wrap an existing library?
I don't think PyPy et al have pure Python versions of the zlib or
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.comwrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g. introduces
a new
On 2011-08-27, at 2:20 PM, Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.com wrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also
I disagree. The first paragraph says this has something to do with new
keywords. It doesn't appear to say what we expect users to -do- with
it. Both are important.
Well, users can use the new features...
Is it You'd better try this, because it's going in eventually. If you
don't try it
On 8/27/2011 9:47 AM, Nadeem Vawda wrote:
I'd like to propose the addition of a new module in Python 3.3. The 'lzma'
module will provide support for compression and decompression using the LZMA
algorithm, and the .xz and .lzma file formats. The matter has already been
discussed on the
Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin brian.cur...@gmail.comwrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg drsali...@gmail.com wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g.
On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda nadeem.va...@gmail.com
wrote:
On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan ncogh...@gmail.com
wrote:
It's acceptable for the Python version to use ctypes in the case of
In the thread about replacing re with regex someone mentioned adding
to __future__ which isnt a great idea as future APIs are already
solidified, they just live there to give developer time to adapt their
code. The idea of a __experimental__ area is good for any pep's or
stliib additions that are
I'd like to better understand why ctypes is (sometimes) frowned upon.
Is it the brittleness? Tendency to segfault?
That, and Python should work completely if ctypes is not available.
FWIW, I have a partial implementation of a module that does xz from
Python using ctypes.
So does it work
On Sat, Aug 27, 2011 at 9:47 PM, Terry Reedy tjre...@udel.edu wrote:
On 8/27/2011 9:47 AM, Nadeem Vawda wrote:
I'd like to propose the addition of a new module in Python 3.3. The 'lzma'
module will provide support for compression and decompression using the
LZMA
algorithm, and the .xz and
On Sat, Aug 27, 2011 at 1:21 PM, Martin v. Löwis mar...@v.loewis.dewrote:
I'd like to better understand why ctypes is (sometimes) frowned upon.
Is it the brittleness? Tendency to segfault?
That, and Python should work completely if ctypes is not available.
What are the most major
Le samedi 27 août 2011 21:57:26, Dj Gilcrease a écrit :
The idea of a __experimental__ area is good for any pep's or
stliib additions that are somewhat controversial (API isnt agreed on,
code may take a while to integrate properly, developer wants some time
to hash out any edge case bugs or
On 07:57 pm, digitalx...@gmail.com wrote:
In the thread about replacing re with regex someone mentioned adding
to __future__ which isnt a great idea as future APIs are already
solidified, they just live there to give developer time to adapt their
code. The idea of a __experimental__ area is good
On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg drsali...@gmail.com wrote:
It seems like there should be some way of coming up with an xml file
describing the types of the various bits of data and formal arguments -
perhaps using gccxml or something like it.
The problem is that you would need
On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda nadeem.va...@gmail.comwrote:
On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg drsali...@gmail.com
wrote:
It seems like there should be some way of coming up with an xml file
describing the types of the various bits of data and formal arguments -
On Sat, 27 Aug 2011 15:14:15 -0700
Dan Stromberg drsali...@gmail.com wrote:
On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda nadeem.va...@gmail.comwrote:
On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg drsali...@gmail.com
wrote:
It seems like there should be some way of coming up with an
Why -can't- we expect the user to have liblzma headers installed?
Couldn't it just be a dependency in the package management system?
Please give it up. You just won't convince that list that ctypes
is a viable approach for the standard library.
Regards,
Martin
On Sat, Aug 27, 2011 at 3:26 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 15:14:15 -0700
Dan Stromberg drsali...@gmail.com wrote:
On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda nadeem.va...@gmail.com
wrote:
On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg
On Sat, 27 Aug 2011 16:19:01 -0700
Dan Stromberg drsali...@gmail.com wrote:
2) It's a rather arbitrary distinction that's being drawn between dev and
nondev today. There's no particular reason why the line couldn't be drawn
somewhere else.
Sure. Now please convince Linux distributions first,
Nick Coghlan wrote:
The next step needed is for someone to volunteer to write and champion
a PEP that:
Would it be feasible and desirable to modify regex so
that it *is* backwards-compatible with re, with a view
to making it a drop-in replacement at some point?
If not, the PEP should discuss
On 8/27/2011 7:39 PM, Greg Ewing wrote:
Nick Coghlan wrote:
The next step needed is for someone to volunteer to write and champion
a PEP that:
Would it be feasible and desirable to modify regex so
that it *is* backwards-compatible with re, with a view
to making it a drop-in replacement at
On Sat, Aug 27, 2011 at 4:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
Sure. Now please convince Linux distributions first, because this
particular subthread is going nowhere.
I hope you're not a solipsist.
Anyway, if the mere -discussion- of embracing a standard and safe way of
making
On Sat, Aug 27, 2011 at 4:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 16:19:01 -0700
Dan Stromberg drsali...@gmail.com wrote:
2) It's a rather arbitrary distinction that's being drawn between dev and
nondev today. There's no particular reason why the line couldn't
On Sun, Aug 28, 2011 at 3:48 AM, Terry Reedy tjre...@udel.edu wrote:
These are reasons why both Ezio and I suggested on the tracker adding regex
without deleting re. (I personally would not mind just replacing re with
regex, but then I have no legacy re code to break. So I am not suggesting
On Sat, Aug 27, 2011 at 5:48 PM, Terry Reedy tjre...@udel.edu wrote:
Many of the things regex does differently might be called either bug fixes
or feature changes, depending on one's viewpoint. Regex should definitely
not be 'bug-compatible'.
Well, as you said, it depends on one's viewpoint.
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com wrote:
IMO, we really, really need some common way of accessing C libraries that
works for all major Python variants.
We have one. It's called writing an extension module.
ctypes is a crutch because it doesn't realistically
On Sat, Aug 27, 2011 at 4:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti ezio.melo...@gmail.com wrote:
I'm not sure it's worth doing an extensive review of the code, a better
approach might be to require extensive test coverage (and a
On Sat, Aug 27, 2011 at 8:59 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
On Sat, Aug 27, 2011 at 4:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 27 Aug 2011 04:37:21 +0300
Ezio Melotti ezio.melo...@gmail.com wrote:
I'm not sure it's worth doing an extensive review of the
Dan, I once had the more or less the same opinion/question as you with
regard to ctypes, but I now see at least 3 problems.
1) It seems hard to write it correctly. There are currently 47 open
ctypes issues, with 9 being feature requests, leaving 38
behavior-related issues. Tom Heller has not
On 8/27/2011 11:54 PM, Guido van Rossum wrote:
If so, it would be like the decimal
module, which closely tracks the IEEE decimal standard, rather than the
binary float standard.
Well, I would hope that for each major Python version (i.e. 3.2,
3.3, 3.4, ...) we would pick a specific version of
On Sat, Aug 27, 2011 at 8:57 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com
wrote:
IMO, we really, really need some common way of accessing C libraries that
works for all major Python variants.
We have one. It's called
69 matches
Mail list logo
