[Python-Dev] Backslash at end of raw string
Python (e.g. 2.5) does not accept a backslash as the LAST character of a raw string: >>> r"\" File "", line 1 r"\" ^ Syntax Error: EOL while scanning single-quoted string. path = r'\MyDir\MySubDir\' # raises same error path = r'\MyDir\MySubDir' # no error Isn't this a bug? Rob Cliffe___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backslash at end of raw string
"Rob Cliffe" writes: > Syntax Error: EOL while scanning single-quoted string. […] > Isn't this a bug? It has a report http://bugs.python.org/issue1271> but is not a bug http://www.python.org/doc/faq/general/#why-can-t-raw-strings-r-strings-end-with-a-backslash>. -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney
[..]
>
> Yes, I'm referring to the discussion that were had over “why do we want
> special keywords that mess with the default alphanumerical ordering of
> version string components?” discussion.
>
> That needs to be addressed in the PEP, since it's germane to the
> explanation for the PEP's existence.
I've started to add another section in the PEP to summarize this
discussion but then I realized that we are already giving the answer
in the PEP in the "Requisites and current status"
I made it clearer though, by adding an extra sentence with an example.
Requesite #2 :
"""
2. most projects need special meaning versions for "pre-releases" (such as
"alpha", "beta", "rc"), and these have widely used aliases ("a" stands
for "alpha", "b" for "beta" and "c" for "rc"). And these pre-release
versions makes it impossible to use a simple alphanumerical ordering
of the version string components. (Example: 3.1a1 < 3.1)
"""
Let me know if you think this is enough and addresses your concern,
Regards
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] First draft of "sysconfig"
Hello,
A while ago I've proposed to refactor the APIs that provides access to
the installation paths and configuration variables at runtime into a
single module called "sysconfig", and make it easier for all
implementations to work with them.
I've started a branch and worked on it, and I'd like to ask here for
some feedback. And in particular from Jython and IronPython people
because they would probably need to work in that file for their
implementation and/or propose things to add. My understanding is that
we have people like Phillip (Jenvey), Michael F., Frank W. in this
list so they can comment directly and I don't need to cross-post this
mail elsewhere.
== Installation schemes ==
First, the module contains the installation schemes for each platform
CPython uses.
An install scheme is a mapping where the key is the "code" name for a
directory, and
the value the path of that directory, with some $variable that can be expanded.
Install schemes are stored in a private mapping, where the keys are
usually the value of os.name,
and the value, the mapping I've mentionned earlier.
So, for example, the paths for win32 are:
_INSTALL_SCHEMES = {
...
'nt': {
'stdlib': '$base/Lib',
'platstdlib': '$base/Lib',
'purelib': '$base/Lib/site-packages',
'platlib': '$base/Lib/site-packages',
'include': '$base/include',
'platinclude': '$base/include',
'scripts': '$base/Scripts',
'data' : '$base',
},
...
}
where each key corresponds to a directory that contains some Python files:
- stdlib : root of the standard library
- platstdlib: root of platform-specific elements of the standard library
- purelib: the site-packages directory for pure python modules
- platlib: the site-packages directory for platform-specific modules
- include: the include dir
- platinclude: the include dir for platform-specific files
- scripts: the directory where scripts are added
- data: the directory where data file are added
All these directory are read and used by:
- distutils when a package is installed, so the install command can
dispatch files in the right place
- site.py, when Python is initialized
IOW, any part of the stdlib can use these paths to locate and work
with Python files.
The public APIs are:
* get_path_names() : returns a list of the path names ("stdlib",
"platstdlib", etc.)
* get_paths(scheme, vars) : Returns a mapping containing an install scheme.
- "scheme" is the name of the scheme, if not provided will get the
default scheme of the current platform
- vars is an optonal mapping that can provide values for the
various $variables. Notice that they all have
default values, for example $base == sys.prefix.
for example: get_paths('nt')
* get_path(name, scheme, vars): Returns one path corresponding to the scheme.
for example : get_paths('stdlib', 'nt')
Those API are generic, but maybe we could add specific APIs like:
* get_stdlib_path('nt')
These API are basically a refactoring of what already exist in
distutils/command/install.py
== Configuration variables ==
distutils.sysconfig currently provides some APIs to read values from
files like Makefile and pyconfig.h.
These API have been placed in the global sysconfig module:
* get_config_vars(): return a dictionary of all configuration
variables relevant for the current platform.
* get_config_var(name): Return the value of a single variable
* get_platform(): Return a string that identifies the current
platform. (this one is used by site.py for example)
* get_python_version() : return the short python version
(sys.version[:3]) -- this one could probably go away but is useful
because that's the marker used by Python in some paths.
== code, status, next steps ==
The code of the module can be viewed here, it's a revamp of distutils.sysconfig:
http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
I've refactored distutils/ and site.py so they work with this new
module, and added deprecation warnings in distutils.sysconfig.
All tests pass in the branch, but note that the code is still using
the .h and Makefile files. This will probably be removed later in
favor of a static _sysconfig.py file generated when Python is built,
containing the variables sysconfig reads. I'll do this second step
after I get some feedback on the proposal.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First draft of "sysconfig"
On Sat, Dec 12, 2009 at 12:02, Tarek Ziadé wrote:
> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work with them.
>
> I've started a branch and worked on it, and I'd like to ask here for
> some feedback. And in particular from Jython and IronPython people
> because they would probably need to work in that file for their
> implementation and/or propose things to add. My understanding is that
> we have people like Phillip (Jenvey), Michael F., Frank W. in this
> list so they can comment directly and I don't need to cross-post this
> mail elsewhere.
>
> == Installation schemes ==
>
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
>
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
>
> So, for example, the paths for win32 are:
>
> _INSTALL_SCHEMES = {
> ...
> 'nt': {
>'stdlib': '$base/Lib',
>'platstdlib': '$base/Lib',
>'purelib': '$base/Lib/site-packages',
>'platlib': '$base/Lib/site-packages',
>'include': '$base/include',
>'platinclude': '$base/include',
>'scripts': '$base/Scripts',
>'data' : '$base',
>},
> ...
> }
>
>
Are you using string.Template because this code needs to run on installs
older than 2.6?
-Brett
> where each key corresponds to a directory that contains some Python files:
>
> - stdlib : root of the standard library
> - platstdlib: root of platform-specific elements of the standard library
> - purelib: the site-packages directory for pure python modules
> - platlib: the site-packages directory for platform-specific modules
> - include: the include dir
> - platinclude: the include dir for platform-specific files
> - scripts: the directory where scripts are added
> - data: the directory where data file are added
>
> All these directory are read and used by:
> - distutils when a package is installed, so the install command can
> dispatch files in the right place
> - site.py, when Python is initialized
>
> IOW, any part of the stdlib can use these paths to locate and work
> with Python files.
>
> The public APIs are:
>
> * get_path_names() : returns a list of the path names ("stdlib",
> "platstdlib", etc.)
>
> * get_paths(scheme, vars) : Returns a mapping containing an install
> scheme.
> - "scheme" is the name of the scheme, if not provided will get the
> default scheme of the current platform
> - vars is an optonal mapping that can provide values for the
> various $variables. Notice that they all have
> default values, for example $base == sys.prefix.
>
>for example: get_paths('nt')
>
> * get_path(name, scheme, vars): Returns one path corresponding to the
> scheme.
>
> for example : get_paths('stdlib', 'nt')
>
> Those API are generic, but maybe we could add specific APIs like:
>
> * get_stdlib_path('nt')
>
> These API are basically a refactoring of what already exist in
> distutils/command/install.py
>
> == Configuration variables ==
>
> distutils.sysconfig currently provides some APIs to read values from
> files like Makefile and pyconfig.h.
>
> These API have been placed in the global sysconfig module:
>
> * get_config_vars(): return a dictionary of all configuration
> variables relevant for the current platform.
>
> * get_config_var(name): Return the value of a single variable
>
> * get_platform(): Return a string that identifies the current
> platform. (this one is used by site.py for example)
>
> * get_python_version() : return the short python version
> (sys.version[:3]) -- this one could probably go away but is useful
> because that's the marker used by Python in some paths.
>
> == code, status, next steps ==
>
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
>
>
> http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
>
> I've refactored distutils/ and site.py so they work with this new
> module, and added deprecation warnings in distutils.sysconfig.
>
> All tests pass in the branch, but note that the code is still using
> the .h and Makefile files. This will probably be removed later in
> favor of a static _sysconfig.py file generated when Python is built,
> containing the variables sysconfig reads. I'll do this second step
> after I get some feedback on the proposal.
>
> Regards
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> htt
Re: [Python-Dev] First draft of "sysconfig"
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
>> 'nt': {
>> 'stdlib': '$base/Lib',
>> 'platstdlib': '$base/Lib',
>> 'purelib': '$base/Lib/site-packages',
>> 'platlib': '$base/Lib/site-packages',
>> 'include': '$base/include',
>> 'platinclude': '$base/include',
>> 'scripts': '$base/Scripts',
>> 'data' : '$base',
>> },
>> ...
>> }
>>
>
> Are you using string.Template because this code needs to run on installs
> older than 2.6?
> -Brett
Not really. That's mostly because I reused the existing implementation
and I found them quite readable in that case. But a string.Formatter
could work well here too I guess.
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First draft of "sysconfig"
On Sat, Dec 12, 2009 at 14:13, Tarek Ziadé wrote:
> On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
> [...]
> >> 'nt': {
> >>'stdlib': '$base/Lib',
> >>'platstdlib': '$base/Lib',
> >>'purelib': '$base/Lib/site-packages',
> >>'platlib': '$base/Lib/site-packages',
> >>'include': '$base/include',
> >>'platinclude': '$base/include',
> >>'scripts': '$base/Scripts',
> >>'data' : '$base',
> >>},
> >> ...
> >> }
> >>
> >
> > Are you using string.Template because this code needs to run on installs
> > older than 2.6?
> > -Brett
>
> Not really. That's mostly because I reused the existing implementation
> and I found them quite readable in that case. But a string.Formatter
> could work well here too I guess.
Just figured that with formatters the way of the future that
"{base}/include" would work just as well and be "future-proof".
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First draft of "sysconfig"
On Sat, Dec 12, 2009 at 11:18 PM, Brett Cannon wrote:
[..]
>> Not really. That's mostly because I reused the existing implementation
>> and I found them quite readable in that case. But a string.Formatter
>> could work well here too I guess.
>
> Just figured that with formatters the way of the future that
> "{base}/include" would work just as well and be "future-proof".
> -Brett
Sure, I'll change it that way, thanks for the tip
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First draft of "sysconfig"
Tarek Ziadé wrote:
On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon wrote:
[...]
'nt': {
'stdlib': '$base/Lib',
'platstdlib': '$base/Lib',
'purelib': '$base/Lib/site-packages',
'platlib': '$base/Lib/site-packages',
'include': '$base/include',
'platinclude': '$base/include',
'scripts': '$base/Scripts',
'data' : '$base',
},
...
}
Are you using string.Template because this code needs to run on installs
older than 2.6?
-Brett
Not really. That's mostly because I reused the existing implementation
and I found them quite readable in that case. But a string.Formatter
could work well here too I guess.
I don't really understand the complete context, but I think you want
str.format(), not string.Formatter here.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First draft of "sysconfig"
That's what I meant. [From my phone] On Dec 12, 2009 4:32 PM, "Eric Smith" wrote: Tarek Ziadé wrote: > > On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon < br...@python.org> wrote: > [ I don't really understand the complete context, but I think you want str.format(), not string.Formatter here. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
2009/12/11 Lennart Regebro : > Should I start a bug report in the tracker for this? Yes, please. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
