On Sun, Dec 7, 2008 at 11:04 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 12/7/2008 9:11 PM, came the following characters from the
> keyboard of Adam Olsen:
>> On Sun, Dec 7, 2008 at 9:45 PM, Glenn Linderman <[EMAIL PROTECTED]>
>> wrote:
>
> Once upon a time I did write an unv
On approximately 12/7/2008 9:11 PM, came the following characters from
the keyboard of Adam Olsen:
On Sun, Dec 7, 2008 at 9:45 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
On approximately 12/7/2008 8:13 PM, came the following characters from the
keyboard of Stephen J. Turnbull:
Glenn Linderm
On Sun, Dec 7, 2008 at 9:45 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 12/7/2008 8:13 PM, came the following characters from the
> keyboard of Stephen J. Turnbull:
>>
>> Glenn Linderman writes:
>>
>> > But if you are interested in checking for security issues, shouldn't
>> y
On approximately 12/7/2008 8:13 PM, came the following characters from
the keyboard of Stephen J. Turnbull:
Glenn Linderman writes:
> But if you are interested in checking for security issues, shouldn't you
> _first_ decode into some canonical form,
Yes. That's all that is being asked fo
>> I think it is still timely when fixed in January or February.
>> In fact, releasing it still in December might not be possible,
>> due to the limited time available.
>
> The cmp() / PyObject_Compare() removal patch is almost done.
I wasn't (primarily) talking about fixing this particular issue
Glenn Linderman writes:
> But if you are interested in checking for security issues, shouldn't you
> _first_ decode into some canonical form,
Yes. That's all that is being asked for: that Python do strict
decoding to a canonical form by default. That's a lot to ask, as it
turns out, but th
[EMAIL PROTECTED] writes:
> But still, you can't honestly expect me to recommend 3.0 until someone
> has gotten at least a basic skeleton of Twisted up and running under it
> :). My own attempts to do so have failed miserably, to the point where
> I can't even produce a useful bug report w
On approximately 12/7/2008 10:56 AM, came the following characters from
the keyboard of Adam Olsen:
You might receive a UTF-8 encoded file name from a malicious user,
check if it contains something dangerous (like
"../../../../../etc/password"), then decode it. If your decoder isn't
compliant
>> I'm currently implementing a parser to handle Python 3.0, and one of
>> the points I found conflicting with the grammar specification is the
>> PEP 3104.
>>
>> It says that a shortcut would be added to Python 3.0 so that "nonlocal
>> x = 0" can be written. However, the latest grammar specificati
Barry Warsaw wrote:
I'm personally okay with performance fixes in point releases, as long it
doesn't change API or add additional features.
Does your okay include or exclude new internal APIs like new helper
functions or a new C modules?
Christian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 7, 2008, at 7:05 PM, Christian Heimes wrote:
Martin v. Löwis wrote:
I think it is still timely when fixed in January or February.
In fact, releasing it still in December might not be possible,
due to the limited time available.
The cmp() /
Benjamin Peterson wrote:
I have a patch for this [1], but I don't think this should be
considered a release blocker or even backported to 3.0. It's merely a
convenience feature and doesn't inhibit the usefulness of the PEP in
any way.
Amaury said:
An issue was already filed about this:
http://b
On Sun, Dec 7, 2008 at 6:05 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>>
>> I think it is still timely when fixed in January or February.
>> In fact, releasing it still in December might not be possible,
>> due to the limited time available.
>
> The cmp() / PyObject_C
Martin v. Löwis wrote:
I think it is still timely when fixed in January or February.
In fact, releasing it still in December might not be possible,
due to the limited time available.
The cmp() / PyObject_Compare() removal patch is almost done. With some
help I can finish it until Tuesday eveni
Fabio Zadrozny wrote:
Hi,
I'm currently implementing a parser to handle Python 3.0, and one of
the points I found conflicting with the grammar specification is the
PEP 3104.
It says that a shortcut would be added to Python 3.0 so that "nonlocal
x = 0" can be written.
As near as I can tell fr
Guido van Rossum wrote:
On Sun, Dec 7, 2008 at 1:20 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
Toshio Kuratomi wrote:
- If this is true, a definition of os.listdir() that would
better meet programmer expectation would be: "Give me all files in a
directory with the output as str type". The de
Nick Coghlan wrote:
For binary wrappers around the Windows Unicode APIs, I was thinking
specifically of using UTF-8, since that should be able to encode
anything the Unicode APIs can handle.
Why shouldn't the binary interface just expose the raw
utf16 as bytes?
--
Greg
___
Hello,
Fabio Zadrozny wrote:
> Hi,
>
> I'm currently implementing a parser to handle Python 3.0, and one of
> the points I found conflicting with the grammar specification is the
> PEP 3104.
>
> It says that a shortcut would be added to Python 3.0 so that "nonlocal
> x = 0" can be written. Howeve
Terry Reedy wrote:
> Toshio Kuratomi wrote:
>
>> - If this is true, a definition of os.listdir() that would
>> better meet programmer expectation would be: "Give me all files in a
>> directory with the output as str type". The definition of
>> os.listdir() would be "Give me all files in a direc
Hi,
I'm currently implementing a parser to handle Python 3.0, and one of
the points I found conflicting with the grammar specification is the
PEP 3104.
It says that a shortcut would be added to Python 3.0 so that "nonlocal
x = 0" can be written. However, the latest grammar specification
(http://d
On Sun, Dec 7, 2008 at 1:20 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Toshio Kuratomi wrote:
>
>> - If this is true, a definition of os.listdir() that would
>> better meet programmer expectation would be: "Give me all files in a
>> directory with the output as str type". The definition of
>> o
Toshio Kuratomi wrote:
- If this is true, a definition of os.listdir() that would
better meet programmer expectation would be: "Give me all files in a
directory with the output as str type". The definition of
os.listdir() would be "Give me all files in a directory
with the output as bytes typ
> There's clearly an argument of timeliness there, which
> is why we'd like to get this fixed ASAP.
I think it is still timely when fixed in January or February.
In fact, releasing it still in December might not be possible,
due to the limited time available.
Regards,
Martin
_
On Sat Dec 6 21:29:09 CET 2008, Guido van Rossum wrote:
>
> On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano
> wrote:
> > As someone somewhat knowledgable of how parsers work, I do not
> > understand why a method/attribute name "object_name.as(...)" must
> > necessarily conflict with a standalone ke
On Sun, Dec 7, 2008 at 11:18 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 11:35, Adam Olsen <[EMAIL PROTECTED]> wrote:
http://bugs.python.org/issue3672
http://bugs.python.org/issue3297
>>
>> No. Unicode *requires* them to be treated as errors. If you want to
>>
On Sun, Dec 7, 2008 at 11:35, Adam Olsen <[EMAIL PROTECTED]> wrote:
>>> http://bugs.python.org/issue3672
>>> http://bugs.python.org/issue3297
>
> No. Unicode *requires* them to be treated as errors. If you want to
> pass them through then you're creating a custom encoding... which you
> might arg
[EMAIL PROTECTED] wrote:
>
> On 06:07 am, [EMAIL PROTECTED] wrote:
>> Most apps aren't file managers or ftp clients but when they interact
>> with files (for instance, a file selection dialog) they need to be able
>> to show the user all the relevant files. So on an app-by-app basis the
>> need f
On Sun, Dec 7, 2008 at 2:35 AM, Hagen Fürstenau <[EMAIL PROTECTED]> wrote:
>>> As far as I can see all Python Unicode strings can be encoded to UTF-8,
>>> even things like lone surrogates because Python doesn't care about them.
>>> So both the Unicode API and the binary API would be fail-safe on Wi
On Sun, Dec 7, 2008 at 5:38 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> A point release just to remove a function whose withdrawal has been
> advertised as a 3.0 change hardly seems worth the substantial effort of
> cutting a release. If cmp() shouldn't have been in 3.0 and was then
> there's sur
Hi,
I am looking for a core developer to review a few patches for distutils.
#1 is mandatory (it removes a bad bug)
#2 is very nice to have
#3 to #5 are test coverage and code beautication
In order:
1. #4400 : the default generated .pypirc is broken. This patch fixes
it: http://bugs.python.org/
Brett Cannon wrote:
> On Sat, Dec 6, 2008 at 15:41, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote:
>>
>>> On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson
>>> <[EMAIL PROTECTED]> wrote:
Sinc
Georg Brandl wrote:
> Hi,
>
> with a bit of delay I finally got around to creating a mod_rewrite map of
> the 2.5 URLs. URLs like http://docs.python.org/tut/node3.html will now
> point permanently to the new URL.
>
> Let me know if you find a problem.
Excellent news!
Cheers,
Nick.
--
Nick Co
Hi,
with a bit of delay I finally got around to creating a mod_rewrite map of
the 2.5 URLs. URLs like http://docs.python.org/tut/node3.html will now
point permanently to the new URL.
Let me know if you find a problem.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more,
>> As far as I can see all Python Unicode strings can be encoded to UTF-8,
>> even things like lone surrogates because Python doesn't care about them.
>> So both the Unicode API and the binary API would be fail-safe on Windows.
>
> Python is broken and needs to be fixed.
>
> http://bugs.python.or
On Sun, Dec 7, 2008 at 2:07 AM, Hagen Fürstenau <[EMAIL PROTECTED]> wrote:
>> If the Unicode APIs only have correct unicode, sure. If not you'll
>> get errors translating to UTF-8 (and the byte APIs are supposed to
>> pass bad names through unaltered.) Kinda ironic, no?
>
> As far as I can see al
> If the Unicode APIs only have correct unicode, sure. If not you'll
> get errors translating to UTF-8 (and the byte APIs are supposed to
> pass bad names through unaltered.) Kinda ironic, no?
As far as I can see all Python Unicode strings can be encoded to UTF-8,
even things like lone surrogate
36 matches
Mail list logo
