Re: [Python-Dev] small PATCH to fix os.fsync on OS X

[Scott Dial]

Richard Boulton wrote:
I can't think of a situation where it would be useful to do an fsync() 
in which you don't want the data to be flushed as far as possible.  If 
you're bothering to call fsync(), it's presumably because you need to 
guarantee that the data will be in a consistent state in the event of a 
failure (like a power cut).  So I think it would be helpful for an fsync 
call in a high-level language to handle the details of this.


But the file descriptor functions provided by the posix module are *not* 
high-level calls, and in fact, that is part of the point of the module. 
There is a noticeable performance penalty for waiting on F_FULLSYNC to 
complete, and a programmer who is already going outside of the normal 
mode of python file-handling (using file objects) should have a choice 
in the matter.


-Scott

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] small PATCH to fix os.fsync on OS X

[Richard Boulton]

James Y Knight wrote:

On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote:

While some people might suggest that fullfsync should be exposed as a
method on the 'os' module for platforms that support it, I believe
this is not the best approach.  Because the docstring for os.fsync
says that it forces the file to be written to disk, I think it's up to
python to ensure that functionality is really there on all platforms.
Currently on OS X, fullfsync is needed to provide this functionality,
so I think python's os.fsync should use fullfsync on OS X.


Please don't make that change. fsync on OSX does the same thing as fsync 
traditionally does on other OSes. That is: it flushes the data to 
"disk", but doesn't make any effort to ensure that the disk drive 
actually flushes the data from its own write cache to the platter.


Other OSes just don't expose that functionality *at all*.

See e.g. this thread:
http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html

You should instead propose a patch to add F_FULLSYNC to the fcntl module 
when present.


I can't think of a situation where it would be useful to do an fsync() 
in which you don't want the data to be flushed as far as possible.  If 
you're bothering to call fsync(), it's presumably because you need to 
guarantee that the data will be in a consistent state in the event of a 
failure (like a power cut).  So I think it would be helpful for an fsync 
call in a high-level language to handle the details of this.


However, my perspective is largely tied to databases, so there may be 
other situations that I can't think of where it does make sense to want 
to push changes as far as the on-disk buffers, but no further.


If the change suggested isn't to be made to os.fsync(), I think it would 
at least be helpful to add a note to the os.fsync docstring mentioning 
this limitation, and pointing to the F_FULLSYNC in the fcntl module when 
this is implemented.  And perhaps add an implementation of fsync which 
_does_ also do F_FULLSYNC elsewhere (shutil.fsync()?), to save all those 
users of fsync() who also want F_FULLSYNC from having to implement code 
which calls F_FULLSYNC when available and os.fsync() otherwise.


--
Richard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] small PATCH to fix os.fsync on OS X

[James Y Knight]

On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote:


Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!

As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides "fullfsync"
which actually flushes the file descriptor to disk.  This simple patch
modifies python's "fsync" to take advantage of fullfsync on platforms
that support it:
http://bugs.python.org/issue3512

While some people might suggest that fullfsync should be exposed as a
method on the 'os' module for platforms that support it, I believe
this is not the best approach.  Because the docstring for os.fsync
says that it forces the file to be written to disk, I think it's up to
python to ensure that functionality is really there on all platforms.
Currently on OS X, fullfsync is needed to provide this functionality,
so I think python's os.fsync should use fullfsync on OS X.



Please don't make that change. fsync on OSX does the same thing as  
fsync traditionally does on other OSes. That is: it flushes the data  
to "disk", but doesn't make any effort to ensure that the disk drive  
actually flushes the data from its own write cache to the platter.


Other OSes just don't expose that functionality *at all*.

See e.g. this thread:
http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html

You should instead propose a patch to add F_FULLSYNC to the fcntl  
module when present.


James

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] small PATCH to fix os.fsync on OS X

[Scott Dial]

Ian Charnas wrote:

As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides "fullfsync"
which actually flushes the file descriptor to disk.  This simple patch
modifies python's "fsync" to take advantage of fullfsync on platforms
that support it:
http://bugs.python.org/issue3512


