[issue4266] Python 3.0 docs are broken.

[Winfried Plappert]

Winfried Plappert <[EMAIL PROTECTED]> added the comment:

In other words, the various *Tex packages cannot agree on a common syntax?

MiKTeX-pdfTeX 2.7.3147 (1.40.9) (MiKTeX 2.7) also complains about the
double \fi.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4266] Python 3.0 docs are broken.

[Winfried Plappert]

Winfried Plappert <[EMAIL PROTECTED]> added the comment:

And Ubuntu Linux pdflatex complains as well:
/usr/bin/pdflatex from package texlive-latex-base.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> Yes, it uses base 2**15 but it's not the correct conversion to base 
> 2**15. You convert each PyLong digit to base 2**15 but not the whole 
> number.

I don't understand:  yes, each base 2**30 digit is converted to a pair 
of base 2**15 digits, and if necessary (i.e., if the top 15 bits of the 
most significant base 2**30 digit are zero) the size is adjusted.  How 
is this not converting the whole number?

> As a result, the format is different than the current mashal version.

Can you give an example of an integer n such that marshal.dumps(n) gives 
you different results with and without the patch?  As far as I can tell, 
I'm getting the same marshal results both with the unpatched version and 
with the patch applied.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4266] Python 3.0 docs are broken.

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

> In other words, the various *Tex packages cannot agree on a common syntax?

No, syntax has nothing to do with it. It was a mistake of some sort on
my part. It depends on whether the "ifxetex" latex package is present,
because that already defines the \ifxetex command.

I've now fixed it in Sphinx tip, and copied it to SVN so that Barry
needn't do anything except "make update" before trying to build the docs
again.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4266] Python 3.0 docs are broken.

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Other responses...
> It was an argument for changing the base used by the mashal :-)

Ah.  I think I'm with you now.  You're saying that ideally, marshal 
shouldn't have to care about how Python stores its longs:  it should 
just ask some function in longobject.c to provide an already-converted-
to-base-256 representation.  Is that right?

I also find the idea of making the marshal representation base 256 quite 
attractive.  There are already functions in longobject.c that could be 
used for this: _PyLong_{From,As}ByteArray.  And then you wouldn't need 
to touch marshal.c when swapping the GMP version of longobject.c in and 
out.

> Python stores the sign of the number in the first digit. Because 
> of that, we are limited to 15/30 bits.

No: the sign is stored in the size:  if v is a PyLongObject then 
ABS(Py_SIZE(v)) gives the number of digits in the absolute value of the 
integer represented by v, and the sign of Py_SIZE(v) gives the sign of 
the integer.

> would it be possible to keep the "2 digits" hack in 
> PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 
> 15". The base 2^15 slow, so don't make it slower :-)

Why don't we leave this kind of micro-optimization out until we've got 
some benchmarks.  (I'm also tempted to get rid of the long_mul fast path 
for now.)

> PyLong_FromLong() doesn't go into the 1 digit special case for 
> negative number.

Well spotted!  Yes, this should be fixed.  I have a nasty feeling that I 
was responsible for introducing this bug some time ago...

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4268] functions in email package listed under wrong module

[Gabriel Genellina]

New submission from Gabriel Genellina <[EMAIL PROTECTED]>:

Functions message_from_string and message_from_file are documented as 
belonging to the email.parser module, but in fact they live at the top 
of the email package.

The .rst source looks fine, but the rendered html says  
`email.parser.message_from_string`. 
http://docs.python.org/library/email.parser.html#parser-class-api

Perhaps it's the `module:: email.parser` directive at the top?

A similar problem is in email.mime.rst; all the documented classes are 
exposed at the top of the email package (i.e. should be email.MIMEBase, 
not email.mime.MIMEBase)

--
assignee: georg.brandl
components: Documentation
messages: 75554
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: functions in email package listed under wrong module
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4268] functions in email package listed under wrong module

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, fixed in r67117.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4267] sqlite3 documentation

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, applied in r67118.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4245] threading documentation: reorder sections

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

I agree -- fixed in r67119.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11950/pybench_results.txt

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

And now the stat of Python patched with 30bit_longdigit3.patch.

min/avg/max are now the number of bits which gives better 
informations. "bigger" is the number of arguments which are bigger than 1 
digit (not in range [-2^30; 2^30]).

make


_FromLong:   169734 calls, min=( 0,  ), avg=(11.6, ), max=(  32, )
  \--> bigger=31086
long_bool:48772 calls, min=( 0,  ), avg=( 0.3, ), max=(  24, )
long_add: 39685 calls, min=( 0, 0), avg=( 6.5,  3.5), max=(  19,   32)
  \--> bigger=1
