Re: [Python-Dev] Pass possibly imcompatible options to distutil's ccompiler

[Lukas Lueg]

Distutils2 is not really an option right now as it is not found on
major Linux distributions, FreeBSD or MacOS X

2011/4/12 Nick Coghlan :
> On Tue, Apr 12, 2011 at 7:41 AM, Lukas Lueg  wrote:
>> Any other ideas on how to solve this in a better way?
>
> Have you tried with distutils2? If it can't help you, it should really
> be looked into before the packaging API is locked for 3.3.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Djoume Salvetti]

Hi there,


When calling pdb.set_trace() from within a function, it seems to be
impossible to rebind any local variables:


http://paste.pound-python.org/show/5150/


I couldn't find anything in the documentation about this, should I report a
bug?

-- 
Djoume Salvetti
Director of Development

T:416.601.1999 x 249
www.trapeze.com twitter: trapeze
175 Bloor St. E., South Tower, Suite 900
Toronto, ON M4W 3R8
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Alexander Belopolsky]

On Tue, Apr 12, 2011 at 11:15 AM, Djoume Salvetti  wrote:
..
> When calling pdb.set_trace() from within a function, it seems to be 
> impossible to rebind any local variables:
>

Works for me (using latest HG clone):

$ cat test.py
gv = 1

def f():
lv = 1
import pdb; pdb.set_trace()

if __name__ == '__main__':
f()
$ ./python.exe test.py
--Return--
> /Users/sasha/Work/python-hg/py3k/test.py(5)f()->None
-> import pdb; pdb.set_trace()
(Pdb) lv = 2
(Pdb) print lv
2


> http://paste.pound-python.org/show/5150/

Please don't use paste services when posting on python-dev.  Postings
to this list are archived much longer than links to paste services
remain valid.

>
> I couldn't find anything in the documentation about this, should I report a 
> bug?

If you find specific versions that are affected by this bug, please
report it at bugs.python.org.
___
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] Pass possibly imcompatible options to distutil's ccompiler

[Éric Araujo]

Hi,

I'm the maintainer of Pyrit (http://pyrit.googlecode.com) and 
recently

checked in some code that uses the AES-NI intrinsics found in GCC
4.4+. I'm looking for a way how to build the python-extension using
distutils in a sane way and could not get an answer from the
distutils-people about that.


Could you tell where and when you asked?  If it was on distutils-sig 
and

nobody replied, maybe people were just busy and you could try again.

Regards
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Terry Reedy]

On 4/12/2011 12:17 PM, Alexander Belopolsky wrote:


If you find specific versions that are affected by this bug, please
report it at bugs.python.org.


If Py version >= 2.7 and != 3.0.


--
Terry Jan Reedy

___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Djoume Salvetti]

Thank you and sorry about the pastebin.

I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
(all in ubuntu). I'll open a bug.

-- 
Djoume Salvetti
Director of Development

T:416.601.1999 x 249
www.trapeze.com twitter: trapeze
175 Bloor St. E., South Tower, Suite 900
Toronto, ON M4W 3R8
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Michael Foord]

On 12/04/2011 18:01, Djoume Salvetti wrote:

Thank you and sorry about the pastebin.

I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 
3.1.2 (all in ubuntu). I'll open a bug.


Both Python 2.5 and 2.6 are in "security fix only" mode I'm afraid, so 
won't receive fixes for issues like this.


All the best,

Michael Foord


--
Djoume Salvetti
Director of Development

T:416.601.1999 x 249
www.trapeze.com  twitter: trapeze
175 Bloor St. E., South Tower, Suite 900
Toronto, ON M4W 3R8


___
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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Guido van Rossum]

On Tue, Apr 12, 2011 at 10:01 AM, Djoume Salvetti  wrote:
> Thank you and sorry about the pastebin.
> I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
> (all in ubuntu). I'll open a bug.

Looking at the pastebin you are using !lv = 2. Why the !? Without it,
it works fine:

Python 2.5.5+ (release25-maint:86106, Dec  9 2010, 10:25:54)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(x):
...  import pdb; pdb.set_trace()
...  return x
...
>>> f(1)
> (3)f()
(Pdb) x
1
(Pdb) x = 2
(Pdb) c
2
>>>

-- 
--Guido van Rossum (python.org/~guido)
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Guido van Rossum]

On Tue, Apr 12, 2011 at 11:01 AM, Djoume Salvetti  wrote:
> On Tue, Apr 12, 2011 at 1:22 PM, Guido van Rossum  wrote:
>>
>> Looking at the pastebin you are using !lv = 2. Why the !? Without it,
>> it works fine:
>>
>
>
> I just wanted to make sure I was executing a python statement and not a pdb
> alias.
> I re-tested without the exclamation mark and still have the same issue:
>  -> import pdb; pdb.set_trace()
> (Pdb) list
>   1     gv = 1
>   2
>   3     def f():
>   4         lv = 1
>   5  ->     import pdb; pdb.set_trace()
>   6
>   7     if __name__ == '__main__':
>   8         f()
> [EOF]
> (Pdb) lv
> 1
> (Pdb) lv = 2
> (Pdb) lv
> 1
> (Pdb)

Interesting. You'll find that if you let the function continue, lv is
actually set to 2. Why pdb prints 1 I don't know. It might be
interesting to find out why that is, although since it's fixed in
Python 2.7 and Python 3, perhaps observing the changes in pdb.py (or
other related code) between Python 2.6 and 2.7 might be the quickest
way to find out.

