On Sun, Jun 27, 2010 at 1:49 PM, P.J. Eby wrote:
> I just hate the idea that functions taking strings should have to be
> *rewritten* to be explicitly type-agnostic. It seems *so* un-Pythonic...
> like if all the bitmasking functions you'd ever written using 32-bit int
> constants had to be rewr
On Sat, Jun 26, 2010 at 4:37 PM, M.-A. Lemburg wrote:
> Brett Cannon wrote:
>> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>>> I finally realized why clang has not been silencing its warnings about
>>> unused return values: I have -Wno-unused-value set in CFLAGS which
>>> comes before OPT
At 12:43 PM 6/27/2010 +1000, Nick Coghlan wrote:
While full support for third party strings and
byte sequence implementations is an interesting idea, I think it's
overkill for the specific problem of making it easier to write
str/bytes agnostic functions for tasks like URL parsing.
OTOH, to wri
On Sun, Jun 27, 2010 at 8:11 AM, Terry Reedy wrote:
> I can imagine that inter-operation, when appropriate, might work better with
> addition of a couple of missing __rxxx__ methods, such as the mentioned
> __rcontains__. Although adding such would affect the implementation of a
> core syntax fea
On Sun, Jun 27, 2010 at 4:17 AM, P.J. Eby wrote:
> The idea that I'm proposing is that the basic string and byte types should
> defer to "user-defined" string types for mixed type operations, so that
> polymorphism of string-manipulation functions is the *default* case, rather
> than a *special* c
On Sat, Jun 26, 2010 at 16:37, M.-A. Lemburg wrote:
> Brett Cannon wrote:
>> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>>> I finally realized why clang has not been silencing its warnings about
>>> unused return values: I have -Wno-unused-value set in CFLAGS which
>>> comes before OPT (w
Brett Cannon wrote:
> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>> I finally realized why clang has not been silencing its warnings about
>> unused return values: I have -Wno-unused-value set in CFLAGS which
>> comes before OPT (which defines -Wall) as set in PY_CFLAGS in
>> Makefile.pre.
On 6/26/2010 4:06 PM, Matthias Klose wrote:
> On 25.06.2010 22:12, James Y Knight wrote:
>> On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
>>> Placing .so files together does not simplify that install process in any
>>> way. You will still have to handle such packages in a special way.
>>
>> This i
On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
> I finally realized why clang has not been silencing its warnings about
> unused return values: I have -Wno-unused-value set in CFLAGS which
> comes before OPT (which defines -Wall) as set in PY_CFLAGS in
> Makefile.pre.in.
>
> I could obviously
The several posts in this and other threads go me to think about text
versus number computing (which I am more familiar with).
For numbers, we have in Python three builtins, the general purpose ints
and floats and the more specialized complex. Two other rational types
can be imported for speci
On Jun 26, 2010, at 4:35 PM, Matthias Klose wrote:
On 26.06.2010 22:30, C. Titus Brown wrote:
On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote:
On 25.06.2010 02:54, Ben Finney wrote:
James Y Knight writes:
Really, python should store the .py files in /usr/share/python/,
th
Brett Cannon wrote:
I finally realized why clang has not been silencing its warnings about
unused return values: I have -Wno-unused-value set in CFLAGS which
comes before OPT (which defines -Wall) as set in PY_CFLAGS in
Makefile.pre.in.
I could obviously set OPT in my environment, but that would
On 25.06.2010 20:58, Brett Cannon wrote:
On Fri, Jun 25, 2010 at 01:53, Scott Dial
Placing .so files together does not simplify that install process in any
way. You will still have to handle such packages in a special way. You
must still compile the package multiple times for each relevant versi
On 26.06.2010 22:30, C. Titus Brown wrote:
On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote:
On 25.06.2010 02:54, Ben Finney wrote:
James Y Knight writes:
Really, python should store the .py files in /usr/share/python/, the
.so files in /usr/lib/x86_64- linux-gnu/python2.5-deb
On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote:
> On 25.06.2010 02:54, Ben Finney wrote:
>> James Y Knight writes:
>>
>>> Really, python should store the .py files in /usr/share/python/, the
>>> .so files in /usr/lib/x86_64- linux-gnu/python2.5-debug/, and the .pyc
>>> files in /va
On 25.06.2010 02:54, Ben Finney wrote:
James Y Knight writes:
Really, python should store the .py files in /usr/share/python/, the
.so files in /usr/lib/x86_64- linux-gnu/python2.5-debug/, and the .pyc
files in /var/lib/python2.5- debug. But python doesn't work like that.
+1
So who's going
On 24.06.2010 22:46, Barry Warsaw wrote:
On Jun 24, 2010, at 02:28 PM, Barry Warsaw wrote:
On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
2010/6/24 Barry Warsaw:
On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
2010/6/24 Barry Warsaw:
Please let me know what you think. I'm
On 26.06.2010 02:19, Nick Coghlan wrote:
On Sat, Jun 26, 2010 at 6:12 AM, James Y Knight wrote:
However, then you have to also consider python packages made up of multiple
distro packages -- like twisted or zope. Twisted includes some C extensions
in the core package. But then there are other t
On 25.06.2010 22:12, James Y Knight wrote:
On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
On 6/24/2010 8:23 PM, James Y Knight wrote:
On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
If the package has .so files that aren't compatible with other version
of python, then what is the motivation f
At 12:42 PM 6/26/2010 +0900, Stephen J. Turnbull wrote:
What I'm saying here is that if bytes are the signal of validity, and
the stdlib functions preserve validity, then it's better to have the
stdlib functions object to unicode data as an argument. Compare the
alternative: it returns a unicode
On 6/26/2010 7:44 AM, Jesse Noller wrote:
On Sat, Jun 26, 2010 at 9:29 AM, Michael Foord
wrote:
On 26/06/2010 07:11, John Nagle wrote:
We have just released a proof-of-concept implementation of a new
approach to thread management - "newthreading".
The import * form is considered bad
Greg Ewing writes:
> Would there be any sanity in having an option to compile
> Python with UTF-8 as the internal string representation?
Losing Py_UNICODE as mentioned by Stefan Behnel (IIRC) is just the
beginning of the pain.
If Emacs's experience is any guide, the cost in speed and complexit
On Sat, Jun 26, 2010 at 9:29 AM, Michael Foord
wrote:
> On 26/06/2010 07:11, John Nagle wrote:
>>
>> We have just released a proof-of-concept implementation of a new
>> approach to thread management - "newthreading". It is available
>> for download at
>>
>> https://sourceforge.net/projects/newthre
On Sat, 26 Jun 2010 14:29:24 +0100
Michael Foord wrote:
>
> the introduction of
> free-threading in Python has not been hampered by lack of
> synchronization primitives but by the difficulty of changing the
> interpreter without unduly impacting single threaded code.
Exactly what I think too.
On Sat, Jun 26, 2010 at 9:29 AM, Michael Foord
wrote:
> On 26/06/2010 07:11, John Nagle wrote:
>>
>> We have just released a proof-of-concept implementation of a new
>> approach to thread management - "newthreading". It is available
>> for download at
>>
>> https://sourceforge.net/projects/newthre
On 26/06/2010 07:11, John Nagle wrote:
We have just released a proof-of-concept implementation of a new
approach to thread management - "newthreading". It is available
for download at
https://sourceforge.net/projects/newthreading/
The user's guide is at
http://www.animats.com/papers/languages/
Hi,
On Fri, Jun 25, 2010 at 05:27:52PM -0600, Maciej Fijalkowski wrote:
>python setup.py build
As corrected on the blog (http://morepypy.blogspot.com/), this line
should read:
pypy setup.py build
Armin.
___
Python-Dev mailing list
Python-Dev
We have just released a proof-of-concept implementation of a new
approach to thread management - "newthreading". It is available
for download at
https://sourceforge.net/projects/newthreading/
The user's guide is at
http://www.animats.com/papers/languages/newthreadingintro.html
This is
Nick Coghlan wrote:
> On Sat, Jun 26, 2010 at 9:23 AM, Benjamin Peterson
> wrote:
>> 2010/6/25 Steve Holden :
>> I would call it more a sign of no tests rather than one of neglect and
>> perhaps also an indication of the usefulness of those tools.
>
> Less than useful tools with no tests probabl
Greg Ewing, 26.06.2010 09:58:
Tres Seaver wrote:
I do know for a fact that using a UCS2-compiled Python instead of the
system's UCS4-compiled Python leads to measurable, noticable drop in
memory consumption of long-running webserver processes using Unicode
Would there be any sanity in having
Ian Bicking, 26.06.2010 00:26:
On Fri, Jun 25, 2010 at 4:02 PM, Guido van Rossum wrote:
On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
I'd like a version of 'decode' which would give me a type that was, in
every
respect, unicode, and responded to all protocols exactly as other
unicode objec
Tres Seaver wrote:
I do know for a fact that using a UCS2-compiled Python instead of the
system's UCS4-compiled Python leads to measurable, noticable drop in
memory consumption of long-running webserver processes using Unicode
Would there be any sanity in having an option to compile
Python wit
32 matches
Mail list logo