long_compare: 39445 calls, min=( 0, 0), avg=( 9.3,  8.4), max=(  31,   33)
  \--> bigger=10438
_AsLong:  33726 calls, min=( 0,  ), avg=( 4.9, ), max=(1321, )
  \--> bigger=10
long_sub: 13285 calls, min=( 0, 0), avg=( 7.6,  5.6), max=(  13,   13)
long_bitwise:  4690 calls, min=( 0, 0), avg=( 1.7,  1.9), max=(  16,   16)
long_hash: 1097 calls, min=( 0,  ), avg=( 8.1, ), max=(  33, )
  \--> bigger=4
long_mul:   236 calls, min=( 0, 0), avg=( 1.3,  5.4), max=(  17,   17)
long_invert:204 calls, min=( 0,  ), avg=( 2.4, ), max=(   3, )
long_neg:35 calls, min=( 1,  ), avg=( 4.3, ), max=(   7, )
long_format:  3 calls, min=( 0,  ), avg=( 2.0, ), max=(   4, )
long_mod: 3 calls, min=( 1, 2), avg=( 1.7,  2.0), max=(   2,2)
long_pow: 1 calls, min=( 2, 6), avg=( 2.0,  6.0), max=(   2,6)

Notes about make:
 - PyLong_FromLong(), long_compare(), PyLong_AsLong() and long_hash() 
   gets integers not in [-2^30; 2^30] which means that all other functions
   are only called with arguments of 1 digit!
 - PyLong_FromLong() gets ~30.000 (18%) integers of 32 bits
 - global average integer size is between 0.3 and 11.6 (~6.0 bits?)
 - There are 41.500 (12%) big integers on ~350.000 integers

pystone
===

_FromLong:   1504983 calls, min=( 0,  ), avg=( 5.1, ), max=(  31, )
  \--> bigger=14
long_add: 902487 calls, min=( 0, 0), avg=( 3.9,  2.4), max=(  17,   17)
long_compare: 651165 calls, min=( 0, 0), avg=( 1.7,  1.4), max=(  31,   31)
  \--> bigger=27
_AsLong:  252477 calls, min=( 0,  ), avg=( 4.6, ), max=(  16, )
long_sub: 250032 calls, min=( 1, 0), avg=( 4.0,  1.6), max=(   7,7)
long_bool:102655 calls, min=( 0,  ), avg=( 0.5, ), max=(   7, )
long_mul: 100015 calls, min=( 0, 0), avg=( 2.5,  2.0), max=(   4,   16)
long_truediv:  5 calls, min=( 4, 2), avg=( 4.0,  2.0), max=(   4,2)
long_hash:   382 calls, min=( 0,  ), avg=( 8.1, ), max=(  28, )
long_bitwise:117 calls, min=( 0, 0), avg=( 6.7,  6.6), max=(  15,   16)
long_format:   1 calls, min=(16,  ), avg=(16.0, ), max=(  16, )

Notes about pystone:
 - very very few numbers are bigger than one digit: 41 / ~4.000.000
 - global average integer size is between 0.5 and 6.7 (~3.0 bits?)
 - the biggest number has only 31 bits (see long_compare)

Short summary:
 - pystone doesn't use big integer (1 big integer for 100.000 integers)
   => don't use pystone!
 - the average integer size is around 3 or 6 bits, which means that most
   integers can be stored in 8 bits (-255..255)
   => we need to focus on the very small numbers
   => base 2^30 doesn't help for common Python code, it only helps programs
  using really big numbers (128 bits or more?)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4263] BufferedWriter non-blocking overage

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The patch is good. 

I was first surprised by the fact that e.characters_written is not used
in the write() method; but _flush_unlocked() already adjusts the
_write_buf according to the original e.characters_written raised by the
underlying raw file. Everything is fine.

I suggest however to add some tests around the first "except
BlockingIOError". This would answer the question:
# XXX Why not just let the exception pass through?
For example, I modified a function in your patch:

def testWriteNonBlockingOverage(self):
raw = MockNonBlockWriterIO((-1, -2))
[...]

# Subsequent calls to write() try to flush the raw file.
try:
bufio.write(b"x")
except io.BlockingIOError as e:
# Two more chars were written at the raw level
self.assertEqual(bufio._write_buf, write_buf[2:])
# But write() did not accept anything.
self.assertEqual(e.characters_written, 0)
else:
self.fail("BlockingIOError not raised")

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

> I'll investigate the slowdowns

The problem may comes from int64_t on 32 bits CPU. 32x32 -> 64 may be 
emulated on your CPU and so it's slower. I improved your patch to make 
it faster, but I lost all my work because of a misuse of GIT... As I 
remember:
 - I fixed PyLong_FromLong() for small negative integer
 - I unrolled the loop in PyLong_FromLong(): the loop is at least 
