Re: [Python-Dev] Stop using timeit, use perf.timeit!

[Meador Inge]

On Fri, Jun 10, 2016 at 6:13 AM, Victor Stinner 
wrote:

The second result is a new perf module which includes all "tricks"
> discovered in my research: compute average and standard deviation,
> spawn multiple worker child processes, automatically calibrate the
> number of outter-loop iterations, automatically pin worker processes
> to isolated CPUs, and more.
>

Apologies in advance if this is answered in one of the links you posted, but
out of curiosity was geometric mean considered?

In the compiler world this is a very common way of aggregating performance
results.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99

[Meador Inge]

On Sat, Jun 4, 2016 at 1:11 AM, Benjamin Peterson 
wrote:


> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
> (in so much as GCC and MSVC support them)?
>

+1

# Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Speeding up CPython 5-10%

[Meador Inge]

On Sun, May 15, 2016 at 2:23 AM, Cesare Di Mauro 
wrote:


> Just one thing that comes to my mind: is the stack depth calculation
> routine changed? It was suboptimal, and calculating a better number
> decreases stack allocation, and increases the frame usage.
>

This is still a problem and came up again recently:

http://bugs.python.org/issue26549

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes compatibility with 2.3

[Meador Inge]

On Wed, May 11, 2016 at 11:07 AM, Thomas Heller  wrote:

Cool.  While you're at it, the compatibility restriction for modulefinder
> could also be lifted.


+1

The question of modulefinder actually came up recently*:

http://bugs.python.org/issue26881

-- Meador

* Posting here for reference.  Thomas already knows this as he is on the
issue26881 watch list :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New poll about a macro for safe reference replacing

[Meador Inge]

On Wed, Dec 23, 2015 at 9:08 AM, Nick Coghlan  wrote:


> Within the Python context, the analogy from setattr and setitem at the
> Python level to Py_SETREF at the C level is pretty solid, so it likely
> makes sense to run with that as "good enough".
>
> In regards to Py_MOVEREF, while other languages are starting to pay
> more attention to "MOVE" semantics, we haven't really done so in
> Python yet (moving references in Rust isn't the same thing we're
> talking about here - this is just normal runtime reference counting).
>

Oh.  I misunderstood the intent of the macro before
(from "The macro moves the ownership").  You are right.
Move semantics in C++ and Rust is different.
In this case the ownership is not being moved in the same
sense as though languages.

I withdraw my vote for Py_MOVEREF.  Py_SETREF is fine.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New poll about a macro for safe reference replacing

[Meador Inge]

On Tue, Dec 22, 2015 at 3:58 AM, Serhiy Storchaka 
wrote:

On 21.12.15 23:57, Steve Dower wrote:
>
>> Was Py_MOVEREF (or MOVE_REF) ever suggested?
>>
>
> This would be nice name. The macro moves the ownership. But I think it's
> too late. Otherwise we'll never finish the bikeshedding.


FWIW, I like this name the best.  It is increasingly popular for languages
to talk about moving ownership (e.g. move semantics in C++, Rust, etc...).

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Generated Bytecode ...

[Meador Inge]

On Fri, Oct 23, 2015 at 3:23 AM, Victor Stinner
 wrote:

> Note: I propose "noopt" because we already have "optimization level 0"
> which still uses optimizations, it's the default mode. It's different
> than gcc -O0 which really disables all optimizations. I already prefix
> the "noopt" suffix for .pyc files than "opt--1" proposed by Brett in
> http://bugs.python.org/issue2506

Strictly speaking, this isn't completely true.  Most (all?) C/C++
compilers do some level of optimization when they are "disabled".
GCC/Clang, for example, both will do some form of constant folding
with -O0.  The compilers are just *much* less aggressive with the
primary goal of making the debugging experience much more enjoyable.

The situation here sounds similar -- we want an option to provide a
better debugging and tracing experience, which seems like a very
reasonable idea to me.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Meador Inge]

On Thu, Jul 9, 2015 at 7:41 AM, Guido van Rossum gu...@python.org wrote:

 On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka storch...@gmail.com
 wrote:

 On 08.07.15 01:45, Raymond Hettinger wrote:

 P.S.  I don't think python-dev post was necessary or helpful (and I still
 haven't had a chance to read the whole thread).  It would have been
 sufficient to assign the tracker entry back to me.


 Well, I'll open new issue and assign it to you for every your commit that
 looks questionable to me.


 That sounds like a fine solution, and a good conclusion of the thread.

I don't have a very strong opinion on the solution, but should the dev guide
be updated to clarify the feelings expressed about the mailing lists in this
thread?  My interpretation of the dev guide always left me with the feeling
that following python-dev was expected for Python core devs:

  * https://docs.python.org/devguide/communication.html#communication

  * https://docs.python.org/devguide/coredev.html#mailing-lists

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] .clinic.c vs .c.clinic

[Meador Inge]