-- 
--Guido van Rossum (python.org/~guido)
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 05, 2011, at 01:22 PM, Glenn Linderman wrote:

>On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>  DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>>  __version__ = pkgutil.get_distribution('elle').metadata['version']
>
>The RE as given won't match alpha, beta, rc, dev, and post suffixes that are
>discussed in POP 386.

It really wasn't intended to.  I'm torn about even including this code sample
in the PEP.  I'm highly tempted to rip this out and hand-wave over the
implementation of get_version().  It's not a critical part of the PEP and
might just be distracting.

>Are there issues for finding and loading multiple versions of the same
>module?

Out of scope for this PEP I think.

>Should it be possible to determine a version before loading a module?  If
>yes, the version module would have to be able to find a parse version strings
>in any of the many places this PEP suggests they could be... so that would be
>somewhat complex, but the complexity shouldn't be used to change the
>answer... but if the answer is yes, it might encourage fewer variant cases to
>be supported for acceptable version definition locations for this PEP.

I think the answer can be "yes", but only through distutils2/packaging APIs.
If there's no metadata for a module available, then I don't have a problem
saying the version information can't be determined without importing it.

-Barry



signature.asc
Description: PGP signature
___
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] Hg question

[Alexander Belopolsky]

I was preparing a commit to 3.2 and default branches and mistakenly
used -m insread of -l commit option.  As a result, I have

$ hg out
comparing with ssh://h...@hg.python.org/cpython
searching for changes
changeset:   69272:0bf1354fab6b
branch:  3.2
parent:  69268:bfc586c558ed
user:Alexander Belopolsky 
date:Tue Apr 12 14:00:43 2011 -0400
summary: m.txt

changeset:   69273:516ed700ce22
tag: tip
parent:  69270:c26d015cbde8
parent:  69272:0bf1354fab6b
user:Alexander Belopolsky 
date:Tue Apr 12 14:02:22 2011 -0400
summary: m.txt


I would like to replace m.txt in the summary with the content of the
file m.txt.  I tried to use the recipe [1], but qimport fails:

$ hg qimport -r 69272:tip
abort: cannot import merge revision 69273

[1] 
http://stackoverflow.com/questions/623052/how-to-edit-incorrect-commit-message-in-mercurial

PS: This scenario seems to be a usability regression compared to SVN.
SVN would actually warn me if I tried to use -m with a file name
instead of a message and editing the commit log in SVN is fairly
straightforward.
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 10, 2011, at 08:52 AM, Ben Finney wrote:

>Nitpick: Please call these “version strings”. A version string is hardly
>ever just one number, and not in the general case anyway.

The PEP title does say version *numbers* (plural), and that seems more general
than using 'strings' here.

>Emily maintains a package consisting of programs and modules in
>several languages that inter-operate; several are Python, but some
>are Unix shell, Perl, and there are some C modules. Emily decides
>the simplest API for all these modules to get the package version
>string is a single text file named ``version`` at the root of the
>project tree. All the programs and modules, including the
>``setup.py`` file, simply read the contents of ``version`` to get
>the version string.
>
>This is an often-overlooked case, I think. The unspoken assumption is
>often that ``setup.py`` is a suitable place for the overall version
>string, but this is not the case when that string must be read by
>non-Python programs.

I'm not certain that the additional story informs any recommendations made by
the PEP.  In the case where the version number is kept in some external file,
then you'd likely see something like this in setup.py:

setup(version=open('version.txt').read())

or this in foo/__init__.py:

__version__ = open('version.txt').read()

The details aren't that important, but the fact that the version is kept
in an external file doesn't change any of the recommendations the PEP is
already making.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Mark Dickinson]

On Tue, Apr 12, 2011 at 6:01 PM, Djoume Salvetti  wrote:

> Thank you and sorry about the pastebin.
> I can reproduce it on python 2.5.2 and python 2.6.6 but not on python 3.1.2
> (all in ubuntu). I'll open a bug.

Is http://bugs.python.org/issue5215 the same issue?

Mark
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 12:26 AM, Nick Coghlan wrote:

>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>
>> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>>
>> __version__ = pkgutil.get_distribution('elle').metadata['version']
>>
>> The RE as given won't match alpha, beta, rc, dev, and post suffixes that are
>> discussed in POP 386.
>
>Indeed, I really don't like the RE suggestion - better to tell people
>to just move the version info into the static config file and use
>pkgutil to make it available as shown. That solves the build time vs
>install time problem as well.

I'm actually going to remove the regexp example from the PEP.  It's
distracting, incorrect, and unnecessary (give that `packaging` will have such
an API).

>Yep, this is why the version information should be in the setup.cfg
>file, and hence available via pkgutil without loading the module
>first.

If the version information is in the setup.cfg, then the question is, what's
the code look like to get that stuffed into a module's __version__ attribute?
If it's not the pkgutil ugliness, what is it?  And does it work whether your
in say the source tree of your uninstalled module, or in a Python where the
package was installed via they OS?

-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 12:10 PM, Michael Foord wrote:

>>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>>
>>>  DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)')
>>>
>>>  __version__ = pkgutil.get_distribution('elle').metadata['version']
>>>
>
>I really dislike this way of specifying the version. For a start it is really
>ugly.

Agreed!  There should be a higher level API for this, e.g.:

__version__ = pkgutil.get_version('elle')

>More importantly it means the version information is *only* available if the
>package has been installed by "packaging", and so isn't available for the
>parts of my pre-build process like building the documentation (which import
>the version number to put into the docs).