called twice (the number has 2 digits or more)
 - I added special code for operations on two numbers of 1 digit 
(each) for long_add(), long_mul(), long_div(), long_bitwise(), etc.
 - and I don't remember the other changes...

Oh, I have an old patch. I will attach it to this message. About 
speed, it was:
 * unpatched: 20600..20900 pystones
 * your patch: 19900..20100 pystones
 * + my changes: 20200..20400 pytones

Added file: http://bugs.python.org/file11951/optimize.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

I wrote a patch to compute stat about PyLong function calls.

make (use setup.py):

PyLong_FromLong: 168572 calls, min=( 0,  ), avg=(1.4,), max=(  3,)
long_bool:48682 calls, min=( 0,  ), avg=(0.2,), max=(  2,)
long_add: 39527 calls, min=( 0, 0), avg=(0.9, 1.0), max=(  2,   3)
long_compare: 39145 calls, min=( 0, 0), avg=(1.2, 1.1), max=(  3,   3)
PyLong_AsLong:33689 calls, min=( 0,  ), avg=(0.9,), max=( 45,)
long_sub: 13091 calls, min=( 0, 0), avg=(0.9, 0.8), max=(  1,   1)
long_bitwise:  4636 calls, min=( 0, 0), avg=(0.8, 0.6), max=(  2,   2)
long_hash: 1097 calls, min=( 0,  ), avg=(0.9,), max=(  3,)
long_mul:   221 calls, min=( 0, 0), avg=(0.8, 1.1), max=(  2,   2)
long_invert:204 calls, min=( 0,  ), avg=(1.0,), max=(  1,)
long_neg:35 calls, min=( 1,  ), avg=(1.0,), max=(  1,)
long_format:  3 calls, min=( 0,  ), avg=(0.7,), max=(  1,)
long_mod: 3 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)
long_pow: 1 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)

pystone:

PyLong_FromLong:1587652 calls, min=( 0,  ), avg=(1.0,), max=(  3,)
long_add:902487 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  2,   2)
long_compare:651165 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  3,   3)
PyLong_AsLong:   252476 calls, min=( 0,  ), avg=(1.0,), max=(  2,)
long_sub:250032 calls, min=( 1, 0), avg=(1.0, 1.0), max=(  1,   1)
long_bool:   102655 calls, min=( 0,  ), avg=(0.5,), max=(  1,)
long_mul:100015 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  1,   2)
long_div: 5 calls, min=( 1, 1), avg=(1.0, 1.0), max=(  1,   1)
long_hash:  382 calls, min=( 0,  ), avg=(1.1,), max=(  2,)
long_bitwise:   117 calls, min=( 0, 0), avg=(1.0, 1.0), max=(  1,   2)
long_format:  1 calls, min=( 2,  ), avg=(2.0,), max=(  2,)

min/avg/max are the integer digit count (minimum, average, maximum).

What can we learn from this numbers?

PyLong_FromLong(), long_add() and long_compare() are the 3 most common 
operations on integers. 

Except PyLong_FromLong(), long_compare() and long_format(), arguments of the 
functions are mostly in range [-2^15; 2^15].

Biggest number is a number of 45 digits: maybe just one call to long_add(). 
Except this number/call, the biggest numbers have between 2 and 3 digits. 

long_bool() is never called with number bigger than 2 digits.

long_sub() is never called with number bigger than 1 digit!

Added file: http://bugs.python.org/file11952/long_stat.patch

___
Python tracker <[EMAIL PROTECTED]>

___diff --git a/Include/graminit.h b/Include/graminit.h
diff --git a/Objects/longobject.c b/Objects/longobject.c
index 8f7ad4c..b45f809 100644
--- a/Objects/longobject.c
+++ b/Objects/longobject.c
@@ -29,6 +29,128 @@ static PyLongObject small_ints[NSMALLNEGINTS + 
NSMALLPOSINTS];
 int quick_int_allocs, quick_neg_int_allocs;
 #endif
 