I don't believe your patch is correct. My understanding is that fsync() 
on OS X does the exact same thing as it does on any other POSIX 
platform. On all platforms, fsync() does not guarantee that your data 
has made it to permanent storage. fcntl(fd, F_FULLSYNC) is an additional 
feature on OS X to force the OS X to wait for the underlying device's 
write buffers to have cleared. See the discussion on darwin-dev[1]:


"""
So in summary, I believe that the comments in the MySQL news posting
are slightly confused.  On MacOS X fsync() behaves the same as it does
on all Unices.  That's not good enough if you really care about data
integrity and so we also provide the F_FULLFSYNC fcntl.  As far as I
know, MacOS X is the only OS to provide this feature for apps that
need to truly guarantee their data is on disk.
"""

If you want this feature to be accessible in python, then I think you 
should modify the fcntl module to include F_FULLSYNC.


-Scott

[1] http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] small PATCH to fix os.fsync on OS X

[Ian Charnas]

Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!

As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides "fullfsync"
which actually flushes the file descriptor to disk.  This simple patch
modifies python's "fsync" to take advantage of fullfsync on platforms
that support it:
http://bugs.python.org/issue3512

While some people might suggest that fullfsync should be exposed as a
method on the 'os' module for platforms that support it, I believe
this is not the best approach.  Because the docstring for os.fsync
says that it forces the file to be written to disk, I think it's up to
python to ensure that functionality is really there on all platforms.
Currently on OS X, fullfsync is needed to provide this functionality,
so I think python's os.fsync should use fullfsync on OS X.

Looking at 'svn blame' output for Modules/posixmodule.c, I see that
guido wrote the original python fsync, ronald.oussoren added all the
OS X specific stuff to posixmodule.c, and recent commits have been
made to that file by martin.v.loewis. christian.heimes,
facundo.batista, and gregory.p.smith.  Would any of you fine folks
like to take a look at this?  I believe it's a *very* small patch.

Many thanks,  -Ian Charnas

[1] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c

[2] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X.  To see this
code, download a mysql 5.x source snapshot and open up
mysql-/innobase/os/os0file.c
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

On Wed, Aug 6, 2008 at 9:09 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Nobody's been
>> assigned to look at it and it hasn't been given a priority, even though
>> we all agree it's a bug (though we disagree on how to fix it).
>
> This I can explain (I think). Nobody is assigned to look: we usually
> don't do assignments of bugs or patches, except when there is a specific
> maintainer for the code in question. urllib has no maintainer.

I'm somehow strangely attracted to this issue, and have posted a bit
of a code review.

> It hasn't been given priority: There are currently 606 patches in the
> tracker, many fixing bugs of some sort. It's not clear (to me, at least)
> why this should be given priority over all the other things such as
> interpreter crashes.

Well, it's an API change, and those are impossible after beta3 is
released (or at least have to wait for 3.1).

> We all agree it's a bug: no, I don't. I think it's a missing feature,
> at best, but I'm staying out of the discussion. As-is, urllib only
> supports ASCII in URLs, and that is fine for most purposes. URLs
> are just not made for non-ASCII characters. Implement IRIs if you
> want non-ASCII characters; the rules are much clearer for these.

The wikipedia use of urlencoded UTF-8 (and other examples) suggest
that whether we like it or not the trend is towards this. I'd like to
support such usage rather than fight it (standards or no standards).

> As it stands, a committer would have
> - to agree it's an important problem
> - to agree the patch is correct
> - to judge it is not a new feature, as we are in beta already
> - implicitly accept maintenance of that change, and take all
>  the blame that it might produce in the coming years

It could be a small enough new feature. Also note that for urls that
only use ASCII there is no behavior change. (And certainly this *is*
an important use case, e.g. to encode occurrences of + or & in query
strings).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[M.-A. Lemburg]

On 2008-08-06 18:55, Antoine Pitrou wrote:

Martin v. Löwis  v.loewis.de> writes:

URLs are just not made for non-ASCII characters.


Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
http://wiki.python.org/moin/J%C3%BCrgenHermann
(notice the utf-8 encoding in both)


Implement IRIs if you want non-ASCII characters; the rules are much clearer

for these.