On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings la...@hastings.org wrote:

 Contestant 1: Add .clinic.h

 foo.c - foo.c.clinic.h
 foo.h - foo.h.clinic.h

 -0

  Contestant 2: Add .ac.h

 foo.c - foo.c.ac.h
 foo.h - foo.h.ac.h

 -1

  Contestant 3: Add .clinic

 foo.c - foo.c.clinic
 foo.h - foo.h.clinic

 -1 (This will break too many tools in the C/C++ tools ecosystem and I am
not convinced by any of the arguments given those far.)

  Contestant 4: Put in clinic directory, add .h

 foo.c - clinic/foo.c.h
 foo.h - clinic/foo.h.h

 +1

  Contestant 5: Put in __clinic__ directory, add .h

 foo.c - __clinic__/foo.c.h
 foo.h - __clinic__/foo.h.h

 -1 (clinic without the dunders more clear for a directory name.)

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Changing Clinic's output

[Meador Inge]

On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou solip...@pitrou.net wrote:

On Tue, 14 Jan 2014 12:22:12 -0800
 Larry Hastings la...@hastings.org wrote:
 
  https://bitbucket.org/larry/clinic-buffer-samples/src
 
  In it I converted Modules/_pickle.c four different ways.  There's a
  README, please read it.

 I'm +1 on the sidefile approach. +0 on the various buffer approaches.
 -0.5 on the current sprinkled everywhere approach.


After converting a few modules, I feel about the same.  The sprinkling does
clutter
the file.  Although, I do wonder if we can simplify things a bit for the
sideline file
by using macros and headers.  You could write the original definition like:

  /*[clinic input begin]
  _pickle.PicklerMemoProxy.copy

self: PicklerMemoProxyObject

  Copy the memo to a new object.
  [clinic input end]*/
  static PyObject *
  _PICKLE_PICKLERMEMOPROXY_COPY(PyObject *self, PyObject
*Py_UNUSED(ignored))
  {
  ...
  }

and then generate a header like:

  PyDoc_STRVAR(_pickle_PicklerMemoProxy_copy__doc__,
  copy()\n
  Copy the memo to a new object.);

  #define _PICKLE_PICKLERMEMOPROXY_COPY_METHODDEF\
  {copy, (PyCFunction)_pickle_PicklerMemoProxy_copy, METH_NOARGS,
_pickle_PicklerMemoProxy_copy__doc__},

  static PyObject *
  _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self);

  #define _PICKLE_PICKLERMEMOPROXY_COPY(a, b) \
  _pickle_PicklerMemoProxy_copy(PyObject *self, PyObject
*Py_UNUSED(ignored)) \
  { \
  PyObject *return_value = NULL; \
 \
  return_value =
_pickle_PicklerMemoProxy_copy_impl((PicklerMemoProxyObject *)self); \
 \
  return return_value; \
  } \
\
  static PyObject * \
  _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self) \

This way the docstring, method def, and argument parsing code is out of the
way, but
you still retain the helpful comments in the implementation file.  I am
pretty sure this
gets around the where do I inject the side file part too.  You also don't
have to do
much more editing than the original scheme: write the clinic comment,
#iinclude a
header, and then apply the macro.

That being said, this is somewhat half baked and some folks don't like
macros.  I just
wanted to throw it out there since it seems like a reasonable compromise.

FWIW, I have worked on several large programs that generate C header and
implementation
files on the side and it has never bothered me that much.  Well, unless,
something goes
wrong :-)

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 128 bit integer support

[Meador Inge]

On Wed, Dec 4, 2013 at 8:15 AM, Antoine Pitrou solip...@pitrou.net wrote:

Aren't you talking about the struct module? In ctypes, it seems it
 would be sufficient to add a c_int128 type (and/or c_uint128).


Even in ctypes these codes are used internally for the field descriptors.
For ctypes c_int128 seems reasonable to me.  We already have support for 
for 8-bit, 16-bit, 32-bit, and 64-bit fixed sized integer types with
comparable names.  The struct module has the notion of a standard size
where the size is fixed, but we default to native.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

[Meador Inge]

On Thu, Dec 20, 2012 at 2:23 PM, Barry Warsaw ba...@python.org wrote:

 On Dec 20, 2012, at 02:54 PM, Trent Nelson wrote:

On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote:
 I'll work on setting the ARM boards up next week.

Does anyone have a preference regarding the operating system?  There
are a bunch of choices listed here:

http://www.omappedia.org/wiki/Main_Page

As long as it can run a recent sshd and zsh, I have no preference.

 Well, I'm biased of course, but Ubuntu should be easy to install and should
 run just fine AFAIK.  I'm running 12.10 on my ARM buildbot (an iMX.53 board).

+1 for Ubuntu.  I have setup a PandaBoard at home with Ubuntu and
built/tested Python
with it.  The installation was very easy.

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] AST optimizer implemented in Python

[Meador Inge]

On Sat, Aug 11, 2012 at 1:30 PM, Victor Stinner
victor.stin...@gmail.com wrote:

 Hi,

 I started to implement an AST optimizer in Python. It's easy to create
 a new AST tree, so I'm surprised that I didn't find any existing
 project.

 https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py