+typedef enum {
+   STAT_FROMLONG = 0,
+   STAT_BOOL,
+   STAT_COMPARE,
+   STAT_RICHCOMPARE,
+   STAT_ADD,
+   STAT_ASLONG,
+   STAT_SUB,
+   STAT_BITWISE,
+   STAT_HASH,
+   STAT_INVERT,
+   STAT_NEG,
+   STAT_FORMAT,
+   STAT_MUL,
+   STAT_MOD,
+   STAT_POW,
+   STAT_DIV,
+   STAT_TRUEDIV,
+   STAT_RSHIFT,
+   STAT_LSHIFT,
+   STAT_LONG,
+   STAT_FLOAT,
+   STAT_ABS,
+   STAT_DIVMOD,
+   STAT_FORMAT_ADV,
+   STAT_ROUND,
+
+   STAT_COUNT
+} stat_id_t;
+
+typedef struct {
+   int min;
+   int max;
+   int total;
+} stat_digits_t;
+
+typedef struct {
+   int id;
+   int calls;
+   stat_digits_t a;
+   stat_digits_t b;
+} stat_data_t;
+
+stat_data_t _PyLong_stat[STAT_COUNT];
+
+void init_stat(void)
+{
+   unsigned int id;
+   stat_data_t* data;
+   stat_digits_t *a, *b;
+   for (id=0; idid = id;
+   data->calls = 0;
+   a = &data->a;
+   a->min = INT_MAX;
+   a->max = INT_MIN;
+   a->total = 0;
+   b = &data->b;
+   b->min = INT_MAX;
+   b->max = INT_MIN;
+   b->total = 0;
+   }
+}
+
+int cmp_stat(const void *va, const void *vb)
+{
+   const stat_data_t* a = (const stat_data_t*)va;
+   const stat_data_t* b = (const stat_data_t*)vb;
+   if (a->calls < b->calls)
+   return 1;
+   else if (a->calls > b->calls)
+   return -1;
+   else
+   return 0;
+}
+
+void dump_stat(void)
+{
+   unsigned int id;
+   stat_data_t* data;
+   stat_digits_t *a, *b;
+   double avga, avgb;
+   qsort(_PyLong_stat, STAT_COUNT, sizeof(_PyLong_stat[0]), cmp_stat);
+   for (id=0; idid, d

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Here's a pybench comparison, on OS X 10.5/Core 2 Duo/gcc 4.0.1 (32-bit 
non-debug build of the py3k branch).  I got this by doing:

[create clean build of py3k branch]
dickinsm$ ./python.exe Tools/pybench/pybench.py -f bench_unpatched
[apply 30bit patch and rebuild]
dickinsm$ ./python.exe Tools/pybench/pybench.py -c bench_unpatched

Highlights: SimpleLongArithmetic: around 10% faster.
SimpleComplexArithmetic: around 16% slower!
CompareFloatsIntegers: around 20% slower.

I'll investigate the slowdowns.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4269] Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html

[Berend-Jan Wever]

New submission from Berend-Jan Wever <[EMAIL PROTECTED]>:

Part of the text of the online documentation for the string.split() method:


If sep is not specified or is None, a different splitting algorithm is
applied. First, whitespace characters (spaces, tabs, newlines, returns,
and formfeeds) are stripped from both ends. Then, words are separated by
arbitrary length strings of whitespace characters. Consecutive
whitespace delimiters are treated as a single delimiter ("'1 2
3'.split()" returns "['1', '2', '3']"). Splitting an empty string or a
string consisting of just whitespace returns an empty list.


As you may have noticed, there should be multiple spaces in ("'1 2
3'.split()". If you look at the HTML source you will see that they are
there. However, because browsers rendering HTML by default replace
multiple space with a single space, they are not visible in the
documentation. This should be addressed by either using 
around the text to preserve formatting or by replacing all instances of
multiple spaces with instances of " ". I suspect this problem may
be elsewhere in the documentation as well.

--
assignee: georg.brandl
components: Documentation
messages: 75558
nosy: SkyLined, georg.brandl
severity: normal
status: open
title: Spaces not showing correctly in "split()" documentation on 
http://www.python.org/doc/2.5.2/lib/string-methods.html
type: feature request

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4263] BufferedWriter non-blocking overage

[Banesiu Sever]

Banesiu Sever <[EMAIL PROTECTED]> added the comment:

Thanks for your review, here's a new patch.
I've added a new test for the pre-flush condition and made the comments
less cryptic.

Added file: http://bugs.python.org/file11953/bw_overage2.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4263] BufferedWriter non-blocking overage

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

We have discussed this bug in the python developer chat yesterday. I
decided to wait until after the 3.0.0 release. The problem is not
critical enough for 3.0.0. I like to keep the amount of changes during
the RC phase to a minimum.

--
nosy: +christian.heimes
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4263] BufferedWriter non-blocking overage

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I do concur with the desire to restrict changes during RC phase. Do this
also mean that merges from trunk will be reduced to the strict minimum?
No global merge, only on a revision basis after review.

In this case we could apply the patch to the trunk, and let a future
global merge propagate the change to py3k.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Should this patch be applied to 3.0 before the next RC lands? Barry
hasn't released RC2 yet.

--
nosy: +christian.heimes
type:  -> compile error
versions: +Python 2.7, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3166] Make conversions from long to float correctly rounded.

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Mark,

