Antoine Pitrou wrote:
> Le Tue, 2 Mar 2010 17:28:11 -0800,
> Raymond Hettinger a écrit :
>> -1 for several reasons.
>>
>> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core
>> part of our transition story, so we should keep that as
>> clean/consistent as possible. Deprecating the
2010/3/3 Raymond Hettinger :
>
> -1 for several reasons.
> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core part of
> our transition story, so we should keep that as clean/consistent as
> possible. Deprecating the -3 switch seems like shooting ourselves in the
> foot.
Instead of
On Fri, Feb 26, 2010 at 1:51 PM, Meador Inge wrote:
> Hi All,
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118. Mark Dickinson
> suggested that I bring the discussion on over to
2010/3/3 Florent Xicluna :
>
u'\xff' == bytearray('\xff') # It should raise an error because of '-bb'
> __main__:1: BytesWarning: Comparison between bytearray and string
> False
u'\xff' == '\xff'
> __main__:1: UnicodeWarning: Unicode equal comparison failed to convert
> both arguments
> It seems someone has decided that code.python.org doesn't resolve
> anymore.
I have now restored it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
Nick Coghlan wrote:
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).
+1
Baptiste Carvello wrote:
However, making a difference between zipimport and the filesystem imp
On Tue, Mar 2, 2010 at 9:06 PM, Reid Kleckner wrote:
> I don't think this will help you solve your problem, but one thing
> we've done in unladen swallow is to hack PyType_Modified to invalidate
> our own descriptor caches. We may eventually want to extend that into
> a callback interface, but i
2010/3/3 Daniel Stutzbach :
> I think I see a way to dramatically speed up PyObject_RichCompareBool when
> comparing immutable, built-in, non-container objects (int, float, str,
> etc.). It would speed up list.sort when the key is one of those types, as
> well as most operations on the ubiquitous
I've thought of a possible additional feature for my regex module and
I'm looking for opinions.
Occasionally there's a question about matching multiple regexes and
someone might suggest combining them into one regex using "|".
The feature would be to allow regex.compile, etc, to accept a list or
On Wed, Mar 3, 2010 at 3:29 PM, Benjamin Peterson wrote:
> 2010/3/3 Daniel Stutzbach :
> > I think I see a way to dramatically speed up PyObject_RichCompareBool
> when
> > comparing immutable, built-in, non-container objects (int, float, str,
> > etc.). It would speed up list.sort when the key is
Regarding: http://bugs.python.org/issue7540
The change made in response to this issue report breaks existing uses
of Python 2.6.4.
The mechanize library frequently re-initializes the data in the
request without re-using the request. This worked fine in the past,
and does not trigger the problem
2010/3/3 Michael Foord
>
> As far as I can tell there is no Python 2.6.5 documentation online and the
> link to 3.1 docs is actually for 3.1.1 whilst the link for 3.1.1 docs is dead.
I've now fixed the 3.1.1 docs link.
--
Regards,
Benjamin
___
Pytho
As far as I can tell there is no Python 2.6.5 documentation online and
the link to 3.1 docs is actually for 3.1.1 whilst the link for 3.1.1
docs is dead.
The actual documentation doesn't seem to be in the pydotorg svn
repository so I guess this a release manager issue?
Michael Foord
---
Hey Daniel,
On Wed, Mar 3, 2010 at 1:24 PM, Daniel Stutzbach
wrote:
> On Tue, Mar 2, 2010 at 9:06 PM, Reid Kleckner wrote:
>>
>> I don't think this will help you solve your problem, but one thing
>> we've done in unladen swallow is to hack PyType_Modified to invalidate
>> our own descriptor cach
On Wed, Mar 3, 2010 at 4:34 PM, Collin Winter wrote:
> I would recommend patching py3k, with a backport to trunk.
>
After thinking it over, I'm inclined to patch trunk, so I can run the
Unladen Swallow macro-benchmarks, then forward-port to py3k.
I'm correct in understanding that it will be a wh
On Wed, Mar 3, 2010 at 2:41 PM, Daniel Stutzbach
wrote:
> On Wed, Mar 3, 2010 at 4:34 PM, Collin Winter
> wrote:
>>
>> I would recommend patching py3k, with a backport to trunk.
>
> After thinking it over, I'm inclined to patch trunk, so I can run the
> Unladen Swallow macro-benchmarks, then forw
On Mar 02, 2010, at 09:06 PM, Steven D'Aprano wrote:
>(1) What happens if the __cache__ directory doesn't exist and the
>enclosing directory is unwriteable, or if it does exist, but is
>unreadable?
>
>I expect that the byte code files will simply not be created, and
>everything will continue wi
Just FYI : I am post-poning the revert of Distutils to 2.6.x right
after 2.7a4 has been tagged to avoid any problems (this is in 3 days)
The revert is ready but 3 days is not long enough to make sure
everything is going smooth.
On Fri, Feb 26, 2010 at 10:44 PM, Tarek Ziadé wrote:
> Hello,
>
> Th
I understand the need to ship without source -- but why does that
require supporting .pyc (or .pyo) -only?
Couldn't vendors just replace the real .py files with empty files?
Then no one would need the extra stat call, and no one would be bitten
by orphaned .pyc files after a rename.
[Yes, zips c
Le Wed, 03 Mar 2010 20:43:58 +0100,
"Martin v. Löwis" a écrit :
> > It seems someone has decided that code.python.org doesn't resolve
> > anymore.
>
> I have now restored it.
Thanks a lot!
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace the real .py files with empty files?
Yes, I think that's a possibility. What would people think about that
On Wed, Mar 3, 2010 at 16:37, Jim Jewett wrote:
> I understand the need to ship without source -- but why does that
> require supporting .pyc (or .pyo) -only?
>
> Couldn't vendors just replace the real .py files with empty files?
>
Because if someone screws up the mod time on the source files th
On approximately 3/3/2010 5:49 PM, came the following characters from
the keyboard of Barry Warsaw:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace th
Barry Warsaw wrote:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
Couldn't vendors just replace the real .py files with empty files?
Yes, I think that's a possibility. What would people think about that?
Seems like a perverse thing to have to do to me.
Also a bit fragile, since you woul
Glenn Linderman wrote:
In this scenario, the .pyc files would still live in __pycache__ ?
Complete with the foo..pyc naming ?
It might be neater to have a separate cache directory
for each bytecode version, named __cache.__ or
some such.
--
Greg
__
On Mar 3, 2010, at 10:22 PM, Greg Ewing wrote:
> Glenn Linderman wrote:
>
>> In this scenario, the .pyc files would still live in __pycache__ ? Complete
>> with the foo..pyc naming ?
>
> It might be neater to have a separate cache directory
> for each bytecode version, named __cache.__ or
> s
Le Wed, 3 Mar 2010 17:51:04 -0800,
Brett Cannon a écrit :
> On Wed, Mar 3, 2010 at 16:37, Jim Jewett wrote:
>
> > I understand the need to ship without source -- but why does that
> > require supporting .pyc (or .pyo) -only?
> >
> > Couldn't vendors just replace the real .py files with empty fil
Le Thu, 04 Mar 2010 16:22:13 +1300,
Greg Ewing a écrit :
> Glenn Linderman wrote:
>
> > In this scenario, the .pyc files would still live in __pycache__ ?
> > Complete with the foo..pyc naming ?
>
> It might be neater to have a separate cache directory
> for each bytecode version, named __cac
Glyph Lefkowitz wrote:
if we're going to have it be something.something-else, can we please
make sure that .something-else is a common extension that means
"python bytecode cache"?
Maybe something like
__bytecode-__.pycache
?
--
Greg
___
Python-
Antoine Pitrou wrote:
Unless the .py files arrange to raise a syntax error on compiling.
I guess that prevents a total disaster, but the
program is still broken and you have to hunt down
the offending files and fix the timestamps -- if
it's even evident what the problem is and how to
fix it.
Antoine Pitrou wrote:
Actually, I find it neater to have a single cache directory. It makes
for much less clutter, and simpler ignore rules.
Another possibility would be to have a single top-level
cache directory with a subdirectory for each version:
__bytecode__.pycache//.pyc
I don't thin
Le Thu, 04 Mar 2010 16:39:03 +1300,
Greg Ewing a écrit :
> Antoine Pitrou wrote:
>
> > Unless the .py files arrange to raise a syntax error on compiling.
>
> I guess that prevents a total disaster, but the
> program is still broken and you have to hunt down
> the offending files and fix the time
On Thu, Mar 4, 2010 at 3:45 AM, Fred Drake wrote:
> Regarding: http://bugs.python.org/issue7540
>
> The proper response to this issue for Python 2.6 is to make no code
> changes (though a documentation enhancement may be in order).
>
> This change should be reverted from all branches.
>
> Python
33 matches
Mail list logo