Very cool.

 To test its peephole optimizations (by checking manually its final
 bytecode), I wrote a patch for Python to disable Python internal
 peephole optimizer (on bytecode):
 https://bitbucket.org/haypo/misc/src/tip/python/compile_disable_peephole.patch

 --

 There is BytecodeAssembler [1], but it seems to be specialized on
 bytecode. There are (at least?) 3 different issues to implement an AST
 optimizer, but in C, not in Python:

 http://bugs.python.org/issue1346238
 http://bugs.python.org/issue10399
 http://bugs.python.org/issue11549

I read through the issues a while back and each is interesting in its own
right.  However, each is a specific implementation that is somewhat general,
but geared towards one optimization (folding, inlining, etc...).

ISTM, that we need to step back a bit and define a what an AST
optimizer for Python should look like (or even if it really makes any
sense at all).  I imagine having some facilities to manage and add new
passes would be useful, for instance.  I think this work probably merits a
PEP (considering we essentially have four competing implementations for
AST optimization now).

This is an interesting project and I would happily volunteer to help flesh
out the details of a prototype and working on a PEP.

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 releases

[Meador Inge]

On Thu, Jul 26, 2012 at 1:50 PM, Thomas Heller thel...@ctypes.org wrote:

 So, I have uploaded a patch and asked for review (since I'm not 1000%
 sure that it is absolutely correct):

 http://bugs.python.org/issue15459

I'll take a look at this in the next few days.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 - default): Merge #15232: correctly mangle From lines in MIME preamble and epilogue

[Meador Inge]

On Mon, Jul 23, 2012 at 12:34 AM, Meador Inge mead...@gmail.com wrote:

 On Sun, Jul 22, 2012 at 8:55 PM, r.david.murray
 python-check...@python.org wrote:

 http://hg.python.org/cpython/rev/80b81658455b
 changeset:   78246:80b81658455b
 parent:  78244:c43d73277756
 parent:  78245:b97f65f2298d
 user:R David Murray rdmur...@bitdance.com
 date:Sun Jul 22 21:53:54 2012 -0400
 summary:
   Merge #15232: correctly mangle From lines in MIME preamble and epilogue

 files:
   Lib/email/generator.py|  12 -
   Lib/test/test_email/test_email.py |  22 +++
   Misc/NEWS |   3 ++
   3 files changed, 35 insertions(+), 2 deletions(-)

 I'm not quite sure what happened, but something seems to have gone wrong
 with this merge.  After doing the following while on the default branch:

 $ hg merge 3.2

 I see:

 $ hg st
 M Lib/email/generator.py
 M Lib/test/test_email/test_email.py
 M Misc/NEWS

 and a bunch of conflicts in 'Misc/NEWS'.

Hmmm, actually it looks like this head merge that Senthil performed:
http://hg.python.org/cpython/rev/af2e044609ca.

Anyway, I resolved the conflicts.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 - default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

[Meador Inge]

On Mon, Jul 23, 2012 at 11:17 AM, jesus.cea python-check...@python.org wrote:

 http://hg.python.org/cpython/rev/b9a3ed1b14b9
 changeset:   78260:b9a3ed1b14b9
 parent:  78257:03063e718f5f
 parent:  78259:1911e192af0d
 user:Jesus Cea j...@jcea.es
 date:Mon Jul 23 18:16:18 2012 +0200
 summary:
   MERGE: Better test for Issue #15402: Add a __sizeof__ method to 
 struct.Struct

 files:
   Doc/ACKS.txt|  1 +
   Lib/test/test_struct.py |  8 
   2 files changed, 5 insertions(+), 4 deletions(-)

Jesús,

Doc/ACKS.txt is *only* for acknowledging documentation contributions.
Serhiy is already in Misc/ACKS.  No need to add him to Doc/ACKS.txt.

As for the tests, I intentionally kept them the way that Serhiy contributed
them -- using = instead of .  I kept them this way because we also
discussed in issue14596 the prospect of optimizing the way repeat counts
are handled.  These tests would start failing if (when) that optimization
happens.

