Re: [Python-Dev] Why no venv in existing directory?
Hi Carl, On 19.07.2012, at 18:39, Carl Meyer wrote: > Hi Stefan, > > On 07/19/2012 06:28 AM, Stefan H. Holek wrote: >> While trying 3.3 beta I found that I cannot use my favorite >> virtualenv pattern with pyvenv: > > I'd have no problem with lifting the restriction. > > I don't recall any clear rationale; I think it was probably just the > simplest implementation initially, and no one ever raised it as an issue > in the PEP process. Thanks for your reply. The feature certainly is on *my* wish-list but I might be alone here. ;-) Stefan -- Stefan H. Holek ste...@epy.co.at ___ 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] Why no venv in existing directory?
Wiadomość napisana przez Stefan H. Holek w dniu 23 lip 2012, o godz. 09:09: > Hi Carl, > > On 19.07.2012, at 18:39, Carl Meyer wrote: > >> Hi Stefan, >> >> On 07/19/2012 06:28 AM, Stefan H. Holek wrote: >>> While trying 3.3 beta I found that I cannot use my favorite >>> virtualenv pattern with pyvenv: >> >> I'd have no problem with lifting the restriction. >> >> I don't recall any clear rationale; I think it was probably just the >> simplest implementation initially, and no one ever raised it as an issue >> in the PEP process. > > Thanks for your reply. The feature certainly is on *my* wish-list but I might > be alone here. ;-) You are not. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 ___ 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
On Mon, Jul 23, 2012 at 12:34 AM, Meador Inge wrote: > On Sun, Jul 22, 2012 at 8:55 PM, r.david.murray > wrote: > >> http://hg.python.org/cpython/rev/80b81658455b >> changeset: 78246:80b81658455b >> parent: 78244:c43d73277756 >> parent: 78245:b97f65f2298d >> user:R David Murray >> 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] venv scripts for fish and csh shells
I thought my proposition is minor change, but if it's too late for 3.3 — I'm ok. On Sun, Jul 22, 2012 at 8:54 PM, Antoine Pitrou wrote: > On Sun, 22 Jul 2012 20:39:15 +0300 > Andrew Svetlov wrote: >> Ok. >> Sorry for my mistake — there are really no commits for >> http://bugs.python.org/issue15417 >> It's look important for me — but you are release manager. >> If you consider the patch as potentially dangerous — I have to agree with >> you. >> You are the master :) > > This is not because Georg is the master. When a release is nearing we > think it is important to avoid introducing potential regressions, > except when fixing existing bugs. That's why we have a feature freeze > which extends to many kinds of "enhancements", including performance > improvements: really, it is more of a "bugfix-only period". > > One could propose other mechanisms for release preparation, but in the > meantime, it is important as a community that we all follow similar > rules. > > Regards > > Antoine. > > > -- > Software development and contracting: http://pro.pitrou.net > > > ___ > 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/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ 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] venv scripts for fish and csh shells
On Mon, Jul 23, 2012 at 11:24 AM, Andrew Svetlov wrote: > I thought my proposition is minor change, but if it's too late for 3.3 > — I'm ok. Very simply, the first beta is when feature freeze goes into effect. This is a really common policy that has been in effect for a long time in CPython and most projects. ___ 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
On Mon, Jul 23, 2012 at 11:17 AM, jesus.cea wrote:
> http://hg.python.org/cpython/rev/b9a3ed1b14b9
> changeset: 78260:b9a3ed1b14b9
> parent: 78257:03063e718f5f
> parent: 78259:1911e192af0d
> user:Jesus Cea
> 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] [Python-checkins] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
-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.
> 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.
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.
What do you think?.
>
> 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
>>
>
>
>
- --
Jesus Cea Avion _/_/ _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/
. _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBUA1+Bplgi5GaxT1NAQJtSAQAkv5DyoQ1N1YdOH2QLHnFbOsvp/1aG0Vy
hHMlD6cu/L7Ub+gyWWo65v9Dp4sLahV+CYem1wL4Fzd2QyBNQdg+BNou9eqoDzGF
IJbY2HALwOwz1vgeBiamFOSvpyWya/hzXR9I7rkBqXdR9c2Njdl/ioZQNKETO05k
TRfd/BQas4k=
=TKFO
-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
[Python-Dev] Doc/ACKS and Misc/ACKS
On Mon, 23 Jul 2012 18:38:30 +0200 Jesus Cea 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 Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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
>> 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 ___ 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
On Mon, Jul 23, 2012 at 12:17 PM, Antoine Pitrou wrote: > On Mon, 23 Jul 2012 18:38:30 +0200 > Jesus Cea 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
On Mon, Jul 23, 2012 at 11:38 AM, Jesus Cea 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] Doc/ACKS and Misc/ACKS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/07/12 19:30, Eli Bendersky wrote: >> 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 +1 too. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBUA2XtJlgi5GaxT1NAQKiXQQAnOmVaALBmcAbEK7vImQ03m6tdh86ZyU/ VyRuoHVgHxsOn83h2VG+94zjNutedIMK9rq1hEhhPApJcXnYwftMpgEwlyj7vLFA RUz8c02sKpoi/T8BGv2xVdW09yeMCUwzTDAuaS73NqscwcGplibaSPU5oKOjqetc NhS0JdGQcr8= =Ifpc -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] Doc/ACKS and Misc/ACKS
On Mon, Jul 23, 2012 at 1:28 PM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 23/07/12 19:30, Eli Bendersky wrote: >>> 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 > > +1 too. Before everyone else on the list just writes a two character "+1" response, can we just assume that if you don't speak up, you're ok with it? Especially when it's about an ack file... ___ 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/07/12 20:19, Meador Inge wrote:
> self.assertGreaterEqual(sys.getsizeof(struct.Struct('123B')),
[...]
> 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")'.
No garantee, but I would find "interesting" that
"sizeof("1234B")==sizeof("B")".
If someday we implement some clever idea here (like the repeat counter
optimization discussed), we can simply change "sizeof("123B")" to
"sizeof("12345B")", or to "sizeof("BHBHBHBH"), etc.
> 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 ...
I agree. I should have raised this issue in the tracker. The fact is
that I was checking the patch carefully today, when we collided
mid-air working in the same issue both of us :-). I disliked the
proposed tests at that time.
Thanks for raising the issue. I will try to be more careful.
- --
Jesus Cea Avion _/_/ _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/
. _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBUA2ZiZlgi5GaxT1NAQKwLQP/RqrP5qbvUtZ9MCuyTaT45l8+7QzqlJrx
Nyh2t98jWVxiso0FDyT2vw839lX0CwssuKyNPFkXzKicNiX4mW0rC1uxNajCk0kG
aVHKL6aC+65iJhA7+9uOW1yfRFyhqQbUc3aRlvg7UJMj4YEfB82Okk/2Wu0hgyiU
4Ti5VvFuOZ8=
=G/WJ
-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] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
On 23.07.12 19:38, Jesus Cea wrote: 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. 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. What do you think?. I think any __sizeof__ tests are meaningless, because any result is implementation detail. For other implementations we get other values and other relations. Any of our a priori assumptions could be incorrect. Even my first assert may fail, if implementation uses a continuous array with overallocation. I am now prepared a set of 14 __sizeof__ patches (should it be one issue or 14 individual issues in bugtracker?), and I feel a great desire not to write tests at all. ___ 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 (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
On 23.07.12 21:19, Meador Inge wrote: The patch was out for review for several days ... Actually for several months (in issue14596). ___ 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 (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
On 23 Jul 2012, at 19:49, Serhiy Storchaka wrote: > On 23.07.12 19:38, Jesus Cea wrote: >> 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. >> >> 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. >> >> What do you think?. > > I think any __sizeof__ tests are meaningless, because any result is > implementation detail. For other implementations we get other values and > other relations. Any of our a priori assumptions could be incorrect. Even my > first assert may fail, if implementation uses a continuous array with > overallocation. > > I am now prepared a set of 14 __sizeof__ patches (should it be one issue or > 14 individual issues in bugtracker?), and I feel a great desire not to write > tests at all. > Without tests how can you have any confidence the patches are correct (or will continue to be correct)? Just because something is implementation dependent doesn't mean it should not be tested - instead the tests should be marked as cpython specific so that they aren't executed on other implementations. All the best, Michael > ___ > 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
[Python-Dev] Doc/ACKS and Misc/ACKS
> Date: Mon, 23 Jul 2012 19:17:32 +0200 > From: Antoine Pitrou > To: python-dev@python.org > Subject: [Python-Dev] Doc/ACKS and Misc/ACKS > >> > Doc/ACKS.txt is *only* for acknowledging documentation >> > contributions. Serhiy is already in Misc/ACKS. No need to add him >> > to Doc/ACKS.txt. >> > 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 I created an issue for this here: http://bugs.python.org/issue15437 --Chris ___ 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 (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
On 23.07.12 22:46, Michael Foord wrote: I am now prepared a set of 14 __sizeof__ patches (should it be one issue or 14 individual issues in bugtracker?), and I feel a great desire not to write tests at all. Without tests how can you have any confidence the patches are correct (or will continue to be correct)? Tests may not provide this. If we add a new dynamically allocated data or change the size of the old and forgot to reflect this in __sizeof__, then non modified tests not notice this. __sizeof__ returns 42. What is 42? ___ 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
Brian Curtin wrote: On Mon, Jul 23, 2012 at 1:28 PM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/07/12 19:30, Eli Bendersky wrote: 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 +1 too. Before everyone else on the list just writes a two character "+1" response, can we just assume that if you don't speak up, you're ok with it? You mean I don't get to be clever and say +1 + too == +3 ? ;) ~Ethan~ ___ 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 (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct
Zitat von Serhiy Storchaka : On 23.07.12 22:46, Michael Foord wrote: I am now prepared a set of 14 __sizeof__ patches (should it be one issue or 14 individual issues in bugtracker?), and I feel a great desire not to write tests at all. Without tests how can you have any confidence the patches are correct (or will continue to be correct)? Tests may not provide this. If we add a new dynamically allocated data or change the size of the old and forgot to reflect this in __sizeof__, then non modified tests not notice this. __sizeof__ returns 42. What is 42? 42 is most likely not the right answer, as the size should be a multiple of four. The point of writing tests for the sizeof code is that you detect your own mistakes *in writing the test case*. The value of the test case is not so much that it provides detection of regressions, but that you notice the bug once you write the test case. You may argue that then there is no value in committing the test case, but there is also no harm in doing so. In addition, it *may* catch regressions: if somebody changes the layout of an object, the corresponding test most likely fails. Maybe the fix is trivial and just in the test, but maybe the layout changed fundamentally, and the author forgot to change sizeof along with the structure change. You wouldn't have to write 14 patches if implementing sizeof correctly was easy. Please see the existing extensive tests for inspiration on how to add new ones. Regards, 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] 2to3 porting HOWTO: setup.py question
On Mon, Jul 23, 2012 at 12:21 AM, Oscar Benjamin wrote: >> On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin >> wrote: >> > On 22 July 2012 14:08, R. David Murray wrote: >> > >> > > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik >> > > >> > > wrote: >> > > > http://docs.python.org/py3k/howto/pyporting.html#during-installation >> > > > >> > > > What's the point in making implicit Python 3 check here: >> > > > try: # Python 3 >> > > > from distutils.command.build_py import build_py_2to3 as build_py >> > > > except ImportError: # Python 2 >> > > > from distutils.command.build_py import build_py >> > > > >> > > > instead of explicit check like: >> > > > import sys >> > > > if sys.version_info[0] >= 3: >> > > > from distutils.command.build_py import build_py_2to3 as build_py >> > > >> > > It's called testing for the thing that actually matters, rather than >> > > testing a constant with a much broader meaning. Yes, in this case the >> > > results are the same, but IMO it is better programming practice to >> > > test >> > > the thing that actually matters when you can. >> > >> > >> > I recently changed a setup.py from try/ImportError to an explicit >> > sys.version_info check. I'm not totally sure how to reproduce this but I >> > had a problem where I was installing into a 2.x virtualenv and it was >> > running 2to3 during install and subsequently failing to import the 3.x >> > code >> > (the problem didn't occur when using the same python that generated the >> > virtualenv). >> > >> > I may be wrong but I imagined that sometimes build_py_2to3 is importable >> > on >> > 2.x, perhaps for cross-building or something. In any case 'testing the >> > thing that matters' means testing what version of Python you are about >> > to >> > install into not whether the python version supports running 2to3. >> >> I'm not familiar with distutils, really, so you could be right about >> what it is important to test. I was commenting based on the code >> snippet presented, which just deciding which "build" object to use. >> If build_py_2to3 can be imported by python2 and subsequently screws up >> the build, then yes the logic is incorrect. But I have to defer to the >> packaging people on that. (I wish I had time to help with packaging >> because it is important, but it doesn't seem like a sensible place for >> me personally to spend my currently available time.) > > > I'm not currently able to reproduce the problem on this machine. I think I > was using pip/easy_install to install distribution X from PyPI that depended > on distribution Y also on PyPI into an isolated 2.x virtualenv and found > that distribution Y was converted with 2to3 when it was automatically > installed. It could be a bug but I'm not confident enough with virtualenv to > say that it wasn't just me messing things up somehow. > > Either way I still think that in this particular case a version check is the > most explicit and appropriate thing to do. The author of a distribution that > is distributed as Python 2.x code and installed on Python 3.x using 2to3 > knows precisely when they want 2to3 to run and when they don't so why not > make that explicit? > > As an aside, I find the check slightly easier to read if it is written like: > > if sys.version_info >= (3, 0): > from distutils.build_py import build_py_2to3 as build_py Yes. This looks better. If we reached consensus, I wonder how hard is it to find somebody who have the rights and able to fix the documentation: http://docs.python.org/py3k/howto/pyporting.html#during-installation -- anatoly t. ___ 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] 2to3 porting HOWTO: setup.py question
On 22/07/2012 15:57, R. David Murray wrote: I'm not familiar with distutils, really, so you could be right about what it is important to test. I was commenting based on the code snippet presented, which just deciding which "build" object to use. If build_py_2to3 can be imported by python2 and subsequently screws up the build, then yes the logic is incorrect. That can’t happen. The *_2to3 classes (don’t forget build_scripts_2to3) only exist in 3.x and work with a version check or an import with fallback. There is no cross-version-build at all in distutils. 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] 2to3 porting HOWTO: setup.py question
On 23 July 2012 23:27, Éric Araujo wrote: > On 22/07/2012 15:57, R. David Murray wrote: > >> I'm not familiar with distutils, really, so you could be right about >> what it is important to test. I was commenting based on the code >> snippet presented, which just deciding which "build" object to use. >> If build_py_2to3 can be imported by python2 and subsequently screws up >> the build, then yes the logic is incorrect. >> > > That can’t happen. The *_2to3 classes (don’t forget build_scripts_2to3) > only exist in 3.x and work with a version check or an import with fallback. > There is no cross-version-build at all in distutils. > I'm regretting the fact that I didn't keep notes of exactly what I was doing and I can't reproduce this now but this did happen to me when using one of pip/easy_install in a virtualenv. As I said earlier it may have been a mistake on my part as I'm not confident with virtualenv. At the time when I looked at the files in my pretty much empty virtualenv the main things I could see where related to setuptools so I guessed that some kind of setuptools monkey-patch had made build_py_2to3 importable and changed the setup.py to an explicit version check which fixed the problem in that environment. Oscar. ___ 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] 2to3 porting HOWTO: setup.py question
On Tue, Jul 24, 2012 at 1:27 AM, Éric Araujo wrote: > On 22/07/2012 15:57, R. David Murray wrote: >> >> I'm not familiar with distutils, really, so you could be right about >> what it is important to test. I was commenting based on the code >> snippet presented, which just deciding which "build" object to use. >> If build_py_2to3 can be imported by python2 and subsequently screws up >> the build, then yes the logic is incorrect. > > > That can’t happen. The *_2to3 classes (don’t forget build_scripts_2to3) > only exist in 3.x and work with a version check or an import with fallback. > There is no cross-version-build at all in distutils. Python 3 check explicitly tells the reader that 2to3 should only be used in Python 3. Otherwise everybody need to guess when this *_2to3 tools are triggered. As for me, I see no technical limitations why *_2to3 can not be run by Python 2 (PyPy, RPython or whatever). Maybe I don't have Python3, but want to build my package for Python 3. In ideal world it is possible. -- anatoly t. ___ 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