I noticed that you replaced a call to _PyLong_AsScaledDouble with your 
round to nearest algorithm.  I wonder if _PyLong_AsScaledDouble itself 
would benefit from your change.  Currently it is used in PyLong_AsDouble 
and long_true_divide.  I would think that long_true_divide would be more 
accurate if longs were rounded to the nearest float.

I also wonder whether round to nearest float can be implemented without 
floating point arithmetics.  I would think round towards zero should be 
a simple matter of extracting an appropriate number of bits from the 
long and round to nearest would at most require a long addition.

I believe _PyLong_AsScaledDouble is written the way it is to support 
non-IEEE floating formats, but I am not sure that your algorithm would 
always return the nearest float on an arbitrary non-IEEE platform.

Maybe it would be worthwhile to provide a simple IEEE specific code with   
well specified semantics for both PyLong_AsDouble and long_true_divide, 
but fall back to the current code on non-IEEE platforms.

--
nosy: +belopolsky

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4270] struct module: pack/unpack and byte order on x86_64

[Mikhail Terekhov]

New submission from Mikhail Terekhov <[EMAIL PROTECTED]>:

pack/unpack behavior changes unexpectedly depending on the byte order:

l:/tmp >uname -pmiovs
Linux #1 SMP 2008-10-14 22:17:43 +0200 x86_64 x86_64 x86_64 GNU/Linux
l:/tmp >python
python
Python 2.5.1 (r251:54863, Aug  1 2008, 00:35:20) 
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
import struct
>>> struct.pack(">L",0xdeadbeef)
struct.pack(">L",0xdeadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0xdeadbeef)
struct.pack("L",0xdeadbeef)
'\xef\xbe\xad\xde\x00\x00\x00\x00'
>>> struct.pack(">> 

The length of the result above is 8 when no byte order is specified
and 4 when it is.

Another example:

>>> struct.pack("L",0xdeadbeef)
'\x00\x00\x00\x00\xef\xbe\xad\xde'
>>> struct.pack(">> struct.pack("!L",0xdeadbeef)
'\x00\x00\x00\x00'
>>> struct.pack("!L",0x12345678deadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0x12345678deadbeef)
'\xef\xbe\xad\xdexV4\x12'
>>> 

Last results look strange.

--
components: Library (Lib)
messages: 75569
nosy: mmm77
severity: normal
status: open
title: struct module: pack/unpack and byte order on x86_64
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I have now committed Python-2.6-no.manifest.in.pyd.diff as r67120,
r67121, and r67122. Thanks for the patch.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4271] conversion tool does not fix "from Tkinter import N,E"

[Winfried Plappert]

New submission from Winfried Plappert <[EMAIL PROTECTED]>:

I tried to check the tracker for an existing issue with the conversion
tool, but I could not find one. I am using the "python2.6
Python2.6/Tools/scripts/2to3 -w -v ." command to convert existing Python
scripts to Python3.0.

I made two observations:

1. Tkinter
   from Tkinter import (N, E, ...) does NOT get translated to
   from tkinter import (N, E, ...)

2. 2to3 produces relative imports for stuff which lives in the same
directory, but trying to compile the stuff, I get the error:

org: from global_stuffimport *
2t3: from .global_stuffimport *
ValueError: Attempted relative import in non-package

--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 75571
nosy: wplappert
severity: normal
status: open
title: conversion tool does not fix "from Tkinter import N,E"
type: compile error
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4271] conversion tool does not fix "from Tkinter import N,E"

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

The relative import problem has been fixed that will be released in 2.6.1.

--
nosy: +benjamin.peterson
type: compile error -> behavior

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4271] conversion tool does not fix "from Tkinter import N,E"

[Winfried Plappert]

Winfried Plappert <[EMAIL PROTECTED]> added the comment:

and it is also fixed in 3.0rc1: I reran the conversion, but issue 2
still persists,

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4271] conversion tool does not fix "from Tkinter import N,E"

[Winfried Plappert]

Winfried Plappert <[EMAIL PROTECTED]> added the comment:

Sorry, issue 1 still persists: 
>From Tkinter import (bla,blah, blahh)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4271] conversion tool does not fix "from Tkinter import N,E"

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority:  -> high

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4269] Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This is fixed in the new docs, see
.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4236] Crash when importing builtin module during interpreter shutdown

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

PyModule_Create2 might be new, but the warning certainly is not - for
2.x, it lives in Py_InitModule4. Indeed, I can reproduce the problem
with 2.7a0, replacing the import of warnings with an import of imp.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4260] ctypes.xFUNCTYPE are decorators.

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

