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
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)
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?
>
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 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
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 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
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
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
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
> 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
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
__
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
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
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/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: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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
"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
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
34 matches
Mail list logo
