[Python-Dev] Generated Bytecode ...
Hi all, When we compile a python script # test.py if 0: x = 1 python -mdis test.py There is no byte code for the condition. So my question is, the byte code generator removes the unused functions, variables etc…, is it right? What are the cases where the generator does not generate the byte codes ? Thank you, Stéphane -- Stéphane Wirtel - http://wirtel.be - @matrixise signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generated Bytecode ...
Thank you Brett, I am going to read the source code, I am going to give a presentation at PyCon.IE about this part and I wanted to be sure about the dead branches. Thanks On 22 Oct 2015, at 19:02, Brett Cannon wrote: > On Thu, 22 Oct 2015 at 09:37 Stéphane Wirtel wrote: > >> Hi all, >> >> When we compile a python script >> >> # test.py >> if 0: >> x = 1 >> >> python -mdis test.py >> >> There is no byte code for the condition. >> >> So my question is, the byte code generator removes the unused functions, >> variables etc…, is it right? >> > > Technically the peepholer removes the dead branch, but since the peepholer > is run on all bytecode you can't avoid it. > > >> >> What are the cases where the generator does not generate the byte codes ? >> > > It's not specified anywhere; it's just what the peepholer decides to > remove. The exact code can be found at > https://hg.python.org/cpython/file/default/Python/peephole.c . There has > been talk in the past for adding a -X flag to disable the peepholer, but it > never went any farther beyond that. -- Stéphane Wirtel - http://wirtel.be - @matrixise signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Where is defined the grammar of Python?
Hi all, Just to understand, we have the Parser/Python.asdl and Grammar/Grammar files. Which one is used for the AST ? I would like to understand this part of Python, could you help me? Thank you Stéphane -- Stéphane Wirtel - http://wirtel.be - @matrixise signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] EuroPython CPython Sprint?
Hi all, What do you think about a CPython sprint at EuroPython 2014? Regards, Stephane -- Stéphane Wirtel - http://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] EuroPython CPython Sprint?
On 8 May 2014, at 16:33, Brett Cannon wrote: > On Thu May 08 2014 at 10:25:44 AM, Stéphane Wirtel > wrote: > >> Hi all, >> >> What do you think about a CPython sprint at EuroPython 2014? >> > > Great, although I think that answer would be considered obvious since there > is no real negative to holding sprints. =) Are you indirectly asking if > anyone plans to lead such a sprint? Yes, I do, I can make the request to the EuroPython team for the sprint but: * I am not a Python Core Dev * I can't find the right issues for the sprinters * I can't help the sprinters with the issues. * I am a newbie in the CPython code Thus, who would be interested in a CPython sprint? > > -Brett Stéphane, -- Stéphane Wirtel - http://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Remove tempfile.mktemp()
Hi, Context: raise a warning or remove tempfile.mktemp() BPO: https://bugs.python.org/issue36309 Since 2.3, this function is deprecated in the documentation, just in the documentation. In the code, there is a commented RuntimeWarning. Commented by Guido in 2002, because the warning was too annoying (and I understand ;-)). So, in this BPO, we start to discuss about the future of this function and Serhiy proposed to discuss on the Python-dev mailing list. Question: Should we drop it or add a (Pending)DeprecationWarning? Suggestion and timeline: 3.8, we raise a PendingDeprecationWarning * update the code * update the documentation * update the tests (check a PendingDeprecationWarning if sys.version_info == 3.8) 3.9, we change PendingDeprecationWarning to DeprecationWarning (check DeprecationWarning if sys.version_info == 3.9) 3.9+, we drop tempfile.mktemp() What do you suggest? Have a nice day and thank you for your feedback. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?
and why not with a very long PendingDeprecationWarning? this warning could be used in this case. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove tempfile.mktemp()
totally agree with you but this function is deprecated (2002) since 2.3, with a simle comment about a security issue. 2.3 -> 2.7, 3.0 -> 3.7, 13 releases and 17 years. Maybe we could remove it with an official PendingDeprecationWarning. Le 19/03/19 à 14:39, Antoine Pitrou a écrit : > The fact that many projects, including well-maintained ones such Sphinx > or pip, use mktemp(), may be a hint that replacing it is not as easy as > the people writing the Python documentation seem to think. What's the relation with the people writing the Python documentation? The suggestion about the deprecation warning was proposed by Brett Cannon, and Serhiy has proposed to deprecate this function with some releases. The final release for 3.8 is scheduled for October 2019 (PendingDeprecationWarning). Maybe 3.9 will be released 18 months later (DeprecationWarning). and maybe 3.10 or 4.0 will be released 18 months after 3.9. so, from today to 3.9+ there are approximatively 43 months -> 3,5 years. I think it's enough in term of time for the big projects to improve their code. Stéphane ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] introduction of __attribute__(deprecated) ?
Hi,
I have created the issue https://bugs.python.org/issue36347 because I
wanted to add a missing macro for the PyMemberDef.flags attribute.
In the Modules/*.c files, we can find descriptions with
PyMemberDef where the access flag has the 0 value.
Example:
static PyMemberDef members[] = {
{"name", T_OBJECT, offsetof(MyObject, name), 0, NULL},
{NULL},
};
So, I didn't know the meaning of this magic number (0) and after a small
search in structmember.h, this is the default value for an "READWRITE"
attribute but there is no associated macro to this magic number.
solution: add the macro for the READWRITE mode.
so, my first PR has added the new macro READWRITE, like that
#define READWRITE 0
and improve the documentation in Doc/c-api/structures.rst.
but after a review [1], Serhiy proposed to rename it and the other ones
because it did not follow the convention for names in the C API.
Use a prefix for the public names, example Py_ or PY_.
I chose PY_ because PY_WRITE_RESTRICTED already existed.
the next steps were:
* add the new macros
* keep the backward-compatibility
* updated the documentation
I haved pushed the PR for another review
so, but I don't like this definition of READONLY because there is no way
to generate a warning at the compile time when we use the READONLY macro.
#define PY_READONLY 0
#define READONLYPY_READONLY
after that, I have closed my PR because I was not proud with my "solution".
Today, Ronald Oussoren [2] has proposed an other solution based on an
enum and a new __attribute__, aka deprecated.
I have checked with gcc and clang and this option is interesting because
we generate a warning when we try to compile a code if we use the
deprecated READONLY [3]
In the clang documantion, the __attribute__(deprecated) is defined in
GNU and C++11 standard, like __attribute__(unused).
In the gcc documentation, this attribute also exists
Because we already use __attribute__(unused) we could add
__attribute__(deprecated).
LC_ALL=C clang test.c -o test
test.c:14:13: warning: 'READONLY' is deprecated: use PY_READONLY
[-Wdeprecated-declarations]
int i = READONLY;
^
test.c:8:27: note: 'READONLY' has been explicitly marked deprecated here
READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
^
1 warning generated.
LC_ALL=C clang --version test.c -o test
clang version 7.0.1 (Fedora 7.0.1-6.fc29)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
### GCC
LC_ALL=C gcc --version test.c -o test
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
LC_ALL=C gcc test.c -o test
test.c: In function 'main':
test.c:14:5: warning: 'READONLY' is deprecated: use PY_READONLY
[-Wdeprecated-declarations]
int i = READONLY;
^~~
test.c:8:5: note: declared here
READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
^~~~
So my question is, can we use/add __attribute__(deprecated) in our
"development" kit?
[1] https://bugs.python.org/issue36347#msg338261
[2] https://bugs.python.org/issue36347#msg338731
[3] https://bugs.python.org/issue36347#msg338745
Thank you,
Stéphane
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] introduction of __attribute__(deprecated) ?
And use an enumeration for the constants.
For example:
#include
#include
enum {
PY_READWRITE = 0,
PY_READONLY = 1,
READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
READWRITE __attribute((deprecated("use PY_READWRITE"))) = PY_READWRITE,
};
Le 24/03/19 à 20:52, Stéphane Wirtel a écrit :
> Hi,
>
> I have created the issue https://bugs.python.org/issue36347 because I
> wanted to add a missing macro for the PyMemberDef.flags attribute.
>
> In the Modules/*.c files, we can find descriptions with
> PyMemberDef where the access flag has the 0 value.
>
> Example:
>
> static PyMemberDef members[] = {
> {"name", T_OBJECT, offsetof(MyObject, name), 0, NULL},
> {NULL},
> };
>
> So, I didn't know the meaning of this magic number (0) and after a small
> search in structmember.h, this is the default value for an "READWRITE"
> attribute but there is no associated macro to this magic number.
>
> solution: add the macro for the READWRITE mode.
>
> so, my first PR has added the new macro READWRITE, like that
>
> #define READWRITE 0
>
> and improve the documentation in Doc/c-api/structures.rst.
>
> but after a review [1], Serhiy proposed to rename it and the other ones
> because it did not follow the convention for names in the C API.
> Use a prefix for the public names, example Py_ or PY_.
>
> I chose PY_ because PY_WRITE_RESTRICTED already existed.
>
> the next steps were:
> * add the new macros
> * keep the backward-compatibility
> * updated the documentation
>
> I haved pushed the PR for another review
>
> so, but I don't like this definition of READONLY because there is no way
> to generate a warning at the compile time when we use the READONLY macro.
>
> #define PY_READONLY 0
> #define READONLY PY_READONLY
>
> after that, I have closed my PR because I was not proud with my "solution".
>
>
> Today, Ronald Oussoren [2] has proposed an other solution based on an
> enum and a new __attribute__, aka deprecated.
>
> I have checked with gcc and clang and this option is interesting because
> we generate a warning when we try to compile a code if we use the
> deprecated READONLY [3]
>
> In the clang documantion, the __attribute__(deprecated) is defined in
> GNU and C++11 standard, like __attribute__(unused).
>
> In the gcc documentation, this attribute also exists
>
> Because we already use __attribute__(unused) we could add
> __attribute__(deprecated).
>
>
> LC_ALL=C clang test.c -o test
> test.c:14:13: warning: 'READONLY' is deprecated: use PY_READONLY
> [-Wdeprecated-declarations]
> int i = READONLY;
> ^
> test.c:8:27: note: 'READONLY' has been explicitly marked deprecated here
> READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
> ^
> 1 warning generated.
>
> LC_ALL=C clang --version test.c -o test
> clang version 7.0.1 (Fedora 7.0.1-6.fc29)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
> ### GCC
> LC_ALL=C gcc --version test.c -o test
> gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> LC_ALL=C gcc test.c -o test
> test.c: In function 'main':
> test.c:14:5: warning: 'READONLY' is deprecated: use PY_READONLY
> [-Wdeprecated-declarations]
> int i = READONLY;
> ^~~
> test.c:8:5: note: declared here
> READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
> ^~~~
>
> So my question is, can we use/add __attribute__(deprecated) in our
> "development" kit?
>
> [1] https://bugs.python.org/issue36347#msg338261
> [2] https://bugs.python.org/issue36347#msg338731
> [3] https://bugs.python.org/issue36347#msg338745
>
> Thank you,
>
> Stéphane
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] introduction of __attribute__(deprecated) ?
Thanks Victor, I have updated my PR with the Py_DEPRECATED macro. Le 24/03/19 à 23:07, Victor Stinner a écrit : > Le dim. 24 mars 2019 à 20:56, Stéphane Wirtel a écrit : >> So my question is, can we use/add __attribute__(deprecated) in our >> "development" kit? > > There is already Py_DEPRECATED(VERSION_UNUSED) macro which uses > __attribute__((__deprecated__)) on GCC >= 3.1. > > You can find the doc of a few macros in > https://docs.python.org/dev/c-api/intro.html#useful-macros but this > macro isn't documented there. > > pyport.h and pymacro.h contain most of the "macros". > > Victor > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 3.8.0a3 is now available for testing
Łukasz, I have proposed a PR for the update of this docker image: quay.io/python-devs/ci-image I have also updated the versions to 3.4.10, 3.5.7, 3.7.3 and of course to Python 3.8.0a3. By the way, this image will contain the last versions of Python 3.x https://gitlab.com/python-devs/ci-images/merge_requests/9 Bonne journée, Stéphane Le 26/03/19 à 10:11, Łukasz Langa a écrit : > It's time for the third alpha of Python 3.8.0. Go get it here: > https://www.python.org/downloads/release/python-380a3/ > > Python 3.8.0a3 is the third of four planned alpha releases of Python 3.8, > the next feature release of Python. During the alpha phase, Python 3.8 > remains under heavy development: additional features will be added > and existing features may be modified or deleted. Please keep in mind > that this is a preview release and its use is not recommended for > production environments. The last alpha release, 3.8.0a4, is planned > for 2019-04-29. > > I am happy to say that this time all buildbots were properly green. Thank you > to everybody who worked on that. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bpo-36558: Change time.mktime() return type from float to int?
I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well. In C, the signature of mktime is time_t mktime(struct tm *time); from Wikipedia, the Unix time_t data type, on many platforms, is a signed integer, tradionally (32bits). In the newer operating systems, time_t has been widened to 64 bits. -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Requesting PR review on locale module
Hi Cedric, It’s my fault, I am going to check your PR for this week. I am really sorry because I am busy with the preparation of my black belt in Karate and I have a training every day. Have a nice day, Stéphane > Le 17 nov. 2019 à 14:06, Tal Einat a écrit : > > > Hi Cédric, > > Thanks for writing and sorry that you've experienced such a delay. Such > occurrences are unfortunately rather common right now, though we're working > on improving the situation. > > Stéphane Wirtel self-assigned that PR to himself a couple of months ago, but > indeed hasn't followed it up after his requested changes were apparently > addressed, despite a couple of "pings". > > The experts index[1] lists Marc-Andre Lemburg as the expert for the locale > module, so perhaps he'd be interested in taking a look. > > I've CC-ed both Stéphane and Marc-Andre. > > [1] https://devguide.python.org/experts/ > >> On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev >> wrote: >> Hi, >> >> Few months ago, I submitted a PR [1] for the bpo [2] about locale.format >> casting Decimal into float. Has someone some times to finish the review? >> This change is blocking a bugfix on Tryton [3]. >> >> >> [1] https://github.com/python/cpython/pull/15275 >> [2] https://bugs.python.org/issue34311 >> [3] https://bugs.tryton.org/issue8574 >> >> >> Thanks, >> -- >> Cédric Krier - B2CK SPRL >> Email/Jabber: cedric.kr...@b2ck.com >> Tel: +32 472 54 46 59 >> Website: http://www.b2ck.com/ >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ >> Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P7DMG56Q7CAJZ2WDD7IL2F3N4MI5WTEB/ Code of Conduct: http://python.org/psf/codeofconduct/