[David Lambert]
> > @CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
> > def py_cmp_func(*args):
> > (a,b,) = (t[0] for t in args)
> > print("py_cmp_func", a, b)
> > return a-b
> > 
> > qsort(ia,len(ia),sizeof(c_int),py_cmp_func)

[Kevin Watters]
> > As far as I know, the above code will fail randomly in release mode if 
> > you have multiple threads running Python, because when ctypes calls out 
> > to CFUNCTYPE functions, it releases the GIL.
> > 
> > For decorating a python function to give to qsort, maybe you can use 
> > PYFUNCTYPE?

Kevin is wrong - the code is perfect!  Sure does calling a CFUNCTYPE instance
release the GIL, but ctypes aquires the GIL again before executing the python
code in the wrapped py_cmp_func above.

I guess that using PYFUNCTYPE instead would possibly crash because the call to
'qsort' releases the GIL, and the PYFUNCTYPE instance assumes the GIL but does 
not
acquire it.

But I have no time to work on the docs, sorry.

--
nosy: +theller

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4247] Docs: Provide some examples of "pass" use in the tutorial.

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Committed in r67123. Thanks!

--
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

In r67125, r67126, r67127, r67128, r67129, I removed the mt.exe
invocation from tcl and tk, and removed the DLLs CRT manifest from the
installer.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

New submission from Jacques Frechet <[EMAIL PROTECTED]>:

The gzip header defined in RFC 1952 includes a mandatory "MTIME" field,
originally intended to contain the modification time of the original
uncompressed file.  It is often ignored when decompressing, though
gunzip (for example) uses it to set the modification time of the output
file if applicable.

The Python gzip module always sets the MTIME field to the current time,
and always discards MTIME when decompressing.  As a result, compressing
the same string using gzip produces different output every time.  For
certain applications, especially those involving comparisons or
cryprographic signing of binary files, these spurious changes can be
quite inconvenient.  Aside from the MTIME field, the gzip module already
produces entirely deterministic output.

I'm attaching a patch which adds an optional "mtime" argument to the
GzipFile class, giving the caller the option of providing a timestamp
when compressing.  Default behavior is unchanged.  I've included updated
documentation and three new test cases in the patch.

In order to facilitate testing, the patch also includes code to set the
"mtime" member of the GzipFile instance when decompressing.  The first
test case uses the new member to ensure that the timestamp given to the
GzipFile constructor is preserved correctly.  The second test checks for
specific values in the entire gzip header (not just the MTIME field) by
reading the compressed file directly, examining individual fields in a
(relatively) flexible way.  The third compares the entire compressed
stream against a predetermined sequence of bytes in a relatively
inflexible way.  All tests pass on my AMD64 box, and I expect them all
to pass on all supported platforms without any problems.  However, If
anybody is concerned that any of the tests sound like they might be too
brittle, I'm certainly not overly attached to them.

If anyone has any further suggestions, I'd be delighted to submit a new
patch.

Thanks!

Jacques

--
components: Library (Lib)
files: gzip-mtime-py3k.patch
keywords: patch
messages: 75580
nosy: jfrechet
severity: normal
status: open
title: set timestamp in gzip stream
type: feature request
Added file: http://bugs.python.org/file11954/gzip-mtime-py3k.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

Changes by Jacques Frechet <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11955/gzip-mtime-2.x.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

Jacques Frechet <[EMAIL PROTECTED]> added the comment:

This discussion of the problem and possible workarounds might also be of
interest:

 
http://stackoverflow.com/questions/264224/setting-the-gzip-timestamp-from-python

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4273] cycle created by profile.run

[darrenr]

New submission from darrenr <[EMAIL PROTECTED]>:

The profile module creates a reference cycle. See attached session.

--
components: Library (Lib)
files: profile_cycle.txt
messages: 75582
nosy: darrenr
severity: normal
status: open
title: cycle created by profile.run
type: resource usage
versions: Python 2.4
Added file: http://bugs.python.org/file11956/profile_cycle.txt

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4273] cycle created by profile.run

[darrenr]

darrenr <[EMAIL PROTECTED]> added the comment:

The profile module creates a reference cycle. See attached session.

Note: cycle can be broken by deleting reference to 'dispatcher' on 
profile.Profile() instance.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[David Turner]

David Turner <[EMAIL PROTECTED]> added the comment:

Neal Norwitz <[EMAIL PROTECTED]> added the comment:
> 
> Interesting approach.  I was surprised to see the change to the AST, 
> but I understand why you did it.  I think if the AST optimization 
> approach works out well, we will want to have some more general 
> mechanism to communicate these optimization (or other!) hints to the 
> compiler.  It would suck to have to modify the AST each time we 
> wanted to add a new optimization.  You and Tom might have better 
> ideas for how best to achieve that.

