Guido van Rossum writes:
On Thu, Jun 24, 2010 at 1:12 AM, Stephen J. Turnbull step...@xemacs.org
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
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
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 python
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.
Seems to me
On Fri, Jun 25, 2010 at 5:34 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Jun 25, 2010 at 11:18 AM, Terry Reedy tjre...@udel.edu 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
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 protocols
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 type
On Fri, Jun 25, 2010 at 2:05 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
On Fri, Jun 25, 2010 at 5:06 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
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
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
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:
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 objects
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
these
On Fri, Jun 25, 2010 at 11:30 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
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
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.
On Fri, Jun 25, 2010 at 01:53, Scott Dial
scott+python-...@scottdial.com 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
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 order
On Fri, Jun 25, 2010 at 7:35 PM, Michael Foord
fuzzy...@voidspace.org.uk 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.
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
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. I was
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 like
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: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 leave
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 want
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, but
On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
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 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? GHOP?
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
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
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
Guido van Rossum gu...@python.org wrote:
On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
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 just
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 isn't
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 schedules are
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 thought this was
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. OTOH, I
2010/6/25 Steve Holden st...@holdenweb.com:
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
===
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.
On Sat, Jun 26, 2010 at 6:12 AM, James Y Knight f...@fuhm.net 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
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 specific but to
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 thread. Stephen
On Sat, Jun 26, 2010 at 9:23 AM, Benjamin Peterson benja...@python.org wrote:
2010/6/25 Steve Holden st...@holdenweb.com:
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
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.wink
But with your
46 matches
Mail list logo
