[Python-Dev] Behaviour change of object().format()
Hi,
In 3.3 I could do the following
>>> "{x:s}".format(**{'x': [1, 2, 3]})
'[1, 2, 3]'
But in 3.4
>>> "{x:s}".format(**{'x': [1, 2, 3]})
Traceback (most recent call last):
File "", line 1, in
TypeError: non-empty format string passed to object.__format__
Is this intentional?
regards,
James Swift
___
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
[Python-Dev] Behaviour change of object().format() in 3.4
Hi,
In 3.3 I could do the following
>>> "{x:s}".format(**{'x': [1, 2, 3]})
'[1, 2, 3]'
But in 3.4
>>> "{x:s}".format(**{'x': [1, 2, 3]})
Traceback (most recent call last):
File "", line 1, in
TypeError: non-empty format string passed to object.__format__
Is this intentional?
regards,
James Swift
___
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] Behaviour change of object().format() in 3.4
On Tue, 06 May 2014 16:45:52 +0200, James Swift wrote:
> Hi,
>
> In 3.3 I could do the following
>
> >>> "{x:s}".format(**{'x': [1, 2, 3]})
> '[1, 2, 3]'
>
> But in 3.4
>
> >>> "{x:s}".format(**{'x': [1, 2, 3]})
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: non-empty format string passed to object.__format__
>
>
> Is this intentional?
Yes. There was a deprecation warning for this in 3.3, and it
is now an error in 3.4.
For more information, see http://bugs.python.org/issue7994.
--David
___
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] Behaviour change of object().format()
On 05/06/2014 10:33 AM, James Swift wrote:
> Hi,
>
> In 3.3 I could do the following
>
"{x:s}".format(**{'x': [1, 2, 3]})
> '[1, 2, 3]'
>
> But in 3.4
>
"{x:s}".format(**{'x': [1, 2, 3]})
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: non-empty format string passed to object.__format__
>
>
> Is this intentional?
Yes. See http://bugs.python.org/issue7994 for the rationale.
You can use:
>>> "{x!s:15s}".format(**{'x': [1, 2, 3]})
'[1, 2, 3] '
That is, convert it first to a string (with !s) then use whatever string
formatting specifier you want (here, '15s'). This should work under all
3.x versions (I think, haven't checked).
BTW, for this specific case, you might want to use format_map:
>>> "{x!s:15s}".format_map({'x': [1, 2, 3]})
'[1, 2, 3] '
Eric.
___
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] Existence of pythonNN.zip in sys.path
On 5/5/2014 5:32 PM, Anthony Tuininga wrote: Hi, I am the author of cx_Freeze which creates "frozen" executables from Python scripts. To this point I have been using frozen modules (compiled C) but this has the side effect of bundling parts of Python with a cx_Freeze release -- and this has bitten me on a number of occasions when newer versions of Python use slightly incompatible modules. :-) By scanning the code I discovered that Python automatically searches on startup /lib/pythonNN.zip where NN is replaced by the major and minor version that is being executed. Using this would allow me to ensure that bootstrap modules are not bundled with cx_Freeze but acquired from the distribution that is actually using it -- thereby eliminating the hassle noted above. I have tested this approach and found it works flawlessly. There is, however, no documentation that I can find for the contents of sys.path -- the documentation simply says that it is an installation default and doesn't specify what that default is. So my question is: can I safely make use of this "feature"? It has remained in place since at least Python 2.6 but I don't want to assume anything. Please advise! Thanks. I would say yes. AFAIK /lib has always by used for the stdlib on Windows and /lib/pythonxy on *nix. Both are mentioned in the 4th paragraph of the site module doc. We do not lightly change directory structure. PEP 273 then says "The zip archive must be treated exactly as a subdirectory tree,". I take this to mean that lib/pythonxy.zip should work the same as lib/pythonxy/ does. You can depend on the feature working as long as it works. Your bigger worry is accidental regression. I suggest testing release candidates (there is one for 3.4.1 now, I believe) and also an early alpha and beta for new release. The candidate may have a zip patch affecting central directory reading. If not, there is an issue on the tracker. You could monitor patches by filtering the new-issue announcements for 'zip'. -- Terry Jan Reedy ___ 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] Python under the sea and in space
On 5/4/2014 11:02 PM, Jessica McKellar wrote: Hi folks, I'm trying to determine the greatest depth (in the ocean or underground) and highest altitude at which Python code has been executed. Please note that I'm interested in where the code was executed, and not, say, where data that Python analyzed was acquired. I know for example that NASA has analyzed plenty of data from space in Python, but the analysis was done in labs here on Earth. :) Do you have some good candidates? Please let me know! I suggest posting this on python-list; its readers seem to work with a wide range of applications. -- Terry Jan Reedy ___ 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
[Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]
Just a warning, in case any of the new packaging team forgot to contact http://cve.mitre.org/ . Stefan Krah ___ 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] pip: cdecimal an externally hosted file and may be unreliable [sic]
Hi, I don't understand your email. Can you please elaborate? Victor 2014-05-06 23:35 GMT+02:00 Stefan Krah : > Just a warning, in case any of the new packaging team forgot to contact > http://cve.mitre.org/ . > > > Stefan Krah > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ 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