I really didn't want to have to change the AST.  The problem was that
there was a feature of the Python bytecode which was not representable
in Python source code.  I don't anticipate future optimizations
requiring changes to the AST, because I now believe every important
feature of the bytecode is representable in the AST.  The one exception
might be if we have a need for arbitrary jumps.  I don't think that
would be useful, but it might conceivably.  In that case, we would need
Goto and Label AST nodes.  

The thing that struck me as ugly was the idea that there's one object
(the optimizer) that knows everything about all optimization operations.
 This seems like a great case for the visitor pattern.  The optimizer
ought to have a list of functions to call for each type of AST node,
each with some private storage space.  But I didn't want to make that
kind of dramatic change without consulting with Tom.

> I'll make some comments that would need to be addressed, but you might
> want to wait making any changes depending on what approach you decide 
> to take.
> 
> The most important missing piece is tests to show that the new code 
> works.

> There are various whitespace issues.  Both whitespace only changes 
> that should be avoided and indentation inconsistencies with the 
> existing code (or so it appears).  The latter could be the way I'm 
> viewing the file or existing problems with tabs.

Fixed, I think.  The original code appears to be somewhat inconsistent
between files in its uses of spaces/tabs, but I think I have now matched
the style of each file.

> In Python/optimize.c, you need to handle the case where the 
> PyDict_New() calls fail.  It looks like currently an undetected error
> can happen during construction.  And on destruction it will crash 
> because the objects will be NULL when calling Py_DECREF.
 
Fixed.  

> All calls like PyDict_SetItem(), PyInt_FromLong(), etc need to handle
> errors.

I'm not exactly sure which "etc" need to handle errors.  Py*_As*? 
Anyway, I changed the ones you mentioned.

> I'll need to study the code a lot more to see how well it behaves. 
> Tests would help a lot with that.

I've added a few.

Added file: http://bugs.python.org/file11957/tlee-ast-optimize-appends-2.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[David Turner]

David Turner <[EMAIL PROTECTED]> added the comment:

Actually, I just noticed a case where the code would do the wrong thing.
 I fixed it and added a test for it.

Added file: http://bugs.python.org/file11958/tlee-ast-optimize-appends-3.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I considered using a datetime.datetime object instead. But it make more 
sense to use a time_t number, like os.stat() and time.time().

About the tests on the gzip format details: I am not an expert of the 
gzip format, but are we sure that the compressed data will always be the 
same?
Otherwise the patch is fine.

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

> I really didn't want to have to change the AST.  The problem was that
> there was a feature of the Python bytecode which was not representable
> in Python source code. 

FWIW, I see exposing bytecodes as an anti-pattern that locks in a
particular implementation in a way that makes it hard to change and hard
to port to other Python implementations.  The current bound method
approach works fine.  Don't really see enough payoff to justify the
extra code and maintenance.

--
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4272] set timestamp in gzip stream

[Jacques Frechet]

Jacques Frechet <[EMAIL PROTECTED]> added the comment:

I'm no expert either.  The output certainly seems to be deterministic
for a given version of zlib, and I'm not aware of any prior versions of
zlib that produce different compressed output.  However, my
understanding is that there is more than one possible compressed
representation of a given uncompressed input, so it's entirely possible
that a past or future version of zlib might produce compressed output
that is different while remaining interoperable.  I have no idea whether
the zlib people care specifically about producing identical compressed
output across versions or not.  It might be a big deal to them, or they
might have other priorities.

I included the third test because I am guessing that the compressed
output probably won't change very soon, and that if it does, it might be
interesting to know that it changed.  If that sounds to you like it
might be more trouble than it's worth, then I think the right thing to
do would be to simply get rid of the third test and keep the first two.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4236] Crash when importing builtin module during interpreter shutdown

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Strange, I can't reproduce the problem with any Python version. Even
py3k doesn't crash with either "import imp" and "import warnings".

$ cat ../issue4236.py
class Crasher(object):
def __del__(self):
print("__del__ called")
import imp

crasher = Crasher()

$ python2.4 issue4236.py
__del__ called
Exception exceptions.ImportError: 'No module named imp' in > ignored

$ python2.5 issue4236.py
__del__ called
Exception exceptions.ImportError: 'No module named imp' in > ignored

$ python2.6 issue4236.py
__del__ called
Exception ImportError: 'No module named imp' in > ignored

$ py3k/python issue4236.py
__del__ called
Exception ImportError: 'No module named imp' in > ignored

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4266] Python 3.0 docs are broken.

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Sorry, but this is still not fixed:

tnow using/cmdline Exception occurred:
  File
