P.J. Eby writes:
> it's just that if you already have the bytes, and all you want to
> do is tag them (e.g. the WSGI headers case), the extra encoding
> step seems pointless.
Well, I'll have to concede that unless and until I get involved in the
WSGI development effort.
> >But with your arch
On Sat, Jun 26, 2010 at 9:23 AM, Benjamin Peterson wrote:
> 2010/6/25 Steve Holden :
> I would call it more a sign of no tests rather than one of neglect and
> perhaps also an indication of the usefulness of those tools.
Less than useful tools with no tests probably qualify as neglected...
An as
Am 26.06.2010 02:41, schrieb Stephen Thorne:
> On 2010-06-25, "Martin v. Löwis" wrote:
>>> What page were we suggesting linking to?
>>
>> I don't think anybody proposed anything specific. Steve Holden
>> suggested it should go to "reasoned discussion of the
>> pros and cons as evinced in this threa
On 2010-06-25, "Martin v. Löwis" wrote:
> > What page were we suggesting linking to?
>
> I don't think anybody proposed anything specific. Steve Holden
> suggested it should go to "reasoned discussion of the
> pros and cons as evinced in this thread". Stephen Thorne didn't
> propose anything speci
On Sat, Jun 26, 2010 at 6:12 AM, James Y Knight wrote:
> However, then you have to also consider python packages made up of multiple
> distro packages -- like twisted or zope. Twisted includes some C extensions
> in the core package. But then there are other twisted modules (installed
> under a "t
===
PyPy 1.3: Stabilization
===
Hello.
We're please to announce release of PyPy 1.3. This release has two major
improvements. First of all, we stabilized the JIT compiler since 1.2 release,
answered user issues, fixed bugs, and generally improved speed.
We
2010/6/25 Steve Holden :
> I was pretty stunned when I tried this. Remember that the Tools
> subdirectory is distributed with Windows, so this means we got through
> almost two releases without anyone realizing that 2to3 does not appear
> to have touched this code.
I would call it more a sign of n
Martin v. Löwis wrote:
>> Would that be bad or good (slipping into September)? I'd like to get a
>> release out as soon after 2.7 final as possible, but it's an entirely
>> self-imposed deadline. There's no reason why we can't push the whole 2.6.6
>> thing later if that works better for you. OTO
Martin v. Löwis wrote:
I am extremely keen for this to happen. Does anyone have ownership of this
project? There was some discussion of it up-list but the discussion
fizzled.
>>> Can you please explain what "this project" is, in the context of your
>>> message? GSoC? GHOP?
>> Oh, I
Martin v. Löwis wrote:
> Am 25.06.2010 18:18, schrieb Barry Warsaw:
>> Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
>> time for me to work out the release schedule for Python 2.6.6 - likely the
>> last maintenance release for Python 2.6.
>>
>> Because summer schedul
Martin v. Löwis wrote:
> Am 25.06.2010 18:57, schrieb Terry Reedy:
>> On 6/24/2010 8:51 PM, Rich Healey wrote:
>>> http://docs.python.org/library/copy.html
>> Discussion of the wording of current docs should go to python-list.
>> Py-dev is for development of future Python.
>
> No no no. [...]
It
Glyph Lefkowitz wrote:
>
> On Jun 25, 2010, at 5:02 PM, Guido van Rossum wrote:
>
>> But you'd still have to validate it, right? You wouldn't want to go on
>> using what you thought was wrapped UTF-8 if it wasn't actually valid
>> UTF-8 (or you'd be worse off than in Python 2). So you're really j
Guido van Rossum wrote:
> On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
> wrote:
> >
> > On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote:
> >
> > Regarding the proposal of a String ABC, I hope this isn't going to
> > become a backdoor to reintroduce the Python 2 madness of allowing
> > eq
I was pretty stunned when I tried this. Remember that the Tools
subdirectory is distributed with Windows, so this means we got through
almost two releases without anyone realizing that 2to3 does not appear
to have touched this code.
Yes, I have: http://bugs.python.org/issue9083
When's 3.2 due out
At 01:18 AM 6/26/2010 +0900, Stephen J. Turnbull wrote:
It seems to me what is wanted here is something like Perl's taint
mechanism, for *both* kinds of strings. Am I missing something?
You could certainly view it as a kind of tainting. The part where
the type would be bytes-based is indeed
On Fri, Jun 25, 2010 at 4:02 PM, Guido van Rossum wrote:
> On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
> > I'd like a version of 'decode' which would give me a type that was, in
> every
> > respect, unicode, and responded to all protocols exactly as other
> > unicode objects (or "str objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> But you'd still have to validate it, right? You wouldn't want to go on
> using what you thought was wrapped UTF-8 if it wasn't actually valid
> UTF-8 (or you'd be worse off than in Python 2). So you're really just
> worried a
On 25/06/2010 22:14, "Martin v. Löwis" wrote:
What page were we suggesting linking to?
I don't think anybody proposed anything specific. Steve Holden
suggested it should go to "reasoned discussion of the
pros and cons as evinced in this thread". Stephen Thorne didn't
propose anything speci
On Jun 25, 2010, at 11:16 PM, Martin v. Löwis wrote:
>> Would that be bad or good (slipping into September)? I'd like to get a
>> release out as soon after 2.7 final as possible, but it's an entirely
>> self-imposed deadline. There's no reason why we can't push the whole 2.6.6
>> thing later if
On Jun 25, 2010, at 5:02 PM, Guido van Rossum wrote:
> But you'd still have to validate it, right? You wouldn't want to go on
> using what you thought was wrapped UTF-8 if it wasn't actually valid
> UTF-8 (or you'd be worse off than in Python 2). So you're really just
> worried about space consum
On 25/06/2010 19:35, Michael Foord wrote:
Hello all,
I've put a recipe up on the Python cookbook for creating APIs that
work as both decorators and context managers and wonder if it would be
considered a useful addition to the functools module.
http://code.activestate.com/recipes/577273-deco
> Would that be bad or good (slipping into September)? I'd like to get a
> release out as soon after 2.7 final as possible, but it's an entirely
> self-imposed deadline. There's no reason why we can't push the whole 2.6.6
> thing later if that works better for you. OTOH, I can't go much earlier
> What page were we suggesting linking to?
I don't think anybody proposed anything specific. Steve Holden
suggested it should go to "reasoned discussion of the
pros and cons as evinced in this thread". Stephen Thorne didn't
propose anything specific but to have a large button.
> I'll move the dis
On 25/06/2010 21:27, "Martin v. Löwis" wrote:
I am extremely keen for this to happen. Does anyone have ownership of this
project? There was some discussion of it up-list but the discussion fizzled.
Can you please explain what "this project" is, in the context of your
message? GSoC? GHO
On Jun 25, 2010, at 10:33 PM, Martin v. Löwis wrote:
>Am 25.06.2010 18:18, schrieb Barry Warsaw:
>> Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
>> time for me to work out the release schedule for Python 2.6.6 - likely the
>> last maintenance release for Python 2.6
On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
wrote:
>
> On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote:
>
> Regarding the proposal of a String ABC, I hope this isn't going to
> become a backdoor to reintroduce the Python 2 madness of allowing
> equivalency between text and bytes for *some
On Jun 24, 2010, at 11:37 PM, Éric Araujo wrote:
>Your plan seems good. Adding keyword arguments should not create
>compatibility issues, and I suspect the impact on the code of build_ext
>may be actually quite small. I’ll try to review your patch even though I
>don’t know C or compiler oddities,
On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote:
> Regarding the proposal of a String ABC, I hope this isn't going to
> become a backdoor to reintroduce the Python 2 madness of allowing
> equivalency between text and bytes for *some* strings of bytes and not
> others.
For my part, what I wan
Am 25.06.2010 18:18, schrieb Barry Warsaw:
> Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
> time for me to work out the release schedule for Python 2.6.6 - likely the
> last maintenance release for Python 2.6.
>
> Because summer schedules are crazy, and I want to l
> My apologies guys, I see now.
>
> I will see if I can think of a less ambiguous way to word this and submit a
> bug.
Please don't take out or rephrase the word "shallow", though. This has a
long CS tradition of meaning exactly what is meant here.
Regards,
Martin
__
Am 25.06.2010 18:57, schrieb Terry Reedy:
> On 6/24/2010 8:51 PM, Rich Healey wrote:
>> http://docs.python.org/library/copy.html
>
> Discussion of the wording of current docs should go to python-list.
> Py-dev is for development of future Python.
No no no. Mis-worded documentation is a bug, just
>>> I am extremely keen for this to happen. Does anyone have ownership of this
>>> project? There was some discussion of it up-list but the discussion fizzled.
>>
>> Can you please explain what "this project" is, in the context of your
>> message? GSoC? GHOP?
>
> Oh, I thought this was quite clear
On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
On 6/24/2010 8:23 PM, James Y Knight wrote:
On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
If the package has .so files that aren't compatible with other
version
of python, then what is the motivation for placing that in a shared
location (sinc
On Fri, Jun 25, 2010 at 7:35 PM, Michael Foord
wrote:
> Hello all,
>
> I've put a recipe up on the Python cookbook for creating APIs that work as
> both decorators and context managers and wonder if it would be considered a
> useful addition to the functools module.
> http://code.activestate.com/r
On 6/25/2010 2:58 PM, Brett Cannon wrote:
> I assume you are talking about PEP 3147. You're right that the PEP was
> for pyc files and that's it. No one is talking about rewriting the
> PEP.
Yes, I am making reference to PEP 3147. I make reference to that PEP
because this change is of the same ord
On Fri, Jun 25, 2010 at 01:53, Scott Dial
wrote:
> On 6/24/2010 8:23 PM, James Y Knight wrote:
>> On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
>>> If the package has .so files that aren't compatible with other version
>>> of python, then what is the motivation for placing that in a shared
>>> lo
Hello all,
I've put a recipe up on the Python cookbook for creating APIs that work
as both decorators and context managers and wonder if it would be
considered a useful addition to the functools module.
http://code.activestate.com/recipes/577273-decorator-and-context-manager-from-a-single-api
On 6/24/2010 8:51 PM, Rich Healey wrote:
http://docs.python.org/library/copy.html
Discussion of the wording of current docs should go to python-list.
Py-dev is for development of future Python.
--
Terry Jan Reedy
___
Python-Dev mailing list
Pytho
On Fri, Jun 25, 2010 at 11:30 AM, Stephen J. Turnbull wrote:
> Ian Bicking writes:
>
> > I'm proposing these specials would be used in polymorphic functions,
> like
> > the functions in urllib.parse. I would not personally use them in my
> own
> > code (unless of course I was writing my own po
Ian Bicking writes:
> I don't get what you are arguing against. Are you worried that if
> we make URL code polymorphic that this will mean some code will
> treat URLs as bytes, and that code will be incompatible with URLs
> as text? No one is arguing we remove text support from any of
> the
Ian Bicking writes:
> I'm proposing these specials would be used in polymorphic functions, like
> the functions in urllib.parse. I would not personally use them in my own
> code (unless of course I was writing my own polymorphic functions).
>
> This also makes it less important that the obj
On Jun 25, 2010, at 12:18 PM, Barry Warsaw wrote:
>* Python 2.6.6 rc 1 on Monday 2010-08-02
>* Python 2.6.6 final on Monday 2010-08-16
I've also updated the Google calendar of Python releases:
http://www.google.com/calendar/ical/b6v58qvojllt0i6ql654r1vh00%40group.calendar.google.com/public/basic
P.J. Eby writes:
> I do know the ultimate target codec -- that's the point.
>
> IOW, I want to be able to do to all my operations by passing
> target-encoded strings to polymorphic functions.
IOW, you *do* have text and (ignoring efficiency issues) could just as
well use str. But That Other
Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's
time for me to work out the release schedule for Python 2.6.6 - likely the
last maintenance release for Python 2.6.
Because summer schedules are crazy, and I want to leave two weeks between
2.6.6 rc1 and 2.6.6 final, my
ACTIVITY SUMMARY (2010-06-18 - 2010-06-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2795 open (+38) / 18104 closed (+14) / 20899 total (+52)
Open issues with patches: 1130
Ave
On Fri, Jun 25, 2010 at 5:06 AM, Stephen J. Turnbull wrote:
> > So with this idea in mind it makes more sense to me that *specific
> pieces of
> > text* can be reasonably treated as both bytes and text. All the string
> > literals in urllib.parse.urlunspit() for example.
> >
> > The semanti
On Fri, Jun 25, 2010 at 2:05 AM, Stephen J. Turnbull wrote:
> > But join('x', 'y') -> 'x/y' and join(b'x', b'y') -> b'x/y' make
> > sense to me.
> >
> > So, actually, I *don't* understand what you mean by needing LBYL.
>
> Consider docutils. Some folks assert that URIs *are* bytes and should
>
At 04:49 PM 6/25/2010 +0900, Stephen J. Turnbull wrote:
P.J. Eby writes:
> This doesn't have to be in the functions; it can be in the
> *types*. Mixed-type string operations have to do type checking and
> upcasting already, but if the protocol were open, you could make an
> encoded-bytes ty
Ian Bicking writes:
> We've setup a system where we think of text as natively unicode, with
> encodings to put that unicode into a byte form. This is certainly
> appropriate in a lot of cases. But there's a significant class of problems
> where bytes are the native structure. Network protoc
On Fri, Jun 25, 2010 at 5:34 AM, Nick Coghlan wrote:
> On Fri, Jun 25, 2010 at 11:18 AM, Terry Reedy wrote:
>> I believe there is material on the wiki as well as the two existing pages on
>> other sites that were discussed here. So a new page on python.org could
>> consist of a few links. Someone
On 6/24/2010 9:18 PM, Greg Ewing wrote:
> Scott Dial wrote:
>
>> But the only motivation for doing this with .pyc files is that the .py
>> files are able to be shared,
>
> In an application made up of a mixture of pure Python and
> extension modules, the .py files are able to be shared too.
> See
On 6/24/2010 8:23 PM, James Y Knight wrote:
> On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
>> If the package has .so files that aren't compatible with other version
>> of python, then what is the motivation for placing that in a shared
>> location (since it can't actually be shared)
>
> Because
P.J. Eby writes:
> This doesn't have to be in the functions; it can be in the
> *types*. Mixed-type string operations have to do type checking and
> upcasting already, but if the protocol were open, you could make an
> encoded-bytes type that would handle the error checking.
Don't you rea
Guido van Rossum writes:
> On Thu, Jun 24, 2010 at 1:12 AM, Stephen J. Turnbull
> wrote:
> Understood, but both the majority of str/bytes methods and several
> existing APIs (e.g. many in the os module, like os.listdir()) do it
> this way.
Understood.
> Also, IMO a polymorphic function s
54 matches
Mail list logo
