Re: [Python-Dev] (no subject)
I split off a separate thread on python-ideas [1] specific to the idea of
introducing + and += operators on a dict.
[1] https://mail.python.org/pipermail/python-ideas/2015-February/031748.html
~ Ian Lee
On Tue, Feb 10, 2015 at 10:35 PM, John Wong gokoproj...@gmail.com wrote:
On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee ianlee1...@gmail.com wrote:
+1 for adding + or | operator for merging dicts. To me this operation:
{'x': 1, 'y': 2} + {'z': 3}
{'x': 1, 'y': 2, 'z': 3}
Is very clear. The only potentially non obvious case I can see then is
when there are duplicate keys, in which case the syntax could just be
defined that last setter wins, e.g.:
{'x': 1, 'y': 2} + {'x': 3}
{'x': 3, 'y': 2}
Which is analogous to the example:
new_dict = dict1.copy()
new_dict.update(dict2)
Well looking at just list
a + b yields new list
a += b yields modified a
then there is also .extend in list. etc.
so do we want to follow list's footstep? I like + because + is more
natural to read. Maybe this needs to be a separate thread. I am actually
amazed to remember dict + dict is not possible... there must be a reason
(performance??) for this...
___
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] (no subject)
John Wong wrote: I am actually amazed to remember dict + dict is not possible... there must be a reason (performance??) for this... I think it's mainly because there is no obviously correct answer to the question of what to do about duplicate keys. -- Greg ___ 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] (no subject)
On 02/10/2015 10:33 AM, Paul Moore wrote:
On 10 February 2015 at 00:29, Neil Girdhar mistersh...@gmail.com wrote:
function(**kw_arguments, **more_arguments)
If the key key1 is in both dictionaries, more_arguments wins, right?
There was some debate and it was decided that duplicate keyword arguments
would remain an error (for now at least). If you want to merge the
dictionaries with overriding, then you can still do:
function(**{**kw_arguments, **more_arguments})
because **-unpacking in dicts overrides as you guessed.
Eww. Seriously, function(**{**kw_arguments, **more_arguments}) feels
more like a Perl executable line noise construct than anything I'd
ever want to see in Python. And taking something that doesn't work and
saying you can make it work by wrapping **{...} round it just seems
wrong.
I don't think people would want to write the above.
I like the sequence and dict flattening part of the PEP, mostly because it
is consistent and should be easy to understand, but the comprehension syntax
enhancements seem to be bad for readability and comprehending what the code
does.
The call syntax part is a mixed bag: on the one hand it is nice to be
consistent with the extended possibilities in literals (flattening),
but on the other hand there would be small but annoying inconsistencies
anyways (e.g. the duplicate kwarg case above).
Georg
___
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] Problem running ./python -m test -v test_whatever
You might want to try asking on python-l...@python.org to get a wider audience as you might find a fellow AIX user there who can help you out. On Wed Feb 11 2015 at 12:29:56 AM Dwight dcrs6...@aceweb.com wrote: Hi, I am primarily a user; but since I can not get a newer version of firefox for my system I have begun the very long process of trying to build a newer version of firefox for my system. I am using an IBM pSeries system running AIX 7.1. I am using gcc and IBM ld. All the modules I have built are being installed in a directory called /opt/alinux. A lot of linux routines are stored in a directory called /opt/freeware and of course IBM has some version of their own which are installed in /usr... Currently there is only one thing installed in /usr/local and that is clamscan. I have built and installed the tcl.8.6.3, tkl.8.6.3 and python 2.7.9 into /opt/aluinux. I am now trying to build and install python 3.4.2. So far I have found a way to compile python successfully. There are only three features missing (_sqlite3, ossaudiodev and spwd). The configure command I ran was: ./configure --prefix=/opt/alinux --exec-prefix=/opt/alinux --enable-shared --with-system-ffi --enable-ipv6 \ --with-tcltk-includes='-I/opt/alinux/include' --with-tcltk-libs='-L/opt/alinux/lib' | tee MYconfig.log After running gmake test I found: Ran 509 tests in 47.407s FAILED (errors=2, skipped=8) Ran 49 tests in 0.065s FAILED (failures=2, skipped=1) Ran 34 tests in 0.320s FAILED (errors=2, skipped=6) Ran 80 tests in 1.040s FAILED (errors=2, skipped=20) Ran 10 tests in 0.366s FAILED (failures=1, skipped=2) Ran 506 tests in 28.860s FAILED (failures=6, errors=5, skipped=83) Ran 97 tests in 21.921s FAILED (failures=9, skipped=3) I then tried to run ./python -m test -v test_whatever and got the following error: $ pwd /home/surfer/DownLoadLFNs/HTML/NEWS/BuildFirefox/Python-3.4.2 $ ls -la lib* -rw-r--r--1 surfer Internet 19562608 Feb 10 20:02 libpython3.4m.a -rwxr-xr-x1 surfer Internet 13331408 Feb 10 20:02 libpython3.4m.so $ ./python -m test -v test_ssl exec(): 0509-036 Cannot load program ./python because of the following errors: 0509-150 Dependent module libpython3.4m.so could not be loaded. 0509-022 Cannot load module libpython3.4m.so. 0509-026 System error: A file or directory in the path name does not exist. I would really appreciate some help in determining what I am doing wrong. As I said in the beginning I am primarily a user and not a developer. I can solve some fairly simple problems; but that about it. I am guessing that there is some kind of linking problem; but I do not know how to solve this problem. I tried this: $ LDFLAGS=-L/home/surfer/DownLoadLFNs/HTML/NEWS/BuildFirefox/Python-3.4.2 $ export LDFLAGS and got the same results. ___ 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/ brett%40python.org ___ 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] (no subject)
On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee ianlee1...@gmail.com wrote:
+1 for adding + or | operator for merging dicts. To me this operation:
{'x': 1, 'y': 2} + {'z': 3}
{'x': 1, 'y': 2, 'z': 3}
Is very clear. The only potentially non obvious case I can see then is
when there are duplicate keys, in which case the syntax could just be
defined that last setter wins, e.g.:
{'x': 1, 'y': 2} + {'x': 3}
{'x': 3, 'y': 2}
Which is analogous to the example:
new_dict = dict1.copy()
new_dict.update(dict2)
Well looking at just list
a + b yields new list
a += b yields modified a
then there is also .extend in list. etc.
so do we want to follow list's footstep? I like + because + is more natural
to read. Maybe this needs to be a separate thread. I am actually amazed to
remember dict + dict is not possible... there must be a reason
(performance??) for this...
___
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] (no subject)
Georg Brandl wrote:
The call syntax part is a mixed bag: on the one hand it is nice to be
consistent with the extended possibilities in literals (flattening),
but on the other hand there would be small but annoying inconsistencies
anyways (e.g. the duplicate kwarg case above).
That inconsistency already exists -- duplicate keys are
allowed in dict literals but not calls:
{'a':1, 'a':2}
{'a': 2}
--
Greg
___
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] (no subject)
On Wed, 11 Feb 2015 18:45:40 +1300 Greg Ewing greg.ew...@canterbury.ac.nz wrote: Antoine Pitrou wrote: bytearray(ba) + bbc bytearray(b'abc') ba + bytearray(bbc) b'abc' It's quite convenient. It's a bit disconcerting that the left operand wins, rather than one of them being designated as the wider type, as occurs with many other operations on mixed types, e.g. int + float. There is no wider type here. This behaviour is perfectly logical. In any case, these seem to be special-case combinations. No: babc + array.array(b, bdef) b'abcdef' bytearray(babc) + array.array(b, bdef) bytearray(b'abcdef') Regards Antoine. ___ 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
