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 an
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.
Greg Ewing 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 .py file only to have m
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
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, that'
Le Sun, 28 Feb 2010 19:32:09 -0800,
Glenn Linderman 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 reason, even if you f
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
On Sun, Feb 28, 2010 at 7:51 PM, Antoine Pitrou 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 which have confi
On Fri, Feb 26, 2010 at 14:15, Tarek Ziadé wrote:
> On Fri, Feb 26, 2010 at 11:13 PM, Brett Cannon 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
> > don't object to the new com
On Sun, Feb 28, 2010 at 12:45, Baptiste Carvello wrote:
> 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 z
On Sun, Feb 28, 2010 at 12:46, Nick Coghlan 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 can or
> > ca
On Sun, Feb 28, 2010 at 16:31, Greg Ewing wrote:
> 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
> shoul
Le Sun, 28 Feb 2010 19:46:30 -0600,
Patrick Maupin 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 already seve
On Sun, Feb 28, 2010 at 7:39 PM, Antoine Pitrou 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 when giving the PE
Le Sun, 28 Feb 2010 18:59:16 -0600,
Patrick Maupin 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 consensus.
On Sun, Feb 28, 2010 at 6:29 PM, Benjamin Peterson 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 too many things w
2010/2/28 Patrick Maupin :
> 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 years. If
the co
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
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 cache
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
2010/2/28 Stefan Behnel
> 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 cET compatible
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).
Y
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 bu
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 s
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 creat
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 fo
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. Disablin
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
On Sun, Feb 28, 2010 at 05:07, 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 m
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 .p
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)
--
http://www.ironpythoninaction.com
On 28 Feb 2010, at 12:19, Floris Bruynooghe
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, only
for
those who only sh
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
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
35 matches
Mail list logo