I think most people would expect something which works with the current World
Wide Web rather than a rigorous implementation of a specific RFC. Implementing
RFCs is fine but it does not magically eliminate all problems, especially when
the RFCs themselves are not in sync with real-world usage.


+1. Practicality beats purity...

The web is moving towards UTF-8 as standard Unicode encoding, so
it's probably wise to follow that approach for quote().

http://en.wikipedia.org/wiki/Percent-encoding

The other way around will also have to deal with old-style URLs
which typically still use the Latin-1 encoding which was the
basis for HTML:

http://www.w3schools.com/TAGS/ref_urlencode.asp

So unquote() should probably try to decode using UTF-8 first
and then fall back to Latin-1 if that doesn't work.

Whether the result of quote()/unquote() should be bytes or
Unicode is a different story and probably also depends on
what the application does with the result. I don't think there's
a good general answer for that one, except maybe just going
for one possible combination and document that.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 05 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Martin v. Löwis]

>> Implement IRIs if you want non-ASCII characters; the rules are much clearer
> for these.
> 
> I think most people would expect something which works with the current World
> Wide Web rather than a rigorous implementation of a specific RFC. Implementing
> RFCs is fine but it does not magically eliminate all problems, especially when
> the RFCs themselves are not in sync with real-world usage.

Why do you think implementing IRIs would not work with the current World
Wide Web? IRIs are *made* for the current World Wide Web. Applications
desiring to work in the current World Wide Web would then, of course,
need to use the IRI library.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> URLs are just not made for non-ASCII characters.

Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
http://wiki.python.org/moin/J%C3%BCrgenHermann
(notice the utf-8 encoding in both)

> Implement IRIs if you want non-ASCII characters; the rules are much clearer
for these.

I think most people would expect something which works with the current World
Wide Web rather than a rigorous implementation of a specific RFC. Implementing
RFCs is fine but it does not magically eliminate all problems, especially when
the RFCs themselves are not in sync with real-world usage.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Martin v. Löwis]

> Nobody's been
> assigned to look at it and it hasn't been given a priority, even though
> we all agree it's a bug (though we disagree on how to fix it).

This I can explain (I think). Nobody is assigned to look: we usually
don't do assignments of bugs or patches, except when there is a specific
maintainer for the code in question. urllib has no maintainer.

It hasn't been given priority: There are currently 606 patches in the
tracker, many fixing bugs of some sort. It's not clear (to me, at least)
why this should be given priority over all the other things such as
interpreter crashes.

We all agree it's a bug: no, I don't. I think it's a missing feature,
at best, but I'm staying out of the discussion. As-is, urllib only
supports ASCII in URLs, and that is fine for most purposes. URLs
are just not made for non-ASCII characters. Implement IRIs if you
want non-ASCII characters; the rules are much clearer for these.

As it stands, a committer would have
- to agree it's an important problem
- to agree the patch is correct
- to judge it is not a new feature, as we are in beta already
- implicitly accept maintenance of that change, and take all
  the blame that it might produce in the coming years

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Py_CLEAR and assigning values

[Martin v. Löwis]

Guido van Rossum wrote:
> I don't see a way that __del__ could be invoked and access the NULL
> between the Py_CLEAR() call and the Py_INCREF() call in the second
> version.

Consider this:

  class Bad:
def __del__(self):
  obj.some_method()

  obj.set_foo(Bad())
  obj.set_foo(None)

Now, the second set_foo does a Py_CLEAR on foo, which invokes
Bad.__del__, which invokes a method on obj, which crashes as foo
is NULL - it has not yet been assigned Py_None as expected.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Bill Janssen]

I suggest we continue this discussion, if at all, on the bug-tracker,
where there's code, and more participants.

http://bugs.python.org/issue3300

I've now posted my idea of how quote/unquote should work in py3K, there.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Scott Dial]

André Malo wrote:
* Matt Giuca wrote: 

We've reached, to quote Guido, "as close as consensus as we can get on
this issue".


There are a lot of quotes around. Including "After the most recent flurry of 
discussion I've lost track of what's the right thing to do."

But I don't talk for other people.