So, neither of these changes are really necessary.  Although, it wouldn't
hurt to have *additional* tests using the  relation.


 diff --git a/Doc/ACKS.txt b/Doc/ACKS.txt
 --- a/Doc/ACKS.txt
 +++ b/Doc/ACKS.txt
 @@ -205,6 +205,7 @@
 * Anthony Starks
 * Greg Stein
 * Peter Stoehr
 +   * Serhiy Storchaka
 * Mark Summerfield
 * Reuben Sumner
 * Kalle Svensson
 diff --git a/Lib/test/test_struct.py b/Lib/test/test_struct.py
 --- a/Lib/test/test_struct.py
 +++ b/Lib/test/test_struct.py
 @@ -575,12 +575,12 @@
  def test_sizeof(self):
  self.assertGreater(sys.getsizeof(struct.Struct('BHILfdspP')),
 sys.getsizeof(struct.Struct('B')))
 -self.assertGreaterEqual(sys.getsizeof(struct.Struct('123B')),
 +self.assertGreater(sys.getsizeof(struct.Struct('123B')),
  sys.getsizeof(struct.Struct('B')))
 -self.assertGreaterEqual(sys.getsizeof(struct.Struct('B' * 123)),
 +self.assertGreater(sys.getsizeof(struct.Struct('B' * 1234)),
  sys.getsizeof(struct.Struct('123B')))
 -self.assertGreaterEqual(sys.getsizeof(struct.Struct('123xB')),
 -sys.getsizeof(struct.Struct('B')))
 +self.assertGreater(sys.getsizeof(struct.Struct('1234B')),
 +sys.getsizeof(struct.Struct('123B')))

  def test_main():
  run_unittest(StructTest)

 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins




-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doc/ACKS and Misc/ACKS

[Meador Inge]

On Mon, Jul 23, 2012 at 12:17 PM, Antoine Pitrou solip...@pitrou.net wrote:

 On Mon, 23 Jul 2012 18:38:30 +0200
 Jesus Cea j...@jcea.es wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 23/07/12 18:27, Meador Inge wrote:
  Doc/ACKS.txt is *only* for acknowledging documentation
  contributions. Serhiy is already in Misc/ACKS.  No need to add him
  to Doc/ACKS.txt.

 Oh, I missed that. Thanks for the head up.

 That said, we could probably merge Doc/ACKS and Misc/ACKS (*). There
 doesn't seem to be any strong argument for separating doc contributions
 from other contributions.

 (*) I think perhaps Éric already proposed it at some point

+1

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 - default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

[Meador Inge]

On Mon, Jul 23, 2012 at 11:38 AM, Jesus Cea j...@jcea.es wrote:

 As for the tests, I intentionally kept them the way that Serhiy
 contributed them -- using = instead of .  I kept them this way
 because we also discussed in issue14596 the prospect of optimizing
 the way repeat counts are handled.  These tests would start failing
 if (when) that optimization happens.

 The problem is that if we do =, then an unpatched python
 interpreter could pass the test too. So we are not actually testing
 the feature.

We are testing the feature because the first test looks like:

self.assertGreater(sys.getsizeof(struct.Struct('BHILfdspP')),
   sys.getsizeof(struct.Struct('B')))

The way things were written 'sys.getsizeof' would returns the same
answer regardless of the format string.

The remaining tests looked like:

self.assertGreaterEqual(sys.getsizeof(struct.Struct('123B')),
sys.getsizeof(struct.Struct('B')))
self.assertGreaterEqual(sys.getsizeof(struct.Struct('B' * 123)),
sys.getsizeof(struct.Struct('123B')))
self.assertGreaterEqual(sys.getsizeof(struct.Struct('123xB')),
sys.getsizeof(struct.Struct('B')))

and while they didn't fail without the patch I felt they were still useful in
documenting that there is nothing that guarantees 'sizeof(123B)  sizeof(B)'
'sizeof(B * 123)  sizeof(123B)', or 'sizeof(123xB)  sizeof(B)'.

 If the repeat counters are going to be optimized, the obvious step
 would be to upgrade the test to do something like BHHIL instead of
 123B. I would wait until this feature is implemented to update the test.

That is what the first test basically already does :-)

 What do you think?.

It isn't that big of a deal.  We can just leave the tests as you changed them.
In the future it would probably be better to hash this stuff out in the tracker.
The patch was out for review for several days ...

Thanks,

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 - default): Merge #15232: correctly mangle From lines in MIME preamble and epilogue

[Meador Inge]

On Sun, Jul 22, 2012 at 8:55 PM, r.david.murray
python-check...@python.org wrote:

 http://hg.python.org/cpython/rev/80b81658455b
 changeset:   78246:80b81658455b
 parent:  78244:c43d73277756
 parent:  78245:b97f65f2298d
 user:R David Murray rdmur...@bitdance.com
 date:Sun Jul 22 21:53:54 2012 -0400
 summary:
   Merge #15232: correctly mangle From lines in MIME preamble and epilogue

 files:
   Lib/email/generator.py|  12 -
   Lib/test/test_email/test_email.py |  22 +++
   Misc/NEWS |   3 ++
   3 files changed, 35 insertions(+), 2 deletions(-)

I'm not quite sure what happened, but something seems to have gone wrong
with this merge.  After doing the following while on the default branch:

$ hg merge 3.2

I see:

$ hg st
M Lib/email/generator.py
M Lib/test/test_email/test_email.py
M Misc/NEWS

