Paolo Benvenuto added the comment:
> As a general rule, don't use `nargs` like this where there's ambiguity as to
> how many values will be allocated to the argument.
What could I use instead of nargs?
--
___
Python
Paolo Melchiorre added the comment:
Thank you all for the feedback, also I have been using python for years and
contributing to other python-based projects it is my first PR to Cpython and I
don't know if my contribution to the discussion is foreseen.
It seems to me that adding
New submission from Paolo Benvenuto :
I'm using argparse with this code:
parser = argparse.ArgumentParser(
description='Scan a media tree in order to generate cache files suitable
for showing a beautiful web gallery',
)
parser.add_argument(
"config_file_or_a
Change by Paolo Melchiorre :
--
keywords: +patch
pull_requests: +27586
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29317
___
Python tracker
<https://bugs.python.org/issu
New submission from Paolo Melchiorre :
It is very common to construct a variable containing alphanumeric values as a
basis for generating random strings, especially in the web environment as a
slug to be used in URLs:
>>> import string
>>> ascii_alphanumerics = st
Paolo Lammens added the comment:
I was about to create the exact same ticket; I'm nudging this.
--
nosy: +plammens
___
Python tracker
<https://bugs.python.org/is
Change by Paolo Lammens :
--
title: Asyncio loop.create_server doesn't bind to any interface if host is a
sequence with jus the empty string -> Asyncio loop.create_server doesn't bind
to any interface if host is a sequence with just the
New submission from Paolo Lammens :
When a sequence containing just the empty string (e.g. `['']`) is passed as the
`host` parameter of `loop.create_server`, the server seems not to bind to any
network interface. Since, per the
[documentation](https://docs.python.org/3/libra
Change by Paolo Lammens :
--
title: inspect.iscoroutine returns False for asynchronous generator functions
-> inspect.iscoroutine returns False for asynchronous generator methods
___
Python tracker
<https://bugs.python.org/issu
Change by Paolo Lammens :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue42760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paolo Lammens added the comment:
Correction:
```
ValueError: callable operator.attrgetter('spam') is not supported by signature
```
--
___
Python tracker
<https://bugs.python.o
New submission from Paolo Lammens :
Currently, `inspect.signature` doesn't support all callables from the
`operator` module, e.g. `operator.attrgetter`:
```python
>>> import inspect
>>> import operator
>>> inspect.signature(operator.attrgetter("spam")
New submission from Paolo Lammens :
The `inspect.iscoroutinefunction` and `inspect.iscoroutine` functions return
`False` for the `asend`, `athrow` and `aclose` methods of asynchronous
generators (PEP 525). These are coroutine functions (i.e. one does e.g. `await
gen.asend(value)`) so I would
Paolo Lammens added the comment:
Hmm I think that’s unrelated; it’s a discussion about whether to add or not
the working directory at all. Here the issue is that the way it *is* added
differs between -c and -m (which isn’t documented). In both cases it is
added (I’m not discussing that) but
New submission from Paolo Lammens :
Tested on:
- Python 3.8.6 for Windows 10 64 bit
- Python 3.9.0 for Windows 10 64 bit
- Python 3.8.6 for Ubuntu 20.04
- Python 3.9.0 for Ubuntu 20.04
Originally asked here: https://stackoverflow.com/q/65024647/6117426
Paolo Marcheschi added the comment:
Please continue support for Solaris/IllumOS!
This is very important for us.
--
nosy: +marcheschi
___
Python tracker
<https://bugs.python.org/issue42
Paolo Lammens added the comment:
The proposed addition (see attached PR) is the following note:
.. note::
The language doesn't place any restriction on the type or value of the
objects
yielded by the iterator returned by :meth:`__await__`, as this is
specific to
Change by Paolo Lammens :
--
keywords: +patch
pull_requests: +21365
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22320
___
Python tracker
<https://bugs.python.org/issu
New submission from Paolo Lammens :
The current specification of object.__await__ is just:
> `object.__await__(self)`
>
> Must return an iterator. Should be used to implement awaitable objects. For
> instance, `asyncio.Future` implements this method to be compatible with
Paolo Taddonio added the comment:
I am not sure if the following is resolved by your proposal, I post it just in
case:
The following code works:
1. class Singleton(object):
2. def __new__(cls, *args, **kwargs):
3. if not hasattr(cls, 'instance'):
Paolo Veglia added the comment:
I had the same issue as Jonathan with Python 3.5.1, big chunks of data get
truncated (to ~85KB).
The problem disappears when splitting original data into smaller chunks:
def _write(self,data):
chunk_size = 1024
for chunk in (data[i:i
Changes by Paolo Elvati :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11839>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Paolo Elvati :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue11839>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Paolo Elvati :
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11839>
___
___
Python-bugs-
New submission from Paolo Elvati :
Hi,
when a default is specified for a file argument that is open with writing
permission (FileType('w')), the default file is always created even if the
argument is specified in the command line.
For example he code:
import argpar
New submission from paolo :
I wish to propose a useful and smart method modify in Tkinter Library:
Previously to scroll this widget we had to write an external function
(recalling xview_moveto and xview_scroll).
With my method this operation is cleared and the same as all other
widgets (just
Paolo 'Blaisorblade' Giarrusso added the comment:
-fno-gcse is controversial.
Even if it might avoid jumps sharing, the impact of that option has to
be measured, since common subexpression elimination allows omitting some
recalculations, so disabling global CSE might have a negative
Paolo 'Blaisorblade' Giarrusso added the comment:
>Probably #if the definitions of Py_LIKELY and Py_UNLIKELY instead of
__builtin_expect so new compilers can easily add their own definitions.
This was done in the first version, but with the currently supported
compilers it's
Paolo 'Blaisorblade' Giarrusso added the comment:
Given a 10% speedup on some systems, and statistically insignificant
changes on other systems, I would still apply the patch, even simply
because the bitmask part simply makes more sense.
I'm not sure about the goto part, but
Paolo 'Blaisorblade' Giarrusso added the comment:
Yep, agreed. It could be quite cool to rely on __attribute__((cold)) to
mark format_exc_check_arg(), but that only works with newer gcc's. I
guess I'll add many likely() by hand - in some cases GCC might already
get it right
Paolo 'Blaisorblade' Giarrusso added the comment:
Also, GCC 2.95 does not support the construct, GCC 2.96 is required.
So, I'd suggest defining likely/unlikely unconditionally and using this,
which leads to less code overall:
# if (__GNUC__ < 2) || ((__GNUC__ == 2) &&
Changes by Paolo 'Blaisorblade' Giarrusso :
--
nosy: +blaisorblade
___
Python tracker
<http://bugs.python.org/issue4715>
___
___
Python-bugs-l
Paolo 'Blaisorblade' Giarrusso added the comment:
#4715 is interesting, but is not really about superinstructions.
Superinstructions are not created because they make sense; any common
sequence of opcodes can become a superinstruction, just for the point of
saving dispatches. And th
Paolo 'Blaisorblade' Giarrusso added the comment:
If speedup on other machines are confirmed, a slowdown of less than 2%
should be acceptable (it's also similar to the statistic noise I have on
my machine - it's a pity pybench does not calculate the standard
deviation o
Paolo 'Blaisorblade' Giarrusso added the comment:
Ok, then vmgen adds almost just direct threading instead of indirect
threading.
Since the purpose of superinstructions is to eliminate dispatch
overhead, and that's more important when little actual work is done,
what about
Changes by Paolo 'Blaisorblade' Giarrusso :
--
nosy: +blaisorblade
___
Python tracker
<http://bugs.python.org/issue4896>
___
___
Python-bugs-l
Paolo 'Blaisorblade' Giarrusso added the comment:
A couple percent maybe is not worth vmgen-ing. But even if I'm not a
vmgen expert, I read many papers from Ertl about superinstructions and
replication, so the expected speedup from vmgen'ing is much bigger.
Is there some m
Paolo 'Blaisorblade' Giarrusso added the comment:
> Same for CPU-specific tuning: I don't think we want to ship Python
with compiler flags which depend on the particular CPU being used.
I wasn't suggesting this - but since different CPUs have different
optimization ru
Paolo 'Blaisorblade' Giarrusso added the comment:
The standing question is still: can we get ICC to produce the expected
output? It looks like we still didn't manage, and since ICC is the best
compiler out there, this matters.
Some problems with SunCC, even if it doesn't
Paolo 'Blaisorblade' Giarrusso added the comment:
@ ajaksu2
> Applying your patches makes no difference with gcc 4.2 and gives a
> barely noticeable (~2%) slowdown with icc.
"Your patches" is something quite unclear :-)
Which are the patch sets you are comparing?
And
Paolo 'Blaisorblade' Giarrusso added the comment:
@skip:
In simple words, the x86 call:
call 0x2000
placed at address 0x1000 becomes:
call %rip + 0x1000
RIP holds the instruction pointer, which will be 0x1000 in this case
(actually, I'm ignoring the detail that when executin
Paolo 'Blaisorblade' Giarrusso added the comment:
I finally implemented my suggestion for the switch elimination.
On top of threadedceval5.patch, apply abstract-switch-reduced.diff and
then restore-old-oparg-load.diff to test it.
This way, only computed goto's are used. I wou
Changes by Paolo 'Blaisorblade' Giarrusso :
Added file: http://bugs.python.org/file12634/restore-old-oparg-load.diff
___
Python tracker
<http://bugs.python.
Changes by Paolo 'Blaisorblade' Giarrusso :
Added file: http://bugs.python.org/file12633/abstract-switch-reduced.diff
___
Python tracker
<http://bugs.python.
Paolo 'Blaisorblade' Giarrusso added the comment:
@pitrou:
Argh, reference counting hinders even that?
I just discovered another problem caused by refcounting.
Various techniques allow to create binary code from the interpreter
binary, by just pasting together the code for
Paolo 'Blaisorblade' Giarrusso added the comment:
@alexandre: if you add two labels per opcode and two dispatch tables,
one before (like now) and one after the parameter fetch (where we have
the 'case'), you can keep the same speed.
And under the hood we also had two di
Paolo 'Blaisorblade' Giarrusso added the comment:
@Skip: if one decides to generate binary code, there is no need to use
switches. Inline threading (also known as "code copying" in some
research papers) is what you are probably looking for:
http://blog.mozilla.com/dmandel
Paolo 'Blaisorblade' Giarrusso added the comment:
@Alexandre:
> > So, can you try dropping the switch altogether, using always computed
> > goto and seeing how does the resulting code get compiled?
> Removing the switch won't be possible unless we change t
Paolo 'Blaisorblade' Giarrusso added the comment:
Daniel, I forgot to ask for the compilation command line you used, since
they make a lot of difference. Can you post them? Thanks
___
Python tracker
<http://bugs.python.
Paolo 'Blaisorblade' Giarrusso added the comment:
1st note: is that code from the threaded version? Note that you need to
modify the source to make it accept also ICC to try that.
In case you already did that, I guess the patch is not useful at all
with ICC since, as far as I can see
Paolo 'Blaisorblade' Giarrusso added the comment:
> I'm not an expert in this kind of optimizations. Could we gain more
speed by making the dispatcher table more dense? Python has less than
128 opcodes (len(opcode.opmap) == 113) so they can be squeezed in a
smaller table.
Paolo 'Blaisorblade' Giarrusso added the comment:
About miscompilations: the current patch is a bit weird for GCC, because
you keep both the switch and the computed goto.
But actually, there is no case in which the switch is needed, and
computed goto give less room to GCC's ch
Paolo 'Blaisorblade' Giarrusso added the comment:
> I attached some additional benchmarks on SunOS. So far, it seems the
benefits of the proposed optimization are highly compiler-dependent.
Well, it would be more correct to say that as you verified for GCC 3.4,
"miscompil
Paolo 'Blaisorblade' Giarrusso added the comment:
> We would have to change opcode.h for this to be truely useful (in
order to re-use OPCODE_LIST()).
Yep.
> I think that should be the subject of a separate bug entry for code
reorganization.
Agreed, I'll maybe tr
Paolo 'Blaisorblade' Giarrusso added the comment:
== On the patch itself ==
Why don't you use the C preprocessor instead of that Python code?
Sample code:
#define OPCODE_LIST(DEFINE_OPCODE) \
DEFINE_OPCODE(STOP_CODE, 0) \
DEFINE_OP
Paolo 'Blaisorblade' Giarrusso added the comment:
Topics
1) About different speedups on 32bits vs 64 bits
2) About PPC slowdown
3) PyPI
=== About different speedups on 32bits vs 64 bits ===
An interpreter is very register-hungry, so on x86_64 it spends much less
time on regi
Paolo 'Blaisorblade' Giarrusso added the comment:
> You may want to check out issue1408710 in which a similar patch was
> provided, but failed to deliver the desired results.
It's not really similar, because you don't duplicate the dispatch code.
It took me some
Paolo 'Blaisorblade' Giarrusso added the comment:
Some other comments.
The time saving of indirect threading are also associated with the
removal of the range check, but better branch prediction is the main
advantage.
> Also, the macro USE_THREADED_CODE should be renamed to s
Paolo 'Blaisorblade' Giarrusso added the comment:
Mentioning other versions as well.
The patch is so easy that it can be backported to all supported
versions, so I'm adding all of them (2.5 is in bugfix-only mode, and as
far as I can see this patch cannot be accept
Changes by Paolo 'Blaisorblade' Giarrusso :
--
nosy: +blaisorblade
___
Python tracker
<http://bugs.python.org/issue4753>
___
___
Python-bugs-l
60 matches
Mail list logo