"/private/tmp/py3k/dist/Python-3.0rc2/Doc/tools/docutils/parsers/rst/states.py",
line 2055, in run_directive
% (type_name, i, result[i]))
AssertionError: Directive "seealso" returned non-Node object (index 0):
[>, >]
The full traceback has been saved in
/var/folders/by/bycjwwYpGcm-aejnq3kFcTI/-Tmp-/sphinx-err-uh9riS.log,
if you want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to [EMAIL PROTECTED] Thanks!
make[1]: *** [build] Error 1
make: *** [dist] Error 2


Verified on both OS X and Ubuntu Intrepid.  Verified on irc by Christian
Heimes.

--
status: closed -> open

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4266] Python 3.0 docs are broken.

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

r67136 is a workaround found by Christian.  We'll go with this for the
3.9rc2 release and make this a deferred blocker for a proper fix for the
next rc.

--
priority: release blocker -> deferred blocker
resolution: fixed -> 

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4274] Finish what's new in 3.0

[Christian Heimes]

New submission from Christian Heimes <[EMAIL PROTECTED]>:

The what's new section of the 3.0 docs need lots of extra care. It's
short and it doesn't list all PEPs and important changes. Since lot's of
people are coming from 2.5 it may also be a wise idea to list relevant
2.5->2.6 changes.

--
assignee: akuchling
components: Documentation
messages: 75592
nosy: akuchling, barry, christian.heimes, georg.brandl, gvanrossum
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Finish what's new in 3.0
type: feature request
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2306] Update What's new in 3.0

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Raising to deferred blocker.  This will definitely block 3.0rc3.

--
nosy: +barry
priority: high -> deferred blocker

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4274] Finish what's new in 3.0

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

See #2306.

--
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4275] socketserver example code not correctly ported to py3k

[Don MacMillen]

New submission from Don MacMillen <[EMAIL PROTECTED]>:

code examples in socketserver do not run in py3k
Obvious errors with print stmt (not function call)
Less obvious errors with socket.send that does not
accept str type (bytearray works fine). Client example
below shows problems.

import socket
import sys

HOST, PORT = "localhost", 
data = " ".join(sys.argv[1:])

# Create a socket (SOCK_STREAM means a TCP socket)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Connect to server and send data
sock.connect((HOST, PORT))
sock.send(data + "\n")

# Receive data from the server and shut down
received = sock.recv(1024)
sock.close()

print "Sent: %s" % data
print "Received: %s" % received

--
messages: 75595
nosy: macd
severity: normal
status: open
title: socketserver example code not correctly ported to py3k
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4276] IDLE in 2.6 fails to launch

[Jan Schreuder]

New submission from Jan Schreuder <[EMAIL PROTECTED]>:

I downloaded and installed Python 2.6 for Mac OSX 10.4. It installed
Build Applet, Extras, IDLE and Python Launcher in a Python 2.6 folder in
the Applications folder. However, IDLE will not launch. I have Python
2.5 installed. That IDLE version works.

--
components: IDLE
messages: 75596
nosy: JanKarel
severity: normal
status: open
title: IDLE in 2.6 fails to launch
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4276] IDLE in 2.6 fails to launch

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Duplicate of #4017.

--
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4275] socketserver example code not correctly ported to py3k

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority:  -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append

[Thomas Lee]

Thomas Lee <[EMAIL PROTECTED]> added the comment:

Neal said:
> I was surprised to see the change to the AST, but I understand why you
did it.

The problems David ran into here sound like an argument for arbitrary
AST annotations -- an idea that I was toying with around the time
"Const" was introduced. That way the optimizer could provide "hints"
rather than explicitly manipulating the AST in certain cases. The
compiler could then look for those hints and generate code accordingly.

For example, in place of the Const node, we might have a "const"
annotation that's applied to the top-level expression.

I think I went with the Const node because it was less work, but I don't
remember the details. I'll try to dig up the appropriate emails if I
haven't lost them.

David said:
> Fixed, I think.  The original code appears to be somewhat 
> inconsistent between files in its uses of spaces/tabs, ...

Yes, they are inconsistent with tabs/spaces. And it sucks. :)

> The thing that struck me as ugly was the idea that there's one
> object (the optimizer) that knows everything about all
> optimization operations.

That's right, but this is no different from the compiler. Conversely, a
visitor pattern would probably work for both the optimizer and the compiler.

Having said that, I couldn't justify making the AST optimizer a huge
departure from the rest of the code base for the sake of design purity.
I'm not even really sure that it's "design purity" when you do things
inconsistently from one component to the next.

Obviously if there's another sufficiently good argument for the visitor
approach, I'm all ears. But again, if we do that I think we should do it
for the compiler as well. I'm not sure how much support such a change
would have.

--
nosy: +thomas.lee

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com