Re: Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
On 2017-05-28, Bill Deegan wrote: > As a follow up to a discussion on IRC #python channel today. > > Assuming the same order of insertions of the same items to a dictionary > would the iteration of a dictionary be the same (not as the order of > insertion, just from run to run) for Python 2.7 up to python 3.3? And again > at Python 3.6? > (Also for py 3.3 through 3.5.x if PYTHONHASHSEED=0) > > With python 3.6 having the added benefit of guaranteeing insertion order is > maintained? I think Steve missed the point of what you were asking, as well as being wrong about dict order in 3.6. Here's the official line on that: The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon (this may change in the future, but it is desired to have this new dict implementation in the language for a few releases before changing the language spec to mandate order-preserving semantics for all current and future Python implementations ( https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compactdict ) If you're asking "given a fixed Python version, and where appropriate PYTHONHASHSEED=0, will dictionaries created the same way always iterate in the same order" then that seems pretty much true by definition (how could it not be true?), as well as being an explicit guarantee in Python 3.3-3.5. ( https://docs.python.org/3.3/using/cmdline.html#envvar-PYTHONHASHSEED ) -- https://mail.python.org/mailman/listinfo/python-list
Re: Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
On Sun, 28 May 2017 11:12 pm, Jon Ribbens wrote: > On 2017-05-28, Bill Deegan wrote: >> As a follow up to a discussion on IRC #python channel today. >> >> Assuming the same order of insertions of the same items to a dictionary >> would the iteration of a dictionary be the same (not as the order of >> insertion, just from run to run) for Python 2.7 up to python 3.3? And again >> at Python 3.6? >> (Also for py 3.3 through 3.5.x if PYTHONHASHSEED=0) >> >> With python 3.6 having the added benefit of guaranteeing insertion order is >> maintained? > > I think Steve missed the point of what you were asking, as well as > being wrong about dict order in 3.6. Here's the official line on that: Thanks for quoting the official line, because it agrees with what I said: dict order in 3.6 is considered an implementation detail, not a language guarantee, and shouldn't be relied on (except for function **kwargs). What exactly did you think I got wrong? - that **kwargs preserve order? - that Python 3.6 does NOT guarantee that other dicts preserve order? - that Python may make that promise in the future? Everything I said is supported by the very document you quoted. > The order-preserving aspect of this new implementation is considered > an implementation detail and should not be relied upon (this may > change in the future, but it is desired to have this new dict > implementation in the language for a few releases before changing the > language spec to mandate order-preserving semantics for all current > and future Python implementations > > ( https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compactdict ) > > If you're asking "given a fixed Python version, and where appropriate > PYTHONHASHSEED=0, will dictionaries created the same way always > iterate in the same order" Why on earth would you assume a fixed Python version when the OP *explicitly* asks about Python 2.7 through 3.3? That's two major versions, four minor versions (excluding 3.0, which nobody should use), and who knows how many bug fix versions. Since the iteration order is explicitly subject to change, then it is possible for any release (major, minor or bug fix) to change the iteration order. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
On 2017-05-28, Steve D'Aprano wrote: > What exactly did you think I got wrong? 3.6 does preserve the dict order. It isn't a guarantee so may change in future versions, but it is what 3.6 actually does. >> If you're asking "given a fixed Python version, and where appropriate >> PYTHONHASHSEED=0, will dictionaries created the same way always >> iterate in the same order" > > Why on earth would you assume a fixed Python version when the OP *explicitly* > asks about Python 2.7 through 3.3? That's two major versions, four minor > versions (excluding 3.0, which nobody should use), and who knows how many bug > fix versions. Since the iteration order is explicitly subject to change, then > it is possible for any release (major, minor or bug fix) to change the > iteration order. Not when you run the same program repeatedly under the same version. Sure, it might be different if you run it under a different version, but it's entirely possible for that not to be the guarantee the OP is looking for. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
On May 28, 2017 8:23 AM, "Jon Ribbens" wrote: > On 2017-05-28, Steve D'Aprano wrote: >> What exactly did you think I got wrong? > > 3.6 does preserve the dict order. It isn't a guarantee so may change > in future versions, but it is what 3.6 actually does. No, it's what CPython 3.6 actually does. There is no guarantee that Jython 3.6 or PyPy 3.6 will do the same, so it's inaccurate to talk about this as the generalized behavior of "3.6". There is not even any guarantee that this won't change in CPython 3.6.2 (though it seems unlikely). -- https://mail.python.org/mailman/listinfo/python-list
Re: Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
On Mon, 29 May 2017 12:15 am, Jon Ribbens wrote: > On 2017-05-28, Steve D'Aprano wrote: >> What exactly did you think I got wrong? > > 3.6 does preserve the dict order. It isn't a guarantee so may change > in future versions, but it is what 3.6 actually does. Did I say it didn't? I said you can't rely on it, because it might change. The OP stated: "... python 3.6 having the added benefit of guaranteeing insertion order is maintained?" and I said: "No -- there is no such guarantee for 3.6. The only language promise is that **kwargs keyword arguments will keep insertion order. That's all. The Python language still reserves the right to re-order dicts at any time" both of which is true. The *plan* is to change this for a stronger promise, but that depends on other implementations (PyPy, Jython and IronPython especially) agreeing that they can offer the same promise without performance penalty. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
نتيجة الشهادة الابتدائية الترم الثاني 2017 جميع المحافظات - نتيجة الصف السادس الإبتدائي آخر العام
‘انا عاوز اعرف نتيجتي انا واخويه رفم جلوسي ورقم جلوس اخويه 41779.41752 -- https://mail.python.org/mailman/listinfo/python-list
Re: pip list --outdated gives all packages
On May 27, 2017, at 11:10 AM, Cecil Westerhof wrote:
> On Saturday 27 May 2017 16:34 CEST, Cem Karan wrote:
>
>>
>> On May 27, 2017, at 7:15 AM, Cecil Westerhof wrote:
>>
>>> On Saturday 27 May 2017 12:33 CEST, Cecil Westerhof wrote:
>>>
I wrote a script to run as a cron job to check if I need to update
my Python installations. I migrated from openSUSE to Debian and
that does not work anymore (pip2 and pip3): it displays the same
with and without --outdated. Anyone knows what the problem could
be?
>>>
>>> It does not exactly displays the same, but it displays all
>>> packages, while in the old version it only displayed the outdated
>>> versions. I already made a change with awk, but I would prefer the
>>> old functionality.
>>>
>>> By the way, the patch is:
>>> pip2 list --outdated --format=legacy | awk '
>>> {
>>> if (substr($2, 2, length($2) - 2) != $5) {
>>> print $0
>>> }
>>> }'
>>
>> Could you check the output of 'pip3 --version'? When I tested pip3
>> on my machine, 'pip3 list --outdated' only yielded the outdated
>> packages, not a list of everything out there.
>
> Both as normal user and root I get:
>pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.5)
I'm completely flummoxed then; on my machines I get the 'old' behavior. Can
you try a completely clean Debian install somewhere (maybe on a virtual box)
and see what happens? I'm wondering if there is something going on with your
migration.
Thanks,
Cem Karan
--
https://mail.python.org/mailman/listinfo/python-list
How to `eval` code with `def`?
Hi, I got the following error when I try to eval the following code with def. Does anybody know what is the correct way to evaluation python code that contains `def`? Thanks. $ cat ./main.py #!/usr/bin/env python # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 fileencoding=utf-8: import dis s = """ def f(x): return x is not None """ print(s) eval(s) $ ./main.py def f(x): return x is not None Traceback (most recent call last): File "./main.py", line 10, in eval(s) File "", line 2 def f(x): ^ SyntaxError: invalid syntax -- Regards, Peng -- https://mail.python.org/mailman/listinfo/python-list
Re: How to `eval` code with `def`?
On 2017-05-29, Peng Yu wrote: > I got the following error when I try to eval the following code with > def. Does anybody know what is the correct way to evaluation python > code that contains `def`? Thanks. exec -- https://mail.python.org/mailman/listinfo/python-list
Re: How to `eval` code with `def`?
On 2017-05-29 02:03, Peng Yu wrote: Hi, I got the following error when I try to eval the following code with def. Does anybody know what is the correct way to evaluation python code that contains `def`? Thanks. $ cat ./main.py #!/usr/bin/env python # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 fileencoding=utf-8: import dis s = """ def f(x): return x is not None """ print(s) eval(s) $ ./main.py def f(x): return x is not None Traceback (most recent call last): File "./main.py", line 10, in eval(s) File "", line 2 def f(x): ^ SyntaxError: invalid syntax 'eval' expects an expression, e.g. "1 + 2", not statements. What you should be using instead is 'exec'. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to `eval` code with `def`?
On Mon, 29 May 2017 11:03 am, Peng Yu wrote: > Hi, > > I got the following error when I try to eval the following code with > def. Does anybody know what is the correct way to evaluation python > code that contains `def`? Thanks. > > $ cat ./main.py > #!/usr/bin/env python > # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 > # fileencoding=utf-8: The file encoding cookie must be in the first or second line for Python to recognise it. Try swapping the encoding cookie and the vim line: #!/usr/bin/env python # fileencoding=utf-8: # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 should work, although I prefer: # -*- coding: utf-8 -*- > import dis > s = """ > def f(x): > return x is not None > """ > print(s) > eval(s) If your intention is to call dis on the function, you don't need eval or exec. Try this instead: import dis def f(x): return x is not None dis.dis(f) If you want the source code too, you can try this: import inspect import dis def f(x): return x is not None dis.dis(f) print inspect.getsource(f) but getsource() only works when the function is defined in a .py file, it doesn't work in the interactive interpreter. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to `eval` code with `def`?
Steve D'Aprano writes: > #!/usr/bin/env python > # fileencoding=utf-8: > # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 Even better, the source code encoding declaration for Python is compatible with a Vim text encoding declaration. So you can just do one: = #! /usr/bin/env python # vim: set fileencoding=utf-8 noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 : = See https://www.python.org/dev/peps/pep-0263/#defining-the-encoding> for a discussion of how Python expects to find the source code encoding declaration. > although I prefer: > > # -*- coding: utf-8 -*- Yes. Jamming all the editor hints at the top of the file is IMO needlessly distracting; both Vim and Emacs will look for them at the end of the file, where they're less intrusive. I prefer to have Python's source code encoding delcaration at the top of the file, and have a block of editor hints at the end of the file. -- \ “I know you believe you understood what you think I said, but I | `\ am not sure you realize that what you heard is not what I | _o__) meant.” —Robert J. McCloskey | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: pip list --outdated gives all packages
On Monday 29 May 2017 02:45 CEST, Cem Karan wrote:
>
> On May 27, 2017, at 11:10 AM, Cecil Westerhof wrote:
>
>> On Saturday 27 May 2017 16:34 CEST, Cem Karan wrote:
>>
>>>
>>> On May 27, 2017, at 7:15 AM, Cecil Westerhof wrote:
>>>
On Saturday 27 May 2017 12:33 CEST, Cecil Westerhof wrote:
> I wrote a script to run as a cron job to check if I need to
> update my Python installations. I migrated from openSUSE to
> Debian and that does not work anymore (pip2 and pip3): it
> displays the same with and without --outdated. Anyone knows what
> the problem could be?
It does not exactly displays the same, but it displays all
packages, while in the old version it only displayed the outdated
versions. I already made a change with awk, but I would prefer
the old functionality.
By the way, the patch is:
pip2 list --outdated --format=legacy | awk '
{
if (substr($2, 2, length($2) - 2) != $5) {
print $0
}
}'
>>>
>>> Could you check the output of 'pip3 --version'? When I tested pip3
>>> on my machine, 'pip3 list --outdated' only yielded the outdated
>>> packages, not a list of everything out there.
>>
>> Both as normal user and root I get:
>> pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.5)
>
> I'm completely flummoxed then; on my machines I get the 'old'
> behavior. Can you try a completely clean Debian install somewhere
> (maybe on a virtual box) and see what happens? I'm wondering if
> there is something going on with your migration.
I will do that. By the way, because of hardware I installed Stretch
which at the moment is still in testing.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: pip list --outdated gives all packages
On Monday 29 May 2017 06:16 CEST, Cecil Westerhof wrote: >> I'm completely flummoxed then; on my machines I get the 'old' >> behavior. Can you try a completely clean Debian install somewhere >> (maybe on a virtual box) and see what happens? I'm wondering if >> there is something going on with your migration. > > I will do that. By the way, because of hardware I installed Stretch > which at the moment is still in testing. I tried it. (Where some problems. Looks like you can not do certain things in VirtualBox. But that is for another time.) Get the same result. So maybe I should put it on the Debian list. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: How to `eval` code with `def`?
Peng Yu wrote:
Does anybody know what is the correct way to evaluation python
code that contains `def`? Thanks.
Here's one way to do it:
env = {}
exec(s, env, env)
Now env['f'] contains the defined function, which you can then
call, disassemble or whatever you want.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
