>> If not, I'd like to propose that we phase out that support: the Windows
>> 2.7 installer should display a warning; 3.2 will stop supporting Windows
>> 2000.
>
>Is there any reason for this? I can understand dropping Windows 9x
> due to the lack of Unicode support but is there anything missi
On Mon, 2010-03-01 at 15:35 -0800, Collin Winter wrote:
> Hey packaging guys,
>
> We recently committed a change to Unladen Swallow [1] that moves all
> the JIT infrastructure into a Python extension module. The theory [2]
> behind this patch was that this would make it easier for downstream
> pac
Martin v. Löwis:
> I don't recall whether we have already decided about continued support
> for Windows 2000.
>
> If not, I'd like to propose that we phase out that support: the Windows
> 2.7 installer should display a warning; 3.2 will stop supporting Windows
> 2000.
Is there any reason for t
On Sat, Feb 27, 2010 at 11:20 AM, Thomas Heller wrote:
> See issue 887237:
>
> http://bugs.python.org/issue887237
>
Thanks for the link Thomas. Since there is already interest in adding
arithmetic to ctypes, perhaps that is an option. One question that raises
in my mind, though, is should only
On Mon, Mar 1, 2010 at 13:40, "Martin v. Löwis" wrote:
> I don't recall whether we have already decided about continued support
> for Windows 2000.
>
> If not, I'd like to propose that we phase out that support: the Windows
> 2.7 installer should display a warning; 3.2 will stop supporting Window
Thanks everybody for providing great input on this aspect of the PEP. I've
updated the open issues section to include a list of the possible resolutions
for bytecode-only imports. Unless anybody has more ideas, it might just be
time to get a BDFL pronouncement.
-Barry
signature.asc
Description
On Feb 28, 2010, at 11:07 PM, Nick Coghlan wrote:
>While the PEP is right in saying that a bytecode-only import hook could
>be added, I believe it would actually be a little tricky to write one
>that didn't severely degrade the performance of either normal imports or
>bytecode-only imports. Keepin
On Feb 28, 2010, at 02:51 PM, Greg Ewing wrote:
>A solution might be to look for the presence of the
>cache directory, and only look for a .pyc in the source
>directory if there is no cache directory. Testing for
>the cache directory would only have to be done once
>per package and the result reme
On Feb 28, 2010, at 10:40 PM, Antoine Pitrou wrote:
>File extensions exist for a reason, even if you find that "kooky" and
>have strong ideas about the psychology of text editors.
>
>Having some binary files named "foobar.py" would certainly annoy a lot
>of people, including me.
I completely agre
Hey packaging guys,
We recently committed a change to Unladen Swallow [1] that moves all
the JIT infrastructure into a Python extension module. The theory [2]
behind this patch was that this would make it easier for downstream
packagers to ship a JIT-less Python package, with the JIT compiler
avai
On Mar 1, 2010, at 4:53 PM, Guido van Rossum wrote:
> On Mon, Mar 1, 2010 at 1:40 PM, "Martin v. Löwis" wrote:
>> I don't recall whether we have already decided about continued support
>> for Windows 2000.
>>
>> If not, I'd like to propose that we phase out that support: the Windows
>> 2.7 inst
On Mon, Mar 1, 2010 at 1:40 PM, "Martin v. Löwis" wrote:
> I don't recall whether we have already decided about continued support
> for Windows 2000.
>
> If not, I'd like to propose that we phase out that support: the Windows
> 2.7 installer should display a warning; 3.2 will stop supporting Windo
Ron Adam wrote:
What if ... a bytecode-only mode is triggered by "__main__" loading from
a bytecode file, otherwise the .py files are needed and are checked to
make sure the bytecode files are current.
That would preclude having a bytecode-only library that
could be used by a sourceful progra
I don't recall whether we have already decided about continued support
for Windows 2000.
If not, I'd like to propose that we phase out that support: the Windows
2.7 installer should display a warning; 3.2 will stop supporting Windows
2000.
Opinions?
Regards,
Martin
__
On Mon, Mar 1, 2010 at 8:45 PM, Jacob Kaplan-Moss wrote:
> Hey folks --
>
> Can someone point me to some information on what's going on with PEP
> 381 (PyPI mirroring)? There's a bunch of XXX'd material, and it
> doesn't appear that pypi.python.org implements the statistics or
> providing parts.
>
Any people who have commit privileges not subscribed to python-committers?
We have gained some new people recently so I just want to make sure everyone
is subscribed to the list.
Also, anyone have an email address for Hirokazu Yamamoto? His mailbox is
full so Mailman unsubscribed him.
-Brett
On Mon, Mar 1, 2010 at 08:30, Ron Adam wrote:
>
>
> 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
On 3/1/2010 2:45 PM, Jacob Kaplan-Moss wrote:
Hey folks --
Can someone point me to some information on what's going on with PEP
381 (PyPI mirroring)? There's a bunch of XXX'd material, and it
doesn't appear that pypi.python.org implements the statistics or
providing parts.
I'd be willing -- hap
Hey folks --
Can someone point me to some information on what's going on with PEP
381 (PyPI mirroring)? There's a bunch of XXX'd material, and it
doesn't appear that pypi.python.org implements the statistics or
providing parts.
I'd be willing -- happy, actually -- to fill in the missing pieces,
b
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
source directory (2nd stat + read for magic
On Mon, Mar 1, 2010 at 3:02 AM, Daniel Fetchinson wrote:
> Quick question: if JSON is too hard to manually edit, how can RSON be
> any easier when it is a *superset* of JSON?
>
Well, Python is essentially a superset of JSON, with string escape handling
being ever so slightly different, and usin
Le Mon, 01 Mar 2010 09:09:09 +0100,
Baptiste Carvello a écrit :
>
> I did a quick check on the stdlib: a zip with .py and .pyc is about
> 80% bigger than one with .pyc only. If you use only the bytecode,
> this can be seen as waisted space. On the other hand, if you ever
> need to debug the appli
Brett Cannon wrote:
> So there are a total of five to six depending on the OS (actually, VMS
> goes up to eight!) before a search path is considered not to contain a
> module.
The windows list is actually going to be slightly different (dir, pyd,
py, pyw, py[co]). It looks for .pyd files rather th
> Finding .ini configuration files too limiting, JSON and XML to hard to
> manually edit
[snip]
> I call the new format RSON (for "Readable Serial Object Notation"),
> and it is designed to be a superset of JSON.
Quick question: if JSON is too hard to manually edit, how can RSON be
any easier wh
Antoine Pitrou a écrit :
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
differen
On Sun, 2010-02-28 at 18:11 -0800, Brett Cannon wrote:
...
> So then looking for a .pyc alongside a .py or vice versa
> should be almost free, and we shouldn't be worrying about
> it.
> But that is making the assumption that all filesystems operate this
> way (.e.g does NF
26 matches
Mail list logo