That would have to be an important feature of .get_version() I think.

>Currently all my packages have the canonical version number information in
>the package itself using:
>
> __version__ = '1.2.3'
>
>Anything that needs the version number, including setup.py for upload to
>pypi, has one place to look for it and it doesn't depend on any other tools
>or processes. If switching to "packaging" prevents me from doing this then it
>will inhibit me using "packaging".

It definitely shouldn't prevent this.  I personally do the same thing, and it
seems the least bad way of doing it.  I think the clear version string
assigned to __version__ is the best recommendation (though not the only one)
that the PEP makes.

-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 09, 2011, at 06:23 PM, Éric Araujo wrote:

>> One of the main complaint against setuptools is that having to change
>> your application code because of the packaging tool used was not a > good
>> idea.  Having to use require instead of import or resource_whatever
>> instead of open (or get_data, the most sadly underused function in > the
>> stdlib) because you use setuptools instead of distutils was a bad > thing.
>>
>> As stated in the PEP, having a __version__ attribute in the module is
>> common, so my opinion is that making the packaging tool use that info > is
>> the Right Thing™, and having the dependency in the reverse sense is
>> wrong.  I don’t see a problem with having harmless duplication in the
>> *installed* system, once in  elle.__version__ and once in the pkgutil
>> metadata database.
>
> Barry’s reply:
>
>> I'm including this section because at Pycon, some people did express > an
>> interest in deriving the version number in this direction.  I wanted > to
>> capture what that might look like.  Since this is an informational > PEP, I
>> think it makes sense to include alternative approaches, but I tend to > agree
>> with you that it will be much more common to define > module.__version__ and
>> derive the metadata from that.
>
> IOW, you can define the version only once, either in your source file  or
> in the setup.cfg file, and the PEP describes how to get that info from
> the other place.  My personal opinion is that the approach using
> pkgutil.get_distribution should be much less prominent than the one
> putting the version in the Python code.

It is already though, right?  To me anyway the PEP does emphasize setting
__version__, but I'm open to specific suggestions.

-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 09:59 PM, Nick Coghlan wrote:

>It sounds like part of the PEP needs another trip through
>distutils-sig. An informational PEP really shouldn't be advocating
>standard library changes, but it would make sense for this point of
>view to inform any updates to PEP 386 (the version handling
>standardisation PEP).

I'm certainly open to any suggestions from distutils-sigsters, though I'm not
sure the PEP needs to be discussed there exclusively at this point.

>As I see it, there appear to be two main requests:
>1. Normalised version parsing and comparison should be available even
>if packaging itself is not installed (e.g. as part of pkgutil)
>2. packaging should support extraction of the version metadata from
>the source files when bundling a package for distribution
>
>On point 2, rather than requiring that it be explicitly requested, I
>would suggest the following semantics for determining the version when
>bundling a package ready for distribution:
>
>- if present in the metadata, use that
>- if not present in the metadata, look for __version__ in the module
>source code (or the __init__ source code for an actual package)
>- otherwise warn the developer that no version information has been
>provided so it is automatically being set to "0.0.0a0"

I like that.  Given the recommendations in PEP 396, I think it's more in scope
of the distutils-sig, and the various related PEPs to define the details of
how that would work.  I'd be happy to update the Deriving section of PEP 396
with any such recommendations.  That section isn't meant to be definitive or
even all-encompassing.  It's just meant to give some examples of how you could
do things in your own modules.

-Barry


signature.asc
Description: PGP signature
___
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] Hg question

[Sjoerd Mullender]

On 2011-04-12 20:35, Alexander Belopolsky wrote:
> I was preparing a commit to 3.2 and default branches and mistakenly
> used -m insread of -l commit option.  As a result, I have
> 
> $ hg out
> comparing with ssh://h...@hg.python.org/cpython
> searching for changes
> changeset:   69272:0bf1354fab6b
> branch:  3.2
> parent:  69268:bfc586c558ed
> user:Alexander Belopolsky 
> date:Tue Apr 12 14:00:43 2011 -0400
> summary: m.txt
> 
> changeset:   69273:516ed700ce22
> tag: tip
> parent:  69270:c26d015cbde8
> parent:  69272:0bf1354fab6b
> user:Alexander Belopolsky 
> date:Tue Apr 12 14:02:22 2011 -0400
> summary: m.txt
> 
> 
> I would like to replace m.txt in the summary with the content of the
> file m.txt.  I tried to use the recipe [1], but qimport fails:
> 
> $ hg qimport -r 69272:tip
> abort: cannot import merge revision 69273
> 
> [1] 
> http://stackoverflow.com/questions/623052/how-to-edit-incorrect-commit-message-in-mercurial
> 
> PS: This scenario seems to be a usability regression compared to SVN.
> SVN would actually warn me if I tried to use -m with a file name
> instead of a message and editing the commit log in SVN is fairly
> straightforward.

If you didn't push the changes to any other clone, you can hg strip
these changesets and do it again, correctly.  strip is part of the
rebase extension.

You cannot edit history that has already been shared with other clones.
 If you did, it would just come back at the next pull.


-- 
Sjoerd Mullender



signature.asc
Description: OpenPGP digital signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 12:51 PM, Michael Foord wrote:

>So I don't think recommending
>"pkgutil.get_distribution('elle').metadata['version']" as a way for packages
>to provide version information is good advice.

I want to make it clear that this section of the PEP is intended only to
provide some choices and examples, not to be definitive.  I've added this
text:

