typo... meant of course foo(*([0]*300))
Andrea
On Mon, Aug 6, 2018 at 9:57 AM Andrea Griffini wrote:
> With Python 2.7.15 what fails is a call with explicit arguments (e.g.
> `foo(0,0,0 ... 0,0)`), not the function definition.
> Calling with `foo([0]*300)` instead works.
>
>
With Python 2.7.15 what fails is a call with explicit arguments (e.g.
`foo(0,0,0 ... 0,0)`), not the function definition.
Calling with `foo([0]*300)` instead works.
On Mon, Aug 6, 2018 at 7:18 AM Stephen McDowell wrote:
> Hello Python Gurus,
>
> TL;DR: 3.7 released functions having greater than
May be is something obvious but I find myself forgetting often about
the fact that most modern CPUs can change speed (and energy consumption)
depending on a moving average of CPU load.
If you don't disable this "green" feature and the benchmarks are quick then
the
result can have huge variations d
>> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6.
Hmmm... When I was hearing the repeated belated saying that Python will
never ever jump
on the statically typed ship on each and every static type annotation
discussion I started to
worry this wasn't indeed the case (why the urge of
The PEP says that a None-aware function call operator (e.g. "f?(x, y)")
would break the rule of python that arguments are evaluated before the
function but this is not correct.
In Python the function is evaluated before the arguments (but of course the
CALL is made after the evaluation of the argu
Not really related but the PEP says that arguments in Python are evaluated
before the function (as a reason to reject the idea of None-aware function
call) but this is not the case:
>>> import dis
>>> dis.dis(lambda : f()(g()))
1 0 LOAD_GLOBAL 0 (f)
Is it intended that closures created in exec statement/function cannot see
locals if the exec was provided a locals dictionary?
This code gives an error ("foo" is not found during lambda execution):
exec("def foo(x): return x\n\n(lambda x:foo(x))(0)", globals(), {})
while executes normally w
It's not the first time someone is confused by the server example of
https://docs.python.org/3/library/socketserver.html
where the receiving side is not making a loop over recv.
Moreover the documentation contains a misleading description of what really
happens:
"The difference is that the read
On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon wrote:
>
>
>
> It's not really our place to say if it makes sense for Arch to compile
> with valgrind flags turned on. It really depends on how they use Python in
> their Linux distribution and what their own goals are.
>
I already asked the package m
ning at 66% the speed of plain ./configure && make Python on my
system. Is this setting reasonable for general users?
If they are good defaults, why aren't them the default?
Andrea Griffini
___
Python-Dev mailing list
Python-Dev@python.org
more
complicate.
Anyway I was just curious to know if there was any technical reason (that I
couldn't see) or if it was more a style/historic reason.
Thank you for the clarification
On Wed, Jan 28, 2015 at 1:40 PM, Nick Coghlan wrote:
> On 28 January 2015 at 21:21, Greg Ewing
> wrote:
Sorry if the question is naive, but why is co_names needed? Wouldn't be
simpler to just use co_consts?
Andrea
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mail
In a function call with named arguments the code generated doesn't follow
that pattern:
dis.dis(lambda : f(a=1,b=2,c=3))
displays:
1 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 (1)
9 LOAD
help(sum) tells clearly that it should be used to sum numbers and not
strings, and with strings actually fails.
However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
Is this to be considered a bug?
Andrea
___
Python-Dev mailing list
Python-De
case?
Andrea Griffini
___
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
er it gets ALSO allocated in
co_varnames even if the local slot apparently is not accesible because
*_FAST opcodes are not generated.
Is there a technical reason for this? It happens in CPython 2, 3 and even
in PyPy...
Andrea Griffini
___
Python-Dev ma
On Fri, Jan 11, 2013 at 5:08 PM, Christian Heimes wrote:
> It has more issues. Coverity has sent me some complains, see attachment.
The second complaint seems a false positive; if self->extra is null
then children is set to 0 and following code is not executed.
___
On Sun, Jan 6, 2013 at 10:40 PM, Kristján Valur Jónsson
wrote:
> A linear lookup in a handful of slots can't be that much of a bother, it is
> only with larger number of entries that the O(1) property starts to matter.
Something that I was thinking is if for small tables does make sense
to actu
On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl wrote:
> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
>>> Daniel Holth gmail.com> writes:
>>>
How does this compare to the markerlib approach? In markerlib you just
make sure all the AST
> My benchmark.py script calibrates automatically the number of loops to
> take at least 100 ms, and then repeat the test during at least 1.0
> second.
>
> Using time instead of a fixed number of loops is more reliable because
> the test is less dependent on the system activity.
I've also been bit
On Mon, Aug 20, 2012 at 11:42 PM, Antoine Pitrou wrote:
>> In the spirit of RawIO.write(), I think RawIO.writelines() could return
>> the number of bytes written (allowing for partial writes).
When dealing with a non-blocking IO what you normally do is use number
returned from the write call to m
On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich wrote:
> You wrote a program to find the two smallest ints that would have a
> hash collision in the CPython set implementation? I'm impressed. And
> by impressed I mean frightened.
?
print set([0,8]).pop(), set([8,0]).pop()
Andrea
_
On Jan 27, 2008 5:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Deprecating int() is pretty radical, I think it would have to
> happen in the distant future. OR not at all. I'm at best +0 on this,
> more like exactly 0. I realize that in practice this kills the idea.
> The "purist" argume
Martin v. Löwis wrote:
> Neal Norwitz schrieb:
>
>> Wow, I didn't realize I was that much of a broken record. :-)
>> I don't even remember talking to Thomas about it, only Guido. I
>> definitely would like to see all private header files clearly denoted
>> by their name or directory.
>>
>
I'm experimenting with a patch for dictionary lookup caching, the
main idea being avoiding the lookup of a constant (co_names) in
a dictionary if the dictionary didn't change since last lookup.
Currently the cache is held in a structure that is parallel to
co_names (the LOAD_GLOBAL opcode uses opa
25 matches
Mail list logo