Let's not play the who-can-find-the-best-quote-to-make-their-point game. 
Yes, there was a lot of discussion, and yes, it would be difficult to 
follow if it wasn't something you were paying much attention to. I 
believe (as someone who didn't even participate in the discussion) that 
it was clear that:


  * quote/unquote should "just work" for strings in 3.x. Meaning that
quote should be str->str and unquote str->str, because *most* uses
of quote/unquote are naive. There is a quite clear proclamation from
the BDFL that quote/unquote should not be bound by pedantic readings
of the RFCs.

  * an alternative set of functions that support byte->str and str->byte
should be added to support other use-cases that are less naive. Matt
added unquote_to_bytes/quote_from_bytes to fill this gap. Bill
agreed it was sufficient to satisfy his use-cases (stipulating that
they are a necessary addition if any change should be made at all).


There is a bug in Python. I've proposed a working fix, and nobody else
has.


Well, you proposed a patch ;-)
It may fix things, it will break a lot. While this was denied over and over 
again, it's still gonna happen, because the axioms are still not accounting 
for the reality.


I've not read anyone other than Bill come forward saying they had a lot 
of code that uses quote/unquote that will be broke. Matt has went 
through the stdlib and found most uses consistent with the 
"quote/unquote users are naive" statement. I would suggest that the onus 
is on you to substantiate this claim that "it will break a lot."


I made all the changes the community suggested. 


I don't think so.


This short reply is useless. What are those changes? If your problem is 
that *your* suggestions were dropped, then I remind you that they *were 
discussed*. And, Matt correctly pointed out that setting the defaults to 
encoding in latin-1 and decoding in utf-8 would be a nightmare. It would 
be much more sane to pick one encoding for both. However, which encoding 
it should be is an arguable point. The apparent consensus was that most 
people didn't care as long as they could override it.



What more needs to be discussed here?


Huh? You feel, the discussion is over?


Can we please avoid discussions about discussion? Arguing about arguing 
does not benefit this discussion. If you have a problem with his 
proposed patch, then please elaborate on that rather than /just/ 
complain that it is unsatisfactory in some way.


Do you agree there is a bug? Do you agree it needs to be solved? And, 
what about the proposed solution is unsatisfactory?


-Scott

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Matt Giuca]

> There are a lot of quotes around. Including "After the most recent flurry
> of
> discussion I've lost track of what's the right thing to do."
> But I don't talk for other people.
>

OK .. let me compose myself a little. Sorry I went ahead and assumed this
was closed.

It's just frustrating to me that I've now spent a month trying to push this
through, and while it seems everybody has an opinion, nobody seems to have
bothered trying my code. (I've even implemented your suggestions and posted
my feedback, and nobody replied to that). Nobody's been assigned to look at
it and it hasn't been given a priority, even though we all agree it's a bug
(though we disagree on how to fix it).


>
> > There is a bug in Python. I've proposed a working fix, and nobody else
> > has.
>
> Well, you proposed a patch ;-)
> It may fix things, it will break a lot. While this was denied over and over
> again, it's still gonna happen, because the axioms are still not accounting
> for the reality.


Well all you're getting from me is "it works". And all I'm getting from you
is "it might not". Please .. I've been asking for weeks now for someone to
review the patch. I've already spent hours (like ... days worth of hours)
testing this patch against the whole library. I've written reams of reports
on the tracker to try and convince people it works. There isn't any more *I*
can do. If you think it's going to break code, go ahead and try it out.

The claims I am making are based on my experience working with a) Python 2,
b) Python 3 as it stands, c) Python 3 with my patch, and d) Python 3 with
quote/unquote using bytes. In my experience, (c) is the only version of
Python 3 which works properly.

> I made all the changes the community suggested.
>
> I don't think so.
>

?


> > What more needs to be discussed here?
>
> Huh? You feel, the discussion is over? Then why are there still open
> questions? I admit, a lot of discussion is triggered by the assessments
> you're stating in your posts. Don't take it as a personal offense, it's a
> simple observation. There were made a lot of statements and nobody even
> bothered to substantiate them.