This could be done in any number of ways, a few of which are outlined
below.  These are included for illustrative purposes only and are not
intended to be definitive, complete, or all-encompassing.  Other
approaches are possible, and some included below may have limitations
that prevent their use in some situations.

Does that help?
-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 02:08 PM, Nick Coghlan wrote:

>(Also, tsk, tsk, Barry for including Standards track proposals in an
>Informational PEP!)

Is that really illegal? :)

>P.S. A nice coincidental progression: PEP 376, 386 and 396 are all
>related to versioning and package metadata

time-machine-ly y'rs,
-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 06, 2011, at 09:55 PM, Glenn Linderman wrote:

>The PEP doesn't mention PyPI, and at present none of the modules there use
>"packaging" :) So it wasn't obvious to me that the PEP applies only to PyPI,
>and I have used modules that were not available from PyPI yet were still
>distributed and packaged somehow (not using "packaging" clearly).

The core of the PEP does not require packaging or PyPI.  The Specification
section is the most important part of the PEP.  Yes, that does mention
parse_version() from PEP 386, and the Version metadata field from PEP 345, but
I think those cross-references are fine, because it's just referring to the
information contained there.

-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 04:53 PM, Nick Coghlan wrote:

>What I would like to see the PEP say is that if you don't *have* a
>setup.cfg file, then go ahead and embed the version directly in your
>Python source file. If you *do* have one, then put the version there
>and retrieve it with "pkgutil" if you want to provide a __version__
>attribute.

I'm not convinced there's consensus on that, i.e. that the version string
should go in setup.cfg if it exists.  It doesn't help that the pkgutil API for
doing that is pretty ugly.

>Barry is welcome to make a feature request to allow that dependency to
>go the other way, with the packaging system reading the version number
>out of the source file, but such a suggestion doesn't belong in an
>Informational PEP. If such a feature is ever accepted, then the
>recommendation in the PEP could be updated.

Note that there's really no reason why packaging has to grow a method to do
this.  It would be a convenience, but not a requirement.  For example, I have
my own helper function (something like the now elided get_version() code) that
digs version strings out of files for my own packages just fine.  True, it
doesn't handle the full normalized version specification, but I don't care
because my version numbers will never look that complex.  If yours does, and
you don't want to rely on the pkgutil API, or you need it to work even when
your module isn't installed, well, write your own code!

The Deriving section of the PEP is not the most important part of it, and is
not making specific recommendations.  If it's not clear that it's only
providing examples, or it's distracting, then maybe it's better off being
removed, cut down or rewritten.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Apr 06, 2011, at 11:04 AM, John Arbash Meinel wrote:

>> In other words, parse_version will return a tuple for each version string,
>> that is compatible with StrictVersion but also accept arbitrary version and
>> deal with them so they can be compared:
>> 
> from pkg_resources import parse_version as V
> V('1.2')
>> ('0001', '0002', '*final')
> V('1.2b2')
>> ('0001', '0002', '*b', '0002', '*final')
> V('FunkyVersion')
>> ('*funkyversion', '*final')
>
>bzrlib has certainly used 'version_info' as a tuple indication such as:
>
>version_info = (2, 4, 0, 'dev', 2)
>
>and
>
>version_info = (2, 4, 0, 'beta', 1)
>
>and
>
>version_info = (2, 3, 1, 'final', 0)
>
>etc.
>
>This is mapping what we could sort out from Python's "sys.version_info".

It's probably worth specifying the __version_info__ tuple in more detail in
either PEP 386 or 396.  I think more detail should go *somewhere*, and it
feels like it could go in either PEP.  Maybe Tarek can chime in on that.

>The *really* nice bit is that you can do:
>
>if sys.version_info >= (2, 6):
>  # do stuff for python 2.6(.0) and beyond
>
>Doing that as:
>
>if sys.version_info >= ('2', '6'):
>
>is pretty ugly.

I personally often do tests against sys.hexversion, which is a little less
ugly (maybe ;).

if sys.hexversion >= 0x20600f0:
# 2.6 or 2.7

- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNpK+lAAoJEBJutWOnSwa/+pYP/R5x6siiCRpGGUjwQti7BZRg
fcddP1kUV/FU6fQFE44ZrXki0d7kx5SyNCTQTphtnBlUiqAvtjYK6oKon9xNqsq/
5KocKrbJZ/h806H0irzElzRXs3M+OcymC2ZQwvR1hqzMrdFRGRQMmanR0yz3LB1x
S2mF+TR2zEdMX4Ace6+Y5Vx4NYHTELapMOfamDgtft+lE+c8w6U7aZX/Gyzgagsd
yXDd33LI4/dRIENA/9NYycm05txebWpbEQsLLytczZqfLX7uXqOe5HTvO2g9CcmD
Yi8AT3ypERAHp+cLED7ICJkD3MY9AMlJBum7wgFjrKvwiJ7tu9x/9nTP3jhE6SaV
oDcyo2qLoCYbBBL+83bsRYK0AEBZAz4fsfJ/2A+a7vIjFrAFsRab7qiLrC9Pg1N+
DC4aFakRkrRBOoLoXnfYmTDq3zqvny4RzsbwP/eD/A13YfquLr8ECL6TFa3WOpNz
cmB6+h6O7AcMHlblON+Cf3PfHcPQC1h9atrkrjOBeG9m5812HcO/sC8lMWk0pUpa
D8OozOJI3ISQvw/rDEFMYKauc7eUIp/2hR4N7NBqBBo28TL38sRvQsQ6UoV0C/aF
3cjAhSHG5g2zsZZADUbyAel5h6MKoyoHkbA11yOHS3RXmE8XASa0zckRYwUwfGtC
M8PDejFisplJhDj2rGSa
=fpk4
-END PGP SIGNATURE-
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Lennart Regebro]