and a bunch of conflicts in 'Misc/NEWS'.


 diff --git a/Lib/email/generator.py b/Lib/email/generator.py
 --- a/Lib/email/generator.py
 +++ b/Lib/email/generator.py
 @@ -252,7 +252,11 @@
  msg.set_boundary(boundary)
  # If there's a preamble, write it out, with a trailing CRLF
  if msg.preamble is not None:
 -self.write(msg.preamble + self._NL)
 +if self._mangle_from_:
 +preamble = fcre.sub('From ', msg.preamble)
 +else:
 +preamble = msg.preamble
 +self.write(preamble + self._NL)
  # dash-boundary transport-padding CRLF
  self.write('--' + boundary + self._NL)
  # body-part
 @@ -270,7 +274,11 @@
  self.write(self._NL + '--' + boundary + '--')
  if msg.epilogue is not None:
  self.write(self._NL)
 -self.write(msg.epilogue)
 +if self._mangle_from_:
 +epilogue = fcre.sub('From ', msg.epilogue)
 +else:
 +epilogue = msg.epilogue
 +self.write(epilogue)

  def _handle_multipart_signed(self, msg):
  # The contents of signed parts has to stay unmodified in order to 
 keep
 diff --git a/Lib/test/test_email/test_email.py 
 b/Lib/test/test_email/test_email.py
 --- a/Lib/test/test_email/test_email.py
 +++ b/Lib/test/test_email/test_email.py
 @@ -1283,6 +1283,28 @@
  Blah blah blah
  )

 +def test_mangle_from_in_preamble_and_epilog(self):
 +s = StringIO()
 +g = Generator(s, mangle_from_=True)
 +msg = email.message_from_string(textwrap.dedent(\
 +From: f...@bar.com
 +Mime-Version: 1.0
 +Content-Type: multipart/mixed; boundary=XXX
 +
 +From somewhere unknown
 +
 +--XXX
 +Content-Type: text/plain
 +
 +foo
 +
 +--XXX--
 +
 +From somewhere unknowable
 +))
 +g.flatten(msg)
 +self.assertEqual(len([1 for x in s.getvalue().split('\n')
 +  if x.startswith('From ')]), 2)


  # Test the basic MIMEAudio class
 diff --git a/Misc/NEWS b/Misc/NEWS
 --- a/Misc/NEWS
 +++ b/Misc/NEWS
 @@ -52,6 +52,9 @@
  Library
  ---

 +- Issue #15232: when mangle_from is True, email.Generator now correctly 
 mangles
 +  lines that start with 'From' that occur in a MIME preamble or epilogue.
 +
  - Issue #15094: Incorrectly placed #endif in _tkinter.c.
Patch by Serhiy Storchaka.


 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins




-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] VS 11 Express is Metro only.

[Meador Inge]

On Fri, May 25, 2012 at 7:06 AM,  mar...@v.loewis.de wrote:

 I hereby predict that Microsoft will revert this decision, and that VS
 Express
 11 will be able to build CPython.

And your prediction was right on :-) :
http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx.

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] dir() in inspect.py ?

[Meador Inge]

On Tue, May 15, 2012 at 3:13 PM, Christian Tismer tis...@stackless.com wrote:

 Is the usage of dir() correct in this context or is the doc right?
 It would be nice to add a sentence of clarification if the use of
 dir() is in fact the correct way to implement inspect.

There is already a note in the inspect.getmembers documentation
(http://docs.python.org/library/inspect.html#inspect.getmembers):


Note

getmembers() does not return metaclass attributes when the argument is
a class (this behavior is inherited from the dir() function).


In any case, open a tracker issue if you think the documentation needs
to be improved or that there might be a bug.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS X build break

[Meador Inge]

On Sat, Feb 4, 2012 at 7:35 AM, Ned Deily n...@acm.org wrote:

 Chances are you are using llvm-gcc-4.2, the default CC for Xcode 4.2.

Yup:

motherbrain:python meadori$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.7.2
BuildVersion:   11C74
motherbrain:python meadori$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

motherbrain:python meadori$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

 There is a critical compile error with it (Issue13241) when building
 default (3.3).  My current recommendations (despite some test failures):

 - for OS X 10.7.x, use the latest released Xcode, currently Xcode 4.2.1,
 and build with clang and debug:

 ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7

That worked.  Thanks!

 Unfortunately, testing and sorting out the issues with the current OS X
 compilers has taken much much longer than anticipated, primarily because
 it's a big task and, until several days ago, I have had no time to
 devote to it.  But I'm making progress now with installer builds
 completed for all of default, 3.2-tip, 3.2.2, 2.7-tip, and 2.7.2, each
 with all of the major compiler combinations on 10.5, 10.6 (Xcode 3.2 and
 4.2), and 10.7 (4.1 and 4.2); the tests are running now on each of the
 applicable environments (that will take about another week to complete).
 Realistically, we should be able to have everything tested, fixed, and
 documented by the end of the PyCon sprints next month.  We will also
 have some recommendations for buildbot changes.

I volunteer to help out if there is anything I can do.

 BTW, the current test failures with clang without pydebug include a
 number of ctypes test failures (in ctypes.test.test_cfuncs.CFunctions).
 If anyone has time to further investigate those, it would be very
 helpful (Issue13370).

I will look into those.

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OS X build break

[Meador Inge]

On Sat, Dec 31, 2011 at 5:56 PM, Guido van Rossum gu...@python.org wrote:

 PS. I would propose a specific fix but I can't seem to build a working
 CPython from the trunk on my laptop (OS X 10.6, Xcode 4.1). I get this error
 late in the build:

 ./python.exe -SE -m sysconfig --generate-posix-vars
 Fatal Python error: Py_Initialize: can't initialize sys standard streams
 Traceback (most recent call last):
   File /Users/guido/cpython/Lib/io.py, line 60, in module
 make: *** [Lib/_sysconfigdata.py] Abort trap

I am having this problem now too.  I am running OS X 10.7.2.
3.2 still builds for me, but I can't build default.

Did you ever get past it?  Anyone else seeing this?

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.1): Closes #13807: Now checks for sys.stderr being there before writing to it.