If you read the bug tracker  all the way
to the beginning, you'll see I use a good many examples, and I also went
through the entire standard library  to try
and substantiate my claims. (Admittedly, I didn't finish investigating the
request module, but that shouldn't prevent the patch from being reviewed).
As I've said all along, yes, it will break code, but then *all solutions
possible* will break code, including leaving it in. Mine *seems* to break
the least existing code. If there is ever a time to break code, Python 3.0
is it.


> A PEP could fix that.
>

I could write a PEP. But as you've read above, I'm concerned this won't get
into Python 3.0, and then we'll be locked into the existing functionality
and it'll never get accepted; hence I'd rather this be resolved as quickly
as possible. If you think it's worth writing a PEP, let's do it.

Apologies again for my antagonistic reply earlier. Not trying to step on
toes, just get stuff done.

Matt
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[André Malo]

* Matt Giuca wrote: 

> > This whole discussion circles too much, I think. Maybe it should be
> > pepped?
>
> The issue isn't circular. It's been patched and tested, then a whole lot
> of people agreed including Guido. Then you and Bill wanted the bytes
> functionality back. So I wrote that in there too, and Bill at least said
> that was sufficient.
>
> On Thu, Jul 31, 2008, Bill Janssen wrote:
> > But:  OK, OK, I yield.  Though I still think this is a bad idea, I'll
> > shut up if we can also add "unquote_as_bytes" which returns a byte
> > sequence instead of a string.  I'll just change my code to use that.
>
> We've reached, to quote Guido, "as close as consensus as we can get on
> this issue".

There are a lot of quotes around. Including "After the most recent flurry of 
discussion I've lost track of what's the right thing to do."
But I don't talk for other people.

> There is a bug in Python. I've proposed a working fix, and nobody else
> has.

Well, you proposed a patch ;-)
It may fix things, it will break a lot. While this was denied over and over 
again, it's still gonna happen, because the axioms are still not accounting 
for the reality.

> I made all the changes the community suggested. 

I don't think so.

> What more needs to be discussed here?

Huh? You feel, the discussion is over? Then why are there still open 
questions? I admit, a lot of discussion is triggered by the assessments 
you're stating in your posts. Don't take it as a personal offense, it's a 
simple observation. There were made a lot of statements and nobody even 
bothered to substantiate them. A PEP could fix that.

But it's a lost issue now. Nobody comes up with an alternative (for various 
reasons, I suppose). So go ahead, EOD from my side.

nd
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython)

[Leo Soto M.]

On Tue, Aug 5, 2008 at 10:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > But that's going to be easier if I understand the "why" and not only
> > the "how". I can live with a "no idea why" answer, though.
>
> Close -- I would have to do a lot of thinking, swapping in parts of my
> memory that have been gone for years. I say, follow CPython blindly
> and you can't go too wrong: even if the rules are arbitrary, they are
> what everyone expects.

Fair enough. It is going to be tricky with coercion (AFAIK, there is
no easy way to ask two java objects if they share the same method
implementation without resorting to reflection), but I'll do my best.

Thanks!
-- 
Leo Soto M.
http://blog.leosoto.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[Matt Giuca]

> This whole discussion circles too much, I think. Maybe it should be pepped?


The issue isn't circular. It's been patched and tested, then a whole lot of
people agreed including Guido. Then you and Bill wanted the bytes
functionality back. So I wrote that in there too, and Bill at least said
that was sufficient.

On Thu, Jul 31, 2008, Bill Janssen wrote:
>
> But:  OK, OK, I yield.  Though I still think this is a bad idea, I'll shut
> up if we can also add "unquote_as_bytes" which returns a byte sequence
> instead of a string.  I'll just change my code to use that.
>

We've reached, to quote Guido, "as close as consensus as we can get on this
issue".

There is a bug in Python. I've proposed a working fix, and nobody else has.
Guido okayed it. I made all the changes the community suggested. What more
needs to be discussed here?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

[André Malo]

* Bill Janssen wrote: 


> > I'm far less concerned about
> > the decision with regards to unquote_to_bytes/quote_from_bytes, as
> > those are new features which can wait.
>
> Forgive me, but those are the *old* features, which must be there.

This whole discussion circles too much, I think. Maybe it should be pepped?

nd
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com