Hasn't it always been like that? I tried with Python 2.3 now and it's
the same. I have no memory of that actually changing an existing
variable in any version of Python I've used. More testing turns out
that this works:

-> print "lv is ", lv
(Pdb) lv=2
(Pdb) c
lv is  2

While this seem to "reset" is:

-> print "lv is ", lv
(Pdb) lv=2
(Pdb) lv
1
(Pdb) c
lv is  1

This is the same from Python 2.3 to 2.6. I thought is just was a lack
of feature, that there for some reason was really hard to change the
value of an existing variable from the debugger. I though that for ten
years. It never occurred to me to change the variable and type c
without first checking that the variable had changed... :-)

It is however fixed in 2.7.

-> print "lv is ", lv
(Pdb) lv=2
(Pdb) lv
2
(Pdb) c
lv is  2


But this bug/lack of feature has been there as long as I can remember. :-)

//Lennart
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 07, 2011, at 09:13 AM, Toshio Kuratomi wrote:

>Barry -- I think we want to talk about NormalizedVersion.from_parts() rather
>than parse_version().

See my previous follow up.  It probably makes sense to be explicit in one
PEP or the other, but...

>So you can't escape needing a function to compare versions.
>(NormalizedVersion does this by letting you compare NormalizedVersions
>together).  Barry if this is correct, maybe __version_info__ is useless and
>I shouldn't have brought it up at pycon?

...yikes!  You might be right about that.  Unless there are any counter
arguments, I think I'll have to remove it from PEP 396.

(Makes me like hexversion even more :).

-Barry


signature.asc
Description: PGP signature
___
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 396, Module Version Numbers

[Laura Creighton]

In a message of Tue, 12 Apr 2011 15:56:32 EDT, Barry Warsaw writes:

>The Deriving section of the PEP is not the most important part of it, and
> is
>not making specific recommendations.  If it's not clear that it's only
>providing examples, or it's distracting, then maybe it's better off being
>removed, cut down or rewritten.

To me, at any rate, it read as a pretty  important part.  But the version I
just read from http://www.python.org/dev/peps/pep-0396/ still has the
re in it as well.

Laura
___
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 396, Module Version Numbers

[Barry Warsaw]

On Apr 12, 2011, at 10:14 PM, Laura Creighton wrote:

>In a message of Tue, 12 Apr 2011 15:56:32 EDT, Barry Warsaw writes:
>
>>The Deriving section of the PEP is not the most important part of it, and
>> is
>>not making specific recommendations.  If it's not clear that it's only
>>providing examples, or it's distracting, then maybe it's better off being
>>removed, cut down or rewritten.
>
>To me, at any rate, it read as a pretty  important part.  But the version I
>just read from http://www.python.org/dev/peps/pep-0396/ still has the
>re in it as well.

Yep, I haven't committed or pushed the change yet.

-Barry



signature.asc
Description: PGP signature
___
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] Hg question

[Martin v. Löwis]

> I would like to replace m.txt in the summary with the content of the
> file m.txt.  I tried to use the recipe [1], but qimport fails:

I'd use "hg export":

hg export -r 69272:tip > ../patch
Edit patch to update commit message
cd ..
rm this_clone
hg clone clean_cpython this_clone
cd this_clone
hg import ../patch

HTH,
Martin
___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[Guido van Rossum]

On Tue, Apr 12, 2011 at 1:05 PM, Lennart Regebro  wrote:
> Hasn't it always been like that? I tried with Python 2.3 now and it's
> the same. I have no memory of that actually changing an existing
> variable in any version of Python I've used. More testing turns out
> that this works:
>
> -> print "lv is ", lv
> (Pdb) lv=2
> (Pdb) c
> lv is  2
>
> While this seem to "reset" is:
>
> -> print "lv is ", lv
> (Pdb) lv=2
> (Pdb) lv
> 1
> (Pdb) c
> lv is  1
>
> This is the same from Python 2.3 to 2.6. I thought is just was a lack
> of feature, that there for some reason was really hard to change the
> value of an existing variable from the debugger. I though that for ten
> years. It never occurred to me to change the variable and type c
> without first checking that the variable had changed... :-)
>
> It is however fixed in 2.7.
>
> -> print "lv is ", lv
> (Pdb) lv=2
> (Pdb) lv
> 2
> (Pdb) c
> lv is  2
>
>
> But this bug/lack of feature has been there as long as I can remember. :-)

I swear it was my intention that assigning to locals would work, and I
was surprised to learn that it didn't. I'm glad it's fixed in 2.7
though... :-)

-- 
--Guido van Rossum (python.org/~guido)
___
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] Hg question

[Victor Stinner]

Le mardi 12 avril 2011 à 14:35 -0400, Alexander Belopolsky a écrit :
> I was preparing a commit to 3.2 and default branches and mistakenly
> used -m insread of -l commit option.  As a result, I have
> 
> $ hg out
> comparing with ssh://h...@hg.python.org/cpython
> searching for changes
> changeset:   69272:0bf1354fab6b
> branch:  3.2
> parent:  69268:bfc586c558ed
> user:Alexander Belopolsky 
> date:Tue Apr 12 14:00:43 2011 -0400
> summary: m.txt
> 
> changeset:   69273:516ed700ce22
> tag: tip
> parent:  69270:c26d015cbde8
> parent:  69272:0bf1354fab6b
> user:Alexander Belopolsky 
> date:Tue Apr 12 14:02:22 2011 -0400
> summary: m.txt
> 
> 
> I would like to replace m.txt in the summary with the content of the
> file m.txt.

