Hi,
On 3/3/12 2:28 AM, Vinay Sajip wrote:
> So, looking at a large project in a relevant problem domain, unicode_literals
> and native string markers would appear not to adversely impact readability or
> performance.
What are you trying to argue? That the overall Django testsuite does
not do a lo
"Martin v. L?wis" wrote:
> > I think it would be nice for Python3.3 to implement the PEP-3118
> > suggestion:
> >
> > 'c' -> UCS1
> >
> > 'u' -> UCS2
> >
> > 'w' -> UCS4
>
> What is the use case for these format codes?
Unfortunately I've only worked with UTF-8 so far and I'm not too familiar
The main reason why I raised the issue is this: If Python-3.3 is shipped
with 'u' -> UCS4 in the array module and *then* someone figures out that
the above format codes are a great idea, we'd be stuck with yet another
format code incompatibility.
Ah. I think the array module should maintain comp
On Wed, Mar 7, 2012 at 8:50 PM, Stefan Krah wrote:
> *If* the arrays that Victor mentioned give one character per array location,
> then memoryview(str) could be used for zero-copy slicing etc.
A slight tangent, but it's worth trying to stick to the "code point"
term when talking about what Unico
On Wed, Mar 7, 2012 at 9:39 PM, wrote:
> Ah. I think the array module should maintain compatibility with Python 3.2,
> i.e. "u" should continue to denote Py_UNICODE, i.e. 7fa098f6dc6a should be
> reverted.
>
> It may be that the 'u' code is not particularly useful, but AFAICT, it never
> was usef
I propose adding an optional (keyword-only?) 3rd parameter, "builtins"
to exec(), eval(), __import__() and any other functions that take
locals and globals as parameters.
Currently, Python code is evaluated in a context of three name spaces;
locals(), globals() and builtins.
However, eval & exec
2012/3/7 Mark Shannon :
> Currently, it is impossible to allow one function access to sensitive
> functions like open(), while denying it to others, as any code can then
> get the builtins of another function via f.__globals__['builtins__'].
> Separating builtins from globals could solve this.
I l
On Wed, Mar 7, 2012 at 10:56, Benjamin Peterson wrote:
> 2012/3/7 Mark Shannon :
> > Currently, it is impossible to allow one function access to sensitive
> > functions like open(), while denying it to others, as any code can then
> > get the builtins of another function via f.__globals__['builti
Hi,
I found a problem in the current "yield from" implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
Test code:
def g1():
yield "y1"
yield from g2()
yield "y4"
def g2():
yield "y2"
try:
yield from gi
Armin Ronacher active-4.com> writes:
> What are you trying to argue? That the overall Django testsuite does
> not do a lot of string processing, less processing with native strings?
>
> I'm surprised you see a difference at all over the whole Django
> testsuite and I wonder why you get a slowdo
2012/3/7 Stefan Behnel :
> The problem is in steps 5) and 6), which are handled by g1 at the wrong
> call level. They shouldn't lead to undelegation and termination in g1, just
> to an exception being raised in g2.
That looks wrong indeed.
>
> I ran into this while trying to adapt the implementat
At the language summit today I got clearance to merge my importlib
bootstrap branch (http://hg.python.org/sandbox/bcannon#bootstrap_importlib)
thanks to performance being about 5% slower using the normal_startup
(which, as Thomas Wouters said, is less than the difference of using the
newest gcc in
On Thu, Mar 8, 2012 at 8:36 AM, Vinay Sajip wrote:
> Anyway, it doesn't really
> matter now, since the latest version of the PEP no longer mentions those
> figures.
Indeed, I deliberately removed the part about performance concerns,
since I considered it a distraction from what I see as the hear
On 7 March 2012 23:05, Brett Cannon wrote:
> At the language summit today I got clearance to merge my importlib bootstrap
> branch (http://hg.python.org/sandbox/bcannon#bootstrap_importlib) thanks to
> performance being about 5% slower using the normal_startup (which, as Thomas
> Wouters said, is
Since PEP 412 has code that doesn't break tests anymore (thanks to hash
randomization), it was just accepted. Mark, can you make sure there is an
up-to-date patch in the tracker so people can potentially look at the code
at the sprints here at PyCon? And also please apply for core dev privileges
(h
On Thu, Mar 8, 2012 at 6:40 AM, Stefan Behnel wrote:
> I ran into this while trying to adapt the implementation for Cython, which
> has a different generator type implementation but otherwise uses more or
> less the same code now. But I'm not sure how to fix this one without major
> changes to the
2012/3/7 Benjamin Peterson :
> 2012/3/7 Stefan Behnel :
>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>> call level. They shouldn't lead to undelegation and termination in g1, just
>> to an exception being raised in g2.
>
> That looks wrong indeed.
Fixed as of 3357eac1
On Thu, Mar 8, 2012 at 10:00 AM, Benjamin Peterson wrote:
> 2012/3/7 Benjamin Peterson :
>> 2012/3/7 Stefan Behnel :
>>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>>> call level. They shouldn't lead to undelegation and termination in g1, just
>>> to an exception being
http://mail.python.org/pipermail/python-dev/2012-March/117396.html
Stefan Behnel posted:
> I found a problem in the current "yield from" implementation ...
[paraphrasing]
g1 yields from g2
g2 yields from g1
XXX python follows the existing delegation without checking re-entrancy
On Thu, Mar 8, 2012 at 10:32 AM, Jim J. Jewett wrote:
> How is this a problem?
>
> Re-entering a generator is a bug. Python caught it and raised an
> appropriate exception.
No, the problem was that the interpreter screwed up the state of the
generators while attempting to deal with the erroneous
http://mail.python.org/pipermail/python-dev/2012-March/117395.html
Brett Cannon posted:
[in reply to Mark Shannon's suggestion of adding a builtins parameter
to match locals and globals]
> It's a mess right now to try to grab the __import__()
> implementation and this would actually help clarif
Hi,
During the Language Summit 2011 (*), it was discussed that PyPy and
Jython don't support non-string key in type dict. An issue was open to
emit a warning on such dict, but the patch has not been commited yet.
I'm trying to Lib/test/crashers/losing_mro_ref.py: I wrote a patch
fixing the specif
2012/3/7 Victor Stinner :
> So my question is: what is the use case of such dict? Why do we still
> support it?
Probably a side-effect of implementation.
> Can't we simply raise an error if the dict contains
> non-string keys?
Sounds okay to me.
--
Regards,
Benjamin
__
> During the Language Summit 2011 (*), it was discussed that PyPy and
> Jython don't support non-string key in type dict. An issue was open to
> emit a warning on such dict, but the patch has not been commited yet.
It's the issue #11455. As written in the issue, there are two ways to
create such t
On Wed, Mar 7, 2012 at 5:45 PM, Victor Stinner wrote:
> > During the Language Summit 2011 (*), it was discussed that PyPy and
> > Jython don't support non-string key in type dict. An issue was open to
> > emit a warning on such dict, but the patch has not been commited yet.
>
> It's the issue #114
I see that I've misunderstood this entirely, nevermind me.
--Brett
On 08/03/12 14:48, Brett Wilkins wrote:
> I assume when you say "non-string keys" this includes numbers.
>
> But in Pypy, I can certainly use numbers:
{'1':1, 1:2}.keys()
> ['1', 1]
>
> I can even use a lambda (obviously not
I assume when you say "non-string keys" this includes numbers.
But in Pypy, I can certainly use numbers:
>>> {'1':1, 1:2}.keys()
['1', 1]
I can even use a lambda (obviously not a string, a number, nor what I
would consider a primitive):
>>> {'1':1, (lambda x: x):2}.keys()
['1', at 0x7fdb0b8
On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson wrote:
> 2012/3/7 Victor Stinner :
>> Can't we simply raise an error if the dict contains
>> non-string keys?
>
> Sounds okay to me.
For 3.3, the most we can do is trigger a deprecation warning, since
removing this feature *will* break currently
On Thu, Mar 08, 2012 at 12:20:21PM +1000, Nick Coghlan wrote:
> On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson
> wrote:
> > 2012/3/7 Victor Stinner :
> >> Can't we simply raise an error if the dict contains
> >> non-string keys?
> >
> > Sounds okay to me.
>
> For 3.3, the most we can do is t
On Wed, Mar 7, 2012 at 8:39 PM, Victor Stinner wrote:
> So my question is: what is the use case of such dict?
Well, I use them for this:
http://pypi.python.org/pypi/AddOns
(And I have various other libraries that depend on that library.)
Short version: AddOns are things you can use to dynamic
Hi Stefan,
Stefan Behnel wrote:
> could you please stop bashing CPython for no good reason, especially on
> python-dev? Specifically, to call it broken beyond repair is a rather
> offensive claim, especially when made in public.
Sorry if you were offended. I am just trying to point out that
CPyt
On Wed, Mar 7, 2012 at 5:42 PM, Benjamin Peterson wrote:
> 2012/3/7 Victor Stinner :
>> So my question is: what is the use case of such dict? Why do we still
>> support it?
>
> Probably a side-effect of implementation.
>
>> Can't we simply raise an error if the dict contains
>> non-string keys?
>
Maciej Fijalkowski, 06.03.2012 00:08:
> For a comparison, PyPy sandbox is a compiled from higher-level
> language program that by design does not have all sorts of problems
> described. The amount of code you need to carefully review is very
> minimal (as compared to the entire CPython interpreter)
PJ Eby wrote:
Short version: AddOns are things you can use to dynamically extend
instances -- a bit like the "decorator" in "decorator pattern" (not to
be confused with Python decorators). Rather than synthesize a unique
string as a dictionary key, I just used the AddOn classes themselves as
34 matches
Mail list logo
