On Oct 6, 2011, at 10:11 PM, Cameron Simpson wrote:
> Hmm. Glyph seemed to be arguing both ways - that everything should be
> tested as root, and also that root is not special. I have unease over the
> former and disagreement over the latter.
Your reply to Stephen suggests that we are actually i
Steven D'Aprano wrote:
Given that strings are immutable, would it not be an obvious
optimization for replace to return the source string unchanged if the
old and new substrings are equal,
Only if this situation occurs frequently enough to outweigh
the overhead of comparing the target and repl
Benjamin Peterson wrote:
Why not just have it return 0 on error? This would be more consistent with API
functions that return "false" values like NULL
But that would make it confusingly different from all the other
functions that return ints. The NULL convention is only used
when the function
On 07Oct2011 13:42, Steven D'Aprano wrote:
| Cameron Simpson wrote:
| >On 06Oct2011 04:26, Glyph wrote:
| >| On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
| >| > Surely VERY FEW tests need to be run as root, and they need careful
| >| > consideration. The whole thing (build, full test suite
Cameron Simpson wrote:
On 06Oct2011 04:26, Glyph wrote:
| On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
| > Surely VERY FEW tests need to be run as root, and they need careful
| > consideration. The whole thing (build, full test suite) should
| > not run as root.
|
| This is news to me -
On 07Oct2011 12:46, Andrew Bennetts wrote:
| On Fri, Oct 07, 2011 at 08:27:01AM +1100, Cameron Simpson wrote:
| […]
| > | >> running buildbot tests as root does not reflect the experience of
| > | >> non-root users. It seems some tests need to be run both ways just for
| > | >> correctness testing
On Fri, Oct 07, 2011 at 08:27:01AM +1100, Cameron Simpson wrote:
[…]
> | >> running buildbot tests as root does not reflect the experience of
> | >> non-root users. It seems some tests need to be run both ways just for
> | >> correctness testing.
> |
> | (except I'd say "all", not "some")
>
> No.
Victor Stinner wrote:
Hum, copy-paste failure, I wrote numbers in the wrong order, it's:
(test: Python 3.2 => Python 3.3)
"A".join(["Bob"]*100)): 0.92 => 2.11
("C"+"AB"*300).rfind("CA"): 0.57 => 1.03
("A" + ("Z"*128*1024)).replace("A", "BB", 1): 0.25 => 0.50
I improved str.replace(): it's now 5
(also, is it useful? PEP 393 has added a flurry of new macros to
unicodeobject.h and it's getting hard to know which ones are genuinely
useful, or well-performing)
Please understand that not all of them have been added by PEP 393
genuinely. Some have only be added by individual committers,
and w
Am 06.10.11 14:57, schrieb Amaury Forgeot d'Arc:
Hi,
with the new Unicode API, there are many checks like:
+if (PyUnicode_READY(*filename))
+goto handle_error;
I think you are misinterpreting what you are seeing.
There are not *many* such checks. Of the PyUnicode_READY
chec
2011/10/6 Benjamin Peterson :
> Why not just have it return 0 on error? This would be more consistent with API
> functions that return "false" values like NULL and would just be
>
> if (!PyUnicode_READY(s)) return NULL;
Most functions of the Python C API seems to follow one of two ways to
indicate
On Thu, 6 Oct 2011 17:40:20 -0400
Nick Coghlan wrote:
> On Thu, Oct 6, 2011 at 4:47 PM, Benjamin Peterson wrote:
> > Amaury Forgeot d'Arc gmail.com> writes:
> >
> >> I'd prefer it was written :
> >> if (PyUnicode_READY(*filename) < 0)
> >> because "< 0" clearly indicates an error conditio
On Fri, 7 Oct 2011 08:27:01 +1100
Cameron Simpson wrote:
>
> 2: Root _can_ corrupt things anywhere in the system (within the VM, of
>course, but the builtbot is a subset of it). A normal unprivileged user
>will not have write permission to thing like:
> the OS image
> the compil
On Thu, Oct 6, 2011 at 4:47 PM, Benjamin Peterson wrote:
> Amaury Forgeot d'Arc gmail.com> writes:
>
>> I'd prefer it was written :
>> if (PyUnicode_READY(*filename) < 0)
>> because "< 0" clearly indicates an error condition.
>
> Why not just have it return 0 on error? This would be more c
On 06Oct2011 04:26, Glyph wrote:
| On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
| > Surely VERY FEW tests need to be run as root, and they need careful
| > consideration. The whole thing (build, full test suite) should
| > not run as root.
|
| This is news to me - is most of Python not sup
Amaury Forgeot d'Arc gmail.com> writes:
> I'd prefer it was written :
>if (PyUnicode_READY(*filename) < 0)
> because "< 0" clearly indicates an error condition.
Why not just have it return 0 on error? This would be more consistent with API
functions that return "false" values like NULL a
On Thu, Oct 6, 2011 at 3:06 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote:
>
>>I still think 'venv' is preferable to any of the other options proposed
>>thus far.
>
> It's also nicely unique for googling. Funnily eno
Lennart Regebro wrote:
+1 for env or sandbox or something else with "box" in it.
Eggbox? Eggcrate? Incubator?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
On 10/06/2011 12:00 AM, Brett Cannon wrote:
> Please file a bug about the dead links so we can fix/remove them.
>
it's done in http://bugs.python.org/issue13117 (and I've also tried with
a patch).
Cheers,
francis
___
Python-Dev mailing list
Python-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote:
>I still think 'venv' is preferable to any of the other options proposed
>thus far.
It's also nicely unique for googling. Funnily enough, the top hit right now
for 'venv' is apparently Lua's project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/2011 12:12 PM, Nick Coghlan wrote:
> sandbox is a bit close to Victor's pysandbox for restricted execution
> environments.
>
> 'nest' would probably work, although I don't recall the 'egg'
> nomenclature featuring heavily in the current zipim
Éric Araujo writes:
> Le 04/10/2011 04:59, Stephen J. Turnbull a écrit :
> > I'm not familiar with the hg dev process (I use hg a lot, but so far
> > it Just Works for me :), but I would imagine they will move in that
> > direction as well.
"That direction" being "ability to attach notes to e
On Thu, Oct 6, 2011 at 12:50 PM, Barry Warsaw wrote:
> On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>
>>On Thu, 6 Oct 2011 12:02:05 -0400
>>Barry Warsaw wrote:
>>>
>>> >The first part is implemented in CPython; the second part needs a module
>>> >name to replace virtualenv. python -m pyth
On Thu, Oct 6, 2011 at 10:31 AM, Ronald Oussoren wrote:
> On 6 Oct, 2011, at 14:57, Amaury Forgeot d'Arc wrote:
>> I'd prefer it was written :
>> if (PyUnicode_READY(*filename) < 0)
>> because "< 0" clearly indicates an error condition.
>> That's how all calls to PyType_Ready are written, fo
Éric Araujo netwok.org> writes:
> Oh, let’s not forget naming. We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.
Another possible name
On 6 October 2011 17:02, Barry Warsaw wrote:
> I don't particularly like the -m interface though. Yes, it should work, but I
> also think there should be a command that basically wraps whatever the -m
> invocation is, just for user friendliness.
No problem with a wrapper, but the nice thing abou
On 10/06/11 18:02, Barry Warsaw wrote:
> On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:
>
>>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>>> I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid
>>> that picking something cute might make it harder to discover. `pythonv` or
>
On Thu, Oct 6, 2011 at 12:02 PM, Barry Warsaw wrote:
> Well, I have to be honest, I've *always* thought "nest" would be a good
> choice
> for a feature like this, but years ago (IIRC) PJE wanted to reserve that
> term
> for something else, which I'm not sure ever happened.
>
Actually, it was pre
+1 for env or sandbox or something else with "box" in it.
pythonbox? envbox? boxenv?
___
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/arch
On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>On Thu, 6 Oct 2011 12:02:05 -0400
>Barry Warsaw wrote:
>>
>> >The first part is implemented in CPython; the second part needs a module
>> >name to replace virtualenv. python -m pythonv doesn’t seem right.
>>
>> Nope, although `python -m virt
- Original Message -
> I started to play with virtualenv recently and wondered about the status
> of the similar feature in 3.3 (cpythonv). The last thread mentioned two
> bugs; one has been fixed since.
The pythonv branch is pretty much up to date with the default branch (3.3). I
regul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Éric,
Vinay is more up to date than I am on the current status of the
implementation. I need to update the PEP draft we worked on last spring
and get it posted (the WIP is at
https://bitbucket.org/carljm/pythonv-pep but is out of date with the
late
On Thu, 6 Oct 2011 12:02:05 -0400
Barry Warsaw wrote:
>
> >The first part is implemented in CPython; the second part needs a module
> >name to replace virtualenv. python -m pythonv doesn’t seem right.
>
> Nope, although `python -m virtualize` seems about perfect.
`python -m sandbox` ?
_
On Thu, 06 Oct 2011 17:52:05 +0200
Victor Stinner wrote:
> index << (kind - 1) and index * PyUnicode_CHARACTER_SIZE(str) were used
> in unicodeobject.c. It's not easy to understand this formula
index * PyUnicode_CHARACTER_SIZE(str)
is quite easy to understand to me.
I find it less cryptic tha
On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:
>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid
>> that picking something cute might make it harder to discover. `pythonv` or
>> `cpythonv` seem like good choices to me. Ma
On Thu, Oct 6, 2011 at 10:46, Éric Araujo wrote:
> Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid
>> that picking something cute might make it harder to discover. `pythonv` or
>> `cpythonv` seem like good choices to me. M
Le 06/10/2011 15:52, Antoine Pitrou a écrit :
The PyUnicode_KIND_SIZE macro is defined as follows. Its name looks
rather mysterious or misleading to me. Could we rename it to something
else?
What do you propose?
also, is it useful?
index << (kind - 1) and index * PyUnicode_CHARACTER_SIZE(st
Lars Buitinck wrote:
> >>> from collections import Counter
> >>> a = Counter([1,2,3])
> >>> b = a
> >>> a += Counter([3,4,5])
> >>> a is b
> False
>
> would become
>
> # snip
> >>> a is b
> True
Sounds like a good idea to me. You should open an issue in the tr
Le 06/10/2011 17:31, Barry Warsaw a écrit :
> I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid
> that picking something cute might make it harder to discover. `pythonv` or
> `cpythonv` seem like good choices to me. Maybe the former, so we could
> potentially have jythonv
On Thu, 6 Oct 2011 10:06:17 -0500
Brian Curtin wrote:
> On Thu, Oct 6, 2011 at 09:12, Éric Araujo wrote:
> > Oh, let’s not forget naming. We can’t reuse the module name virtualenv
> > as it would shadow the third-party module name, and I’m not fond of
> > “virtualize”: it brings OS-level virtual
On Oct 06, 2011, at 04:12 PM, Éric Araujo wrote:
>I started to play with virtualenv recently and wondered about the status
>of the similar feature in 3.3 (cpythonv). The last thread mentioned two
>bugs; one has been fixed since.
>
>Apart from the implicit vs. explicit download of distribute, are
On 6 Oct, 2011, at 14:57, Amaury Forgeot d'Arc wrote:
> Hi,
>
> with the new Unicode API, there are many checks like:
> +if (PyUnicode_READY(*filename))
> +goto handle_error;
>
> Every time I read it, I get it wrong:
> "If filename is ready, then fail"
> then I have to rem
On Thu, Oct 6, 2011 at 09:12, Éric Araujo wrote:
> Oh, let’s not forget naming. We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.
How ab
Am 06.10.2011 16:12, schrieb Éric Araujo:
> Oh, let’s not forget naming. We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.
How about clut
+if (PyUnicode_READY(path_unicode))
+return -1;
+
I think we need to discuss/reconsider the return value of
PyUnicode_READY. It's defined to give -1 on error currently.
If that sounds good, then the check for error should be a check
that it is -1.
Regards,
Martin
_
Hi,
I started to play with virtualenv recently and wondered about the status
of the similar feature in 3.3 (cpythonv). The last thread mentioned two
bugs; one has been fixed since.
Apart from the implicit vs. explicit download of distribute, are there
design issues to discuss? Can we do that wi
Hello,
The PyUnicode_KIND_SIZE macro is defined as follows. Its name looks
rather mysterious or misleading to me. Could we rename it to something
else?
(also, is it useful? PEP 393 has added a flurry of new macros to
unicodeobject.h and it's getting hard to know which ones are genuinely
useful, o
Hi,
> http://hg.python.org/cpython/rev/447f521ac6d9
> user:Antoine Pitrou
> date:Tue Oct 04 16:04:01 2011 +0200
> summary:
> When expandtabs() would be a no-op, don't create a duplicate string
>
> diff --git a/Lib/test/test_unicode.py b/Lib/test/test_unicode.py
> --- a/Lib/test
Hi,
Le 04/10/2011 04:59, Stephen J. Turnbull a écrit :
> Currently, in hg. git has a mechanism for adding notes which are
> automatically displayed along with the original commit message, and
> bzr is considering introducing such a mechanism.
Mercurial commits can contain an “extra” dictionary, b
Hi,
Le 03/10/2011 23:38, Terry Reedy a écrit :
> Is it both technically possible (with hg) and socially permissible (with
> us) to edit another's commit message?
Not easily. A changeset identifier is a hash of date, user, parent
changesets hashes, commit message and diff content; editing the co
Hi,
with the new Unicode API, there are many checks like:
+if (PyUnicode_READY(*filename))
+goto handle_error;
Every time I read it, I get it wrong:
"If filename is ready, then fail"
then I have to remember that the function returns either 0 or -1.
I'd prefer it was writte
Hum, copy-paste failure, I wrote numbers in the wrong order, it's:
(test: Python 3.2 => Python 3.3)
"A".join(["Bob"]*100)): 0.92 => 2.11
("C"+"AB"*300).rfind("CA"): 0.57 => 1.03
("A" + ("Z"*128*1024)).replace("A", "BB", 1): 0.25 => 0.50
I improved str.replace(): it's now 5 times faster instead of
On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
> Surely VERY FEW tests need to be run as root, and they need careful
> consideration. The whole thing (build, full test suite) should
> not run as root.
This is news to me - is most of Python not supported to run as root? I was
under the impr
Le 6 octobre 2011 10:09, Charles-François Natali a écrit :
>> But under certain circumstances (if a large block is requested), the
>> allocator uses mmap(), no?
>
> That's right, if the block requested is bigger than mmap_threshold
> (256K by default with glibc, forgetting the sliding window algor
>> > > > That's not a given. Depending on the memory allocator, a copy can be
>> > > > avoided. That's why the "str += str" hack is much more efficient under
>> > > > Linux than Windows, AFAIK.
>> > >
>> > > Even Linux will have to copy a block on realloc in certain cases, no?
>> >
>> > Probably so
> I'd have expect this test to fail on _any_ UNIX system if run as root.
> Root's allowed to write to stuff! Any stuff! About the only permission
> with any effect on root is the eXecute bit for the exec call, to prevent
> blindly running random data files.
You're right, here's another test on Lin
56 matches
Mail list logo