I don't know if it is the "right" solution, but I would use hg strip
+histedit. Something like:

$ hg strip 516ed700ce22 # remove commit in the default branch
$ hg update 3.2
$ hg histedit 0bf1354fab6b

$ hg ci -l m.txt
$ hg update default
$ hg merge 3.2

WARNING: it is easy to loose work using strip and histedit, so first
make sure that you have a copy of your commits. Use hg log -p, hg
export, clone the whole repository, etc.

Victor

___
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 399: Pure Python/C Accelerator Module Compatibiilty Requirements

[Brett Cannon]

Here is the next draft of the PEP. I changed the semantics requirement to
state that 100% branch coverage is required for any Python code that is
being replaced by accelerated C code instead of the broad "must be
semantically equivalent". Also tweaked wording here and there to make
certain things more obvious.

--

PEP: 399
Title: Pure Python/C Accelerator Module Compatibility Requirements
Version: $Revision: 88219 $
Last-Modified: $Date: 2011-01-27 13:47:00 -0800 (Thu, 27 Jan 2011) $
Author: Brett Cannon 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 04-Apr-2011
Python-Version: 3.3
Post-History: 04-Apr-2011, 12-Apr-2011

Abstract


The Python standard library under CPython contains various instances
of modules implemented in both pure Python and C (either entirely or
partially). This PEP requires that in these instances that the
C code *must* pass the test suite used for the pure Python code
so as to act as much as a drop-in replacement as possible
(C- and VM-specific tests are exempt). It is also required that new
C-based modules lacking a pure Python equivalent implementation get
special permissions to be added to the standard library.


Rationale
=

Python has grown beyond the CPython virtual machine (VM). IronPython_,
Jython_, and PyPy_ all currently being viable alternatives to the
CPython VM. This VM ecosystem that has sprung up around the Python
programming language has led to Python being used in many different
areas where CPython cannot be used, e.g., Jython allowing Python to be
used in Java applications.

A problem all of the VMs other than CPython face is handling modules
from the standard library that are implemented (to some extent) in C.
Since they do not typically support the entire `C API of Python`_ they
are unable to use the code used to create the module. Often times this
leads these other VMs to either re-implement the modules in pure
Python or in the programming language used to implement the VM
(e.g., in C# for IronPython). This duplication of effort between
CPython, PyPy, Jython, and IronPython is extremely unfortunate as
implementing a module *at least* in pure Python would help mitigate
this duplicate effort.

The purpose of this PEP is to minimize this duplicate effort by
mandating that all new modules added to Python's standard library
*must* have a pure Python implementation _unless_ special dispensation
is given. This makes sure that a module in the stdlib is available to
all VMs and not just to CPython (pre-existing modules that do not meet
this requirement are exempt, although there is nothing preventing
someone from adding in a pure Python implementation retroactively).

Re-implementing parts (or all) of a module in C (in the case
of CPython) is still allowed for performance reasons, but any such
accelerated code must pass the same test suite (sans VM- or C-specific
tests) to verify semantics and prevent divergence. To accomplish this,
the test suite for the module must have 100% branch coverage of the
pure Python implementation before the acceleration code may be added.
This is to prevent users from accidentally relying
on semantics that are specific to the C code and are not reflected in
the pure Python implementation that other VMs rely upon. For example,
in CPython 3.2.0, ``heapq.heappop()`` does an explicit type
check in its accelerated C code while the Python code uses duck
typing::

from test.support import import_fresh_module

c_heapq = import_fresh_module('heapq', fresh=['_heapq'])
py_heapq = import_fresh_module('heapq', blocked=['_heapq'])


class Spam:
"""Tester class which defines no other magic methods but
__len__()."""
def __len__(self):
return 0


try:
c_heapq.heappop(Spam())
except TypeError:
# Explicit type check failure: "heap argument must be a list"
pass

try:
py_heapq.heappop(Spam())
except AttributeError:
# Duck typing failure: "'Foo' object has no attribute 'pop'"
pass

This kind of divergence is a problem for users as they unwittingly
write code that is CPython-specific. This is also an issue for other
VM teams as they have to deal with bug reports from users thinking
that they incorrectly implemented the module when in fact it was
caused by an untested case.


Details
===

Starting in Python 3.3, any modules added to the standard library must
have a pure Python implementation. This rule can only be ignored if
the Python development team grants a special exemption for the module.
Typically the exemption will be granted only when a module wraps a
specific C-based library (e.g., sqlite3_). In granting an exemption it
will be recognized that the module will be considered exclusive to
CPython and not part of Python's standard library that other VMs are
expected to support. Usage of ``ctypes`` to provide an
API for a C library will continue to be frowned upon as ``cty

Re: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.

[Antoine Pitrou]

On Tue, 12 Apr 2011 23:59:53 +0200
brett.cannon  wrote:
> Technical details of
> +the VM providing the accelerated code are allowed to differ as
> +necessary, e.g., a class being a ``type`` when implemented in C.

I don't understand what this means ("a class being a ``type`` when
implemented in C").

> +If this test were to provide 100% branch coverage for
> +``heapq.heappop()`` in the pure Python implementation then the
> +accelerated C code would be allowed to be added to CPython's standard
> +library. If it did not, then the test suite would need to be updated
> +until 100% branch coverage was provided before the accelerated C code
> +could be added.

I really think that's a too strong requirement. We don't want to
paralyze development until the stdlib gets 100% coverage in the tests
suite.

Regards

Antoine.


___
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] peps: Update PEP 399 to include comments from python-dev.