[Meador Inge]

On Fri, Jan 20, 2012 at 5:32 AM, vinay.sajip python-check...@python.org wrote:
 http://hg.python.org/cpython/rev/73dad4940b88
 changeset:   74538:73dad4940b88
 branch:      3.1

I thought that the 3.1 branch is in security mode?  Is this a security
related fix?
From my brief scan of the changeset, it doesn't seem to be.

 parent:      74253:fb5707168351
 user:        Vinay Sajip vinay_sa...@yahoo.co.uk
 date:        Fri Jan 20 11:23:02 2012 +
 summary:
  Closes #13807: Now checks for sys.stderr being there before writing to it.

 files:
  Lib/logging/__init__.py |  2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


 diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py
 --- a/Lib/logging/__init__.py
 +++ b/Lib/logging/__init__.py
 @@ -721,7 +721,7 @@
         You could, however, replace this with a custom handler if you wish.
         The record which was being processed is passed in to this method.
         
 -        if raiseExceptions:
 +        if raiseExceptions and sys.stderr:  # see issue 13807
             ei = sys.exc_info()
             try:
                 traceback.print_exception(ei[0], ei[1], ei[2], None, 
 sys.stderr)

 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins




-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA support has landed

[Meador Inge]

On Tue, Nov 29, 2011 at 4:59 PM, Nadeem Vawda nadeem.va...@gmail.com wrote:

 liblzma-dev; on Fedora I believe the correct package is xz-devel.

xz-devel is right.  I just verified a build of the new module on a
fresh F16 system.

-- 
Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python -m tokenize in 3.x ?

[Meador Inge]

Hi All,

I have been investing some 'tokenize' bugs recently.  As a part of
that investigation I was trying to use '-m tokenize', which works
great in 2.x:

[meadori@motherbrain cpython]$ python2.7 -m tokenize test.py
1,0-1,5:NAME'print'
1,6-1,21:   STRING  'Hello, World!'
1,21-1,22:  NEWLINE '\n'
2,0-2,0:ENDMARKER   ''

In 3.x, however, the functionality has been removed and replaced with
some hard-wired test code:

[meadori@motherbrain cpython]$ python3 -m tokenize test.py
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3),
line='def parseline(self, line):')
TokenInfo(type=1 (NAME), string='parseline', start=(1, 4), end=(1,
13), line='def parseline(self, line):')
TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14),
line='def parseline(self, line):')
...

Why is this?  I found the commit where the functionality was removed
[1], but no explanation.  Any objection to adding this feature back?

[1] http://hg.python.org/cpython/rev/51e24512e305/

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

[Meador Inge]

On Sat, Aug 27, 2011 at 11:58 PM, Terry Reedy tjre...@udel.edu wrote:

 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 been able to work on it since the beginning of 2010 and
 has formally withdrawn as maintainer. No one else that I know of has taken
 his place.

I am trying to work through getting these issues resolved.  The hard part so
far has been getting reviews and commits.  The follow patches are awaiting
review (the patch for issue 11241 has been accepted, just not applied):

1. http://bugs.python.org/issue9041
2. http://bugs.python.org/issue9651
3. http://bugs.python.org/issue11241

I am more than happy to keep working through these issues, but I need some
help getting the patches actually applied since I don't have commit rights.

-- 
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API refactoring tracker field for Python4

[Meador Inge]

On Fri, Jan 7, 2011 at 11:20 AM, anatoly techtonik techto...@gmail.com wrote:
 This happened, because of poor bug management, where community doesn't
 play any role in determining which issues are desired.
 This mostly because of limitation of our tracker and desire of people
 to extend it to get damn stars, module split, sorting, digging and
 tagging options.

Adding a few new features to the issue tracker isn't going to make the
forgotten changes problems (assuming that it is, indeed, a problem)
that you mentioned magically go away.  Tools alone don't fix problems,
there are people using the tools involved too, and getting people to
use tools effectively is much more difficult.  Adding more features to
a tool that is not be used effectively, just makes it be used even
less effectively.

I speak from recent experiences of helping roll out JIRA to a 50 man
engineering team.  The one regret that I have is that we turned too
many stars, bells, and whistles on instead of helping people create
good issue reports.  Some times there is very good reason to add such
features, but significant amount of data should be there backing that
decision up.  It is better to wait until the data is there pointing to
the problem.

I grabbed the following descriptions from a reply from another part of
this thread:

 Stars:
  go http://code.google.com/p/support/issues/list
  find Stars column
  guess

JIRA has voting, which I have used.  However, it boils back to the
tools vs. people problem.  Enabling voting is useless if no one honors
the votes.  I have seen this happen.  You must have community support.

 Module split:
  try to get all issues for 'os' module
  try to subscribe to all commits for 'CGIHTTPServer'

