Re: [Python-Dev] (no subject)
On Wed, 11 Feb 2015 18:45:40 +1300
Greg Ewing wrote:
> Antoine Pitrou wrote:
> bytearray(b"a") + b"bc"
> >
> > bytearray(b'abc')
> >
> b"a" + bytearray(b"bc")
> >
> > 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:
>>> b"abc" + array.array("b", b"def")
b'abcdef'
>>> bytearray(b"abc") + array.array("b", b"def")
bytearray(b'abcdef')
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
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 [email protected] 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 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > ___ Python-Dev mailing list [email protected] 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 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
[email protected]
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)
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 wrote:
>
>
> On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee 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
[email protected]
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 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
[email protected]
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 [email protected] 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