[Benjamin Peterson]

2011/4/12 Antoine Pitrou :
> On Tue, 12 Apr 2011 23:59:53 +0200
> brett.cannon  wrote:
>> Technical details of
>> +the VM providing the accelerated code are allowed to differ as
>> +necessary, e.g., a class being a ``type`` when implemented in C.
>
> I don't understand what this means ("a class being a ``type`` when
> implemented in C").
>
>> +If this test were to provide 100% branch coverage for
>> +``heapq.heappop()`` in the pure Python implementation then the
>> +accelerated C code would be allowed to be added to CPython's standard
>> +library. If it did not, then the test suite would need to be updated
>> +until 100% branch coverage was provided before the accelerated C code
>> +could be added.
>
> I really think that's a too strong requirement. We don't want to
> paralyze development until the stdlib gets 100% coverage in the tests
> suite.

Presumably this only applies to new code, though, which I would hope
would have comprehensive test coverage regardless of this PEP.



-- 
Regards,
Benjamin
___
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] peps: Update PEP 399 to include comments from python-dev.

[Antoine Pitrou]

On Tue, 12 Apr 2011 17:34:42 -0500
Benjamin Peterson  wrote:
> 2011/4/12 Antoine Pitrou :
> > On Tue, 12 Apr 2011 23:59:53 +0200
> > brett.cannon  wrote:
> >> Technical details of
> >> +the VM providing the accelerated code are allowed to differ as
> >> +necessary, e.g., a class being a ``type`` when implemented in C.
> >
> > I don't understand what this means ("a class being a ``type`` when
> > implemented in C").
> >
> >> +If this test were to provide 100% branch coverage for
> >> +``heapq.heappop()`` in the pure Python implementation then the
> >> +accelerated C code would be allowed to be added to CPython's standard
> >> +library. If it did not, then the test suite would need to be updated
> >> +until 100% branch coverage was provided before the accelerated C code
> >> +could be added.
> >
> > I really think that's a too strong requirement. We don't want to
> > paralyze development until the stdlib gets 100% coverage in the tests
> > suite.
> 
> Presumably this only applies to new code, though, which I would hope
> would have comprehensive test coverage regardless of this PEP.

True, but comprehensive test coverage is not the same as a formal
requirement of 100% coverage.

Regards

Antoine.
___
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] cpython: Fix 64-bit safety issue in BZ2Compressor and BZ2Decompressor.

[Antoine Pitrou]

On Tue, 12 Apr 2011 23:05:40 +0200
nadeem.vawda  wrote:
> http://hg.python.org/cpython/rev/0010cc5f22d4
> changeset:   69275:0010cc5f22d4
> user:Nadeem Vawda 
> date:Tue Apr 12 23:02:42 2011 +0200
> summary:
>   Fix 64-bit safety issue in BZ2Compressor and BZ2Decompressor.
> 
> files:
>   Lib/test/test_bz2.py |  36 +++-
>   Modules/_bz2module.c |  33 +
>   2 files changed, 59 insertions(+), 10 deletions(-)

Can you add a Misc/NEWS entry?

Thank you

Antoine.


___
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] cpython (3.1): Fix Issue11703 - urllib2.geturl() does not return correct url when the original

[Antoine Pitrou]

On Wed, 13 Apr 2011 01:26:12 +0200
senthil.kumaran  wrote:
> http://hg.python.org/cpython/rev/3f240a1cd245
> changeset:   69284:3f240a1cd245
> branch:  3.1
> parent:  69277:707078ca0a77
> user:Senthil Kumaran 
> date:Wed Apr 13 07:01:19 2011 +0800
> summary:
>   Fix Issue11703 - urllib2.geturl() does not return correct url when the 
> original url contains #fragment. Patch Contribution by Santoso Wijaya.
> 
> files:
>   Lib/test/test_urllib.py |  10 ++
>   Lib/test/test_urllib2.py|  15 ++-
>   Lib/test/test_urllib2net.py |   2 +-
>   Lib/urllib/request.py   |   9 ++---
>   4 files changed, 31 insertions(+), 5 deletions(-)

Can you add a Misc/NEWS entry?

Thank you

Antoine.


___
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] peps: Update PEP 399 to include comments from python-dev.

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/12/2011 06:31 PM, Antoine Pitrou wrote:
> On Tue, 12 Apr 2011 23:59:53 +0200
> brett.cannon  wrote:
>> Technical details of
>> +the VM providing the accelerated code are allowed to differ as
>> +necessary, e.g., a class being a ``type`` when implemented in C.
> 
> I don't understand what this means ("a class being a ``type`` when
> implemented in C").
> 
>> +If this test were to provide 100% branch coverage for
>> +``heapq.heappop()`` in the pure Python implementation then the
>> +accelerated C code would be allowed to be added to CPython's standard
>> +library. If it did not, then the test suite would need to be updated
>> +until 100% branch coverage was provided before the accelerated C code
>> +could be added.
> 
> I really think that's a too strong requirement. We don't want to
> paralyze development until the stdlib gets 100% coverage in the tests
> suite.