I have myself wanted this as well before.  However, the downside is
that having more options to select from will inevitably increase the
amount of incorrect selections that are made.  Fewer choices, better
data.  I would rather have better data.

 Sorting:
 click on column titles in bug tracker search results

You can just do sorted searches, right?

 Tagging:
  as a tracker user, try to add tag 'easy' to some easy issue

Are you suggesting that *any* tracker user be allowed to place
arbitrary tags on an issue?  If so, then I think that would be more
confusing as there would be no uniformity to the entries.  I like the
keywords in use on the tracker today better.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] issue2180 and using 'tokenize' with Python 3 'str's

[Meador Inge]

On Tue, Sep 28, 2010 at 7:09 AM, Nick Coghlan ncogh...@gmail.com wrote:

 A feature request on the tracker is the best way to make that happen.


Done - http://bugs.python.org/issue9969.  Thanks for the feedback everyone.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] issue2180 and using 'tokenize' with Python 3 'str's

[Meador Inge]

Hi All,

I was going through some of the open issues related to 'tokenize' and ran
across 'issue2180'.  The reproduction case for this issue is along the lines
of:

  tokenize.tokenize(io.StringIO(if 1:\n \\\n #hey\n print 1).readline)

but, with 'py3k' I get:

 tokenize.tokenize(io.StringIO(if 1:\n  \\\n  #hey\n  print
1).readline)
Traceback (most recent call last):
  File stdin, line 1, in module
  File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 360, in
tokenize
encoding, consumed = detect_encoding(readline)
  File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 316, in
detect_encoding
if first.startswith(BOM_UTF8):
TypeError: Can't convert 'bytes' object to str implicitly

which, as seen in the trace, is because the 'detect_encoding' function in
'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string
to tokenize 'first' (a 'str' object).  It seems to me that strings should
still be able to be tokenized, but maybe I am missing something.

Is the implementation of 'detect_encoding' correct in how it attempts to
determine an encoding or should I open an issue for this?

---
Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reindenting patches

[Meador Inge]

On Wed, May 5, 2010 at 8:10 AM, Antoine Pitrou solip...@pitrou.net wrote:

 For the record, I've added to the untabify script a patch rewriting option
 (-p) which reindents all patch hunks for C files containing tabs. It
 should
 minimize manual reformatting work with existing patches.


I just tried '-p' with a local patch that I had created
pre-whitespace-fixes.  It worked like a charm.  Thanks Antoine.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.

[Meador Inge]

 In other words, I think the goal is not just to add new developers to
 the community, but to continue to build a strong community of developers.

FWIW, from a Python community newbie that has submitted a few patches and
commented on the tracker for a few months, I agree with this statement and
the way things are now.  I was attracted to the Python community, in part,
because the development model seemed so mature and well specified.  I felt
that it was clear from the current documented policies on how I could
contribute -- do these things and get these privileges.  That simple.

Moreover, by having the different stages (do these things to get
tracker privileges, do these other things to get commit privileges, etc...)
it was more clear how I could set personal milestones for myself to become a
contributing member of the community.  I find these stages useful for the
current community to somewhat gauge an unknown person's ability, but also
for that unknown person to develop and learn about the community at a
reasonable pace.

Yes, I know that the issue in question involves not a _completely_ unknown
person, but someone who is known by an existing member of the community.
 However, this is about a community choice and not just one person's choice.


Not to mention the fact that most anyone could have already submitted the
amount of comments needed to get enhanced tracker privileges in the amount
of time that has been spent on this thread :-)

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++

[Meador Inge]

On Fri, Mar 12, 2010 at 4:03 PM, Antoine Pitrou solip...@pitrou.net wrote:

 Le Fri, 12 Mar 2010 13:29:09 -0600,
 s...@pobox.com a écrit :
 
  Traditionally Python has run on some (minority) platforms where C++
  was unavailable.

 Is this concern still valid? We are in the 2010s now.
 I'm not saying I want us to put some C++ in the core interpreter, but
 the portability argument sounds a little old...


One area where this _may_ be a problem is with embedded systems.  I believe
there are some instances where folks have built Python into an embedded
system (with an RTOS say VxWorks, Symbian, QNX Neutrino, Nucleus, etc...)
where C++ is not always the easiest to develop in.  Admittedly, though,
these types of systems are by far a minority with respect to Python.  Just
thought I would mention it anyhow.

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3188: Implementation Questions

[Meador Inge]

On Sat, Feb 27, 2010 at 11:20 AM, Thomas Heller thel...@ctypes.org wrote:

 See issue 887237:

 http://bugs.python.org/issue887237


Thanks for the link Thomas.  Since there is already interest in adding
arithmetic to ctypes, perhaps that is an option.  One question that raises
in my mind, though, is should only 'long double' unpack to a ctype in that
case?  Or should all items unpack to ctypes now?  It seems to me that you
would want everything to unpack to types from the same family (e.g. Python
builtins or ctypes).  This seems conceptually cleaner and the
interoperability between types in the same family are (or can be in the
case of modifying ctypes) more clearly defined.

Thanks,

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3188: Implementation Questions

[Meador Inge]

On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:

 Meador Inge wrote:

  3. Using Decimal keeps the desired precision,


 Well, sort of, but then you end up doing arithmetic in
 decimal instead of binary, which could give different
 results.


Even with the user-defined precision capabilities of the 'Decimal' class?
In other words, can I create an instance of a 'Decimal' that behaves (in all
operations: arithmetic, comparison, etc...) exactly as the extended double
precision type offered by a given machine?

Maybe the solution is to give ctypes long double objects
 the ability to do arithmetic?


Maybe, but then we would have to give all numeric 'ctypes' the ability to do
arithmetic -- which may be more than we want.


-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 3188: Implementation Questions

[Meador Inge]

Hi All,

Recently some discussion began in the issue 3132 thread (
http://bugs.python.org/issue3132) regarding
implementation of the new struct string syntax for PEP 3118.  Mark Dickinson
suggested that I bring the discussion on over to Python Dev.  Below is a
summary
of the questions\comments from the thread.

Unpacking a long-double
===

1. Should this return a Decimal object or a ctypes 'long double'?
2. Using ctypes 'long double' is easier to implement, but precision is
lost when needing to do arithmetic, since the value for cytpes 'long
double'
is converted to a Python float.
3. Using Decimal keeps the desired precision, but the implementation would
be non-trivial and architecture specific (unless we just picked a
fixed number of bytes regardless of the architecture).
4. What representation should be used for standard size and alignment?
IEEE 754 extended double precision?

Pointers
==

1. What is a specific pointer?  For example, is 'd' is a pointer to a
double?
2. How would unpacking a pointer to a Python Object work out?  Given an
address how would the appropriate object to be unpacked be determined?
3. Can pointers be nested, e.g. 'd' ?
4. For the 'X{}' format (pointer to a function), is this supposed to mean a
Python function or a C function?


String Syntax
==

The syntax seems to have transcended verbal description.  I think we
need to put forth a grammar.  There are also some questions regarding
nesting
levels and mixing specifiers that could perhaps be answered more clearly by
having a grammar:

   1. What nesting level can structures have? Arbitrary?
   2. The new array syntax claims multi-dimensional array of whatever
follows.
  Truly whatever? Arrays of structures? Arrays of pointers?
   3. How do array specifiers and pointer specifiers mix?  For example,
  would '(2, 2)d' be a two-by-two array of pointers to doubles?
  What about '(2, 2)d'?  Is this a pointer to an two-by-two array of
  doubles?

An example grammar is contained in a diff against the PEP attached to this
mail.  NOTE:  I am *not* actually submitting a patch against the PEP.  This
was just the clearest way to present the example grammar.

Use Cases


   1. What are the real world use cases for these struct string extensions?
  These should be fleshed out and documented.


-- Meador


pep-3118.diff
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Executing zipfiles and directories (was Re: PyCon Keynote)

[Meador Inge]

On Tue, Jan 26, 2010 at 9:35 PM, David Lyon david.l...@pythontest.orgwrote:
 One problem is that in many places, users are trained specifically
 under windows to *never* run anything in a zip file. As it might
 contain a virus and bring down the whole company network.

I have even hit cases where Windows flat out blocks me from opening a zip
file.  I believe XP SP2 added some security functionality [1] that,
depending on how the zip file is procured, blocks one from opening the
file.  It just throws the error: Windows has blocked access to this file.

Regards,

-- Meador

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;883260
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Meador Inge]

 We really do need precise descriptions of the problems so we can avoid
them.

Initialization of objects with static storage duration typically get a bad
wrap for two main reasons: (1) each toolchain implements them differently
(but typically by storing initialization thunks in a table that is walked by
the C++RT before entry to 'main'), which may lead to subtle differences when
compiling for different platforms and (2) there is no guaranteed
initialization order across translation unit boundaries.

(1) is just a fact of multi-platform development.  (2) is a bit more
interesting.  Consider two translation units 'a.cpp' and 'b.cpp':

   // a.cpp
   T { T() {} };
   ...
   static T obj1;

   // b.cpp
   S { S() {} };
   ...
   static S obj2;

When 'obj1' and 'obj2' get linked into the final image there are no
guarantees on whose constructor (T::T or S::S) will be called first.
Sometimes folks write code where this initialization order matters.  It may
cause strange behavior at run-time that is hard to pin down.  This may not
be a problem in the LLVM code base, but it is the typical problem that C++
devs run into with initialization of objects with static storage duration.

Also related to reduced code size with C++ I was wondering whether or not
anyone has explored using the ability of some toolchains to remove unused
code and data?  In GCC this can be enabled by compiling with
'-ffunction-sections' and '-fdata-sections' and linking with
'--gc-sections'.  In MS VC++ you can compile with '/Gy' and link with
'/OPT'.  This feature can lead to size reductions sometimes with C++ due to
things like template instantation causing multiple copies of the same
function to be linked in.  I played around with compiling CPython with this
(gcc + Darwin) and saw about a 200K size drop.  I want to try compiling all
of U-S (e.g. including LLVM) with these options next.

Thanks,

-- Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com