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 yo
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
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
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
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 occur
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 sam
-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 impl
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 Issue117
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.
>
> file
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`` wh
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 bei
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")
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 m
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:
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 "
> 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
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 example
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
>re
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
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"
-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 com
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 w
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
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
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 cho
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:0bf1354fab6
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
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_d
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
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, an
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
__
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.
>Emil
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:
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
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
>
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:
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 iss
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
Tor
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.
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 th
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 __n
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
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 h
43 matches
Mail list logo