Anybody who is either a) providing a C accelerator for an existing
stdlib module which doesn't yet have 100% coverage, or b) writing a new
module proposed for the stdlib without providing 100% coverage needs to
be prepared to defend that practice against the presumption stated by
the PEP.  We can grandfather existing code already in the stdlib, but
anybody making substantial changes to such code without first providing
coverage ought to be challenged.

Trying to accelerate existing code which doesn't have the coverage is
insane:  how can you know that the accelerator doesn't subtly change the
semantics without tests?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2k5UoACgkQ+gerLs4ltQ5QMgCfda1S5DKbWfrJpy8bp8in0qyr
oisAn01TP7TT41Mj8q3+rusJ+vccNhcS
=s0Q6
-END PGP SIGNATURE-

___
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] peps: Update PEP 399 to include comments from python-dev.

[Antoine Pitrou]

On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver  wrote:
> Trying to accelerate existing code which doesn't have the coverage is
> insane:  how can you know that the accelerator doesn't subtly change the
> semantics without tests?

Well, why do you think tests guarantee that the semantics are the same?
Tests are not a magic bullet. "Covering" a code path doesn't ensure
that every possible behaviour is accounted for.

And if you think that is "insane", you should probably wipe most of the
software you are using on your computer, because most existing software
doesn't have 100% test coverage.

Regards

Antoine.


___
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] Bug? Can't rebind local variables after calling pdb.set_trace()

[R. David Murray]

On Tue, 12 Apr 2011 22:05:57 +0200, Lennart Regebro  wrote:
> This is the same from Python 2.3 to 2.6. I thought is just was a lack
> of feature, that there for some reason was really hard to change the
> value of an existing variable from the debugger. I though that for ten
> years. It never occurred to me to change the variable and type c
> without first checking that the variable had changed... :-)
> 
> It is however fixed in 2.7.

For the curious:

http://bugs.python.org/issue5215

--
R. David Murray   http://www.bitdance.com
___
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] peps: Update PEP 399 to include comments from python-dev.

[James Y Knight]

On Apr 12, 2011, at 7:50 PM, Tres Seaver wrote:
> Trying to accelerate existing code which doesn't have the coverage is
> insane:  how can you know that the accelerator doesn't subtly change the
> semantics without tests?

But even if you do have 100% python source code branch coverage, that's not 
nearly enough. There are thousands of branches inside the python interpreter, 
which you also need to have full coverage on to *really* ensure that the 
behavior of the code does not subtly change.

Good luck with that.

James
___
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] Pass possibly imcompatible options to distutil's ccompiler

[David Cournapeau]

On Tue, Apr 12, 2011 at 8:32 AM, Nick Coghlan  wrote:
> On Tue, Apr 12, 2011 at 7:41 AM, Lukas Lueg  wrote:
>> Any other ideas on how to solve this in a better way?
>
> Have you tried with distutils2? If it can't help you, it should really
> be looked into before the packaging API is locked for 3.3.

distutil2 is almost identical to distutils as far as compilation goes,
so I am not sure why it would help the OP.

@Lukas: if you want to check for compiler flag support, the best way
to do it in distutils is to use the config support: look in particular
in the try_compile/try_link methods. The schema is basically:

# code may refer to e.g. a trivial extension source code
try_compile(code) # check that the current option set is sane
for each additional flag you are interested:
   save compiler option
   add the additional flag
   if try_compile(code) == 0:
   restore compiler option

cheers,

David
___
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] peps: Update PEP 399 to include comments from python-dev.

[Stefan Behnel]

Antoine Pitrou, 13.04.2011 02:07:

On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:

Trying to accelerate existing code which doesn't have the coverage is
insane:  how can you know that the accelerator doesn't subtly change the
semantics without tests?


Well, why do you think tests guarantee that the semantics are the same?
Tests are not a magic bullet. "Covering" a code path doesn't ensure
that every possible behaviour is accounted for.


This is particularly true when it comes to input types. There are different 
protocols out there that people use in their code, iteration vs. item 
access being only the most famous ones, inheritance vs. wrapping being 
another issue. Duck-typed Python code may work with a lot more input types 
than C code, even with 100% test coverage. This has been partly mentioned 
in the PEP, but not as clearly in the context of test coverage. Tests can 
only catch issues with the input they use themselves, not with all input 
the code will encounter in the wild.


However, I think we are really discussing a theoretical issue here. All the 
PEP is trying to achieve is to raise the bar for C code in the stdlib, for 
exactly the reason that it can easily introduce subtle semantic differences 
in comparison to generic Python code.


I think it would help to point out in the PEP that code that fails to touch 
the theoretical 100% test coverage bar is not automatically excluded from 
integration, but needs solid reasoning, review and testing in the wild in 
order to be considered an equivalent alternative implementation. But then 
again, this should actually be required anyway, even for code with an 
exceedingly high test coverage.


Stefan

___
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] peps: Update PEP 399 to include comments from python-dev.

[Georg Brandl]

On 13.04.2011 02:07, Antoine Pitrou wrote:
> On Tue, 12 Apr 2011 19:50:34 -0400
> Tres Seaver  wrote:
>> Trying to accelerate existing code which doesn't have the coverage is
>> insane:  how can you know that the accelerator doesn't subtly change the
>> semantics without tests?
> 
> Well, why do you think tests guarantee that the semantics are the same?
> Tests are not a magic bullet. "Covering" a code path doesn't ensure
> that every possible behaviour is accounted for.

def foo(a, b):
if condition(a):
bar = b
do_something_with(bar)

This has 100% coverage if "condition" is usually true :)

Georg

___
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