Martin v. Löwis, 20.02.2010 13:08:
Actually this should not be a fork of the upstream library.
The goal is to improve stability and predictability of the ElementTree
implementations in the stdlib, and to fix some bugs.
I thought that it is better to backport the fixes from upstream than to
On Sun, Feb 28, 2010 at 02:51:16PM +1300, Greg Ewing wrote:
Floris Bruynooghe wrote:
(But even then I'm not
convinced that would double the stat calls for normal users, only for
those who only ship .pyc files)
It would increase the number of stat calls for normal
users by 50%. You would
--
http://www.ironpythoninaction.com
On 28 Feb 2010, at 12:19, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
On Sun, Feb 28, 2010 at 02:51:16PM +1300, Greg Ewing wrote:
Floris Bruynooghe wrote:
(But even then I'm not
convinced that would double the stat calls for normal users,
Michael Foord wrote:
Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for .pyc in the
source directory (2nd stat + read for magic number check). Or
On Sun, Feb 28, 2010 at 11:07:27PM +1000, Nick Coghlan wrote:
Michael Foord wrote:
Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for .pyc in the
Hi,
pysandbox is a new Python sandbox project under development. By default,
untrusted code executed in the sandbox cannot modify the environment (write a
file, use print or import a module). But you can configure the sandbox to
choose exactly which features are allowed or not, eg. import sys
On Sun, Feb 28, 2010 at 05:07, Nick Coghlan ncogh...@gmail.com wrote:
Michael Foord wrote:
Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for
On Sun, 2010-02-28 at 12:21 -0800, Brett Cannon wrote:
Actually it's four: name/__init__.py, name/__init__.pyc, name.py, and
then name.pyc. And just so people have terminology to go with all of
this, this search is what the finder does to say whether it can or
cannot handle the requested
Nick Coghlan a écrit :
Another option is to remove bytecode-only support from the default
filesystem importer, but keep it for zipimport (since the stat call
savings don't apply in the latter case).
bytecode-only in a zip is used by py2exe, cx_freeze and the like, for space
reasons.
Brett Cannon wrote:
Actually it's four: name/__init__.py, name/__init__.pyc, name.py, and
then name.pyc. And just so people have terminology to go with all of
this, this search is what the finder does to say whether it can or
cannot handle the requested module.
Huh, I thought we checked for
Le Sun, 28 Feb 2010 21:45:56 +0100, Baptiste Carvello a écrit :
bytecode-only in a zip is used by py2exe, cx_freeze and the like, for
space reasons. Disabling it would probably hurt them.
Source code compresses quite well. I'm not sure it would make much of a
difference. AFAIR, when you create
Glenn Linderman wrote:
if the
command line/runpy can do it, the importer could do it. Just a matter
of desire and coding. Whether it is worth pursuing further depends on
people's perceptions of kookiness vs. functional and performance
considerations.
Having .py files around that aren't
On Sun, Feb 28, 2010 at 09:45:56PM +0100, Baptiste Carvello wrote:
However, making a difference between zipimport and the filesystem
importer means the application will stop working if I unzip the
library zip file, which is surprising. Unzipping the zip file can be
handy when debugging a bug
Floris Bruynooghe wrote:
Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for .pyc in the
source directory (2nd stat + read for magic number check).
2010/2/28 Stefan Behnel stefan...@behnel.de
I would actually encourage Florent to do the opposite: act now and prepare
a patch against the latest official ET 1.2 and cET releases (or their SVN
version respectively) that integrates everything that is considered safe,
i.e. everything that makes
On Mon, 2010-03-01 at 12:35 +1300, Greg Ewing wrote:
Yes, although that would then incur higher stat overheads for
people distributing .pyc files. There doesn't seem to be a
way of pleasing everyone.
This is all assuming that the extra stat calls are actually
a problem. Does anyone have
Robert Collins wrote:
In the special
case of probing for $name.$ext1, ...$ext2, ...$ext3, you generally hit
the same pages and don't incur additional page in costs.
So then looking for a .pyc alongside a .py or vice versa
should be almost free, and we shouldn't be worrying about
it.
hot
All:
Finding .ini configuration files too limiting, JSON and XML to hard to
manually edit, and YAML too complex to parse quickly, I have started
work on a new configuration file parser.
I call the new format RSON (for Readable Serial Object Notation),
and it is designed to be a superset of JSON.
2010/2/28 Patrick Maupin pmau...@gmail.com:
All:
Finding .ini configuration files too limiting, JSON and XML to hard to
manually edit, and YAML too complex to parse quickly, I have started
work on a new configuration file parser.
In that case, it should live in the user space for several
On Sun, Feb 28, 2010 at 6:29 PM, Benjamin Peterson benja...@python.org wrote:
In that case, it should live in the user space for several years. If
the community decides that it is an excellent format, then it should
be considered for inclusion in the stand library.
Agreed.
However, there are
Le Sun, 28 Feb 2010 18:59:16 -0600,
Patrick Maupin pmau...@gmail.com a écrit :
So, I do not mind the code sitting outside the standard library, and
the PEP not reaching Final for several years, but I do believe that
the PEP process is itself a really good way to build a better
mousetrap by
On Sun, Feb 28, 2010 at 7:39 PM, Antoine Pitrou solip...@pitrou.net wrote:
In this case it is *at best* python-ideas material, or even
preferably comp.lang.python.
I was thinking about comp.lang.python at some point, but thought I
would try here first.
Just for the record, my only reaction
Le Sun, 28 Feb 2010 19:46:30 -0600,
Patrick Maupin pmau...@gmail.com a écrit :
I suppose I have that sort of reaction about areas I am not interested
in, as well, but currently I am deeply interested in configuration
files due to my circumstances. In any case, the observation that
there are
On Sun, Feb 28, 2010 at 16:31, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Robert Collins wrote:
In the special
case of probing for $name.$ext1, ...$ext2, ...$ext3, you generally hit
the same pages and don't incur additional page in costs.
So then looking for a .pyc alongside a .py or
On Sun, Feb 28, 2010 at 12:46, Nick Coghlan ncogh...@gmail.com wrote:
Brett Cannon wrote:
Actually it's four: name/__init__.py, name/__init__.pyc, name.py, and
then name.pyc. And just so people have terminology to go with all of
this, this search is what the finder does to say whether it
On Sun, Feb 28, 2010 at 12:45, Baptiste Carvello baptiste...@free.frwrote:
Nick Coghlan a écrit :
Another option is to remove bytecode-only support from the default
filesystem importer, but keep it for zipimport (since the stat call
savings don't apply in the latter case).
bytecode-only
On Fri, Feb 26, 2010 at 14:15, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Fri, Feb 26, 2010 at 11:13 PM, Brett Cannon br...@python.org wrote:
[..]
I assume you want the Distutils2 component to auto-assign to you like
Distutils currently does? If so I can add the component for you if people
On Sun, Feb 28, 2010 at 7:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
Well, a constructive approach would involve approaching projects
which have devised their own formats, so as to know what kind of
unified format they would be likely to accept (or not).
Trying to poll selected projects
On approximately 2/28/2010 3:22 PM, came the following characters from
the keyboard of Greg Ewing:
Glenn Linderman wrote:
if the command line/runpy can do it, the importer could do it. Just
a matter of desire and coding. Whether it is worth pursuing further
depends on people's perceptions of
Le Sun, 28 Feb 2010 19:32:09 -0800,
Glenn Linderman v+pyt...@g.nevcal.com a écrit :
If your text editor blows up because it is binary, it is a sad text
editor.
If you have .py mapped to a text editor, that's sort of kooky too; I
have it mapped to Python.
File extensions exist for a
Glenn Linderman wrote:
If your text editor blows up because it is binary, it is a sad text editor.
Blow up is probably an exaggeration, but even just getting
a screen full of gibberish when I think I'm opening a
text file is a jarring experience.
If you have .py mapped to a text editor,
On Feb 27, 2010, at 9:38 AM, Nick Coghlan wrote:
I do like the idea of pulling .pyc only imports out into a separate
importer, but would go so far as to suggest keeping them as a command
line option rather than as a separately distributed module.
One advantage of doing this as a separately
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Having .py files around that aren't source text could lead
to a lot of confusion, given that most platforms these days
decide which application to open for a given file based
solely on the filename extension. I wouldn't enjoy trying
to open a
Brett Cannon a écrit :
However, making a difference between zipimport and the filesystem
importer means the application will stop working if I unzip the
library zip file, which is surprising. Unzipping the zip file can be
handy when debugging a bug caused by a forgotten module.
Florent XICLUNA, 01.03.2010 00:36:
I exchanged some e-mails with Fredrik last week. Not sure if it will be
1.2.8 or 1.3, but now he is positive on the goals of the patch. I've
commited all the changes and external fixes to a branch of the Mercurial
repo owned by Fredrik. I'm expecting an
35 matches
Mail list logo
