Barry Warsaw wrote:
On Jan 31, 2010, at 01:06 PM, Ron Adam wrote:
With a single cache directory, we could have an option to force writing
bytecode to a desired location. That might be useful on it's own for
creating runtime bytecode only installations for installers.
One important reason
Sense this is something new, I believe it is helpful to look at all the
possibilities so it doesn't become something we regret we did later. This
is something that once it gets put in place may be real hard to get rid of.
So here are a few questions that I think haven't seen asked yet.
David Lyon wrote:
Eric Smith wrote:
This discussion probably belongs on the distutils list.
Yes, the discussion should be.
Except that distutils doesn't have very much support for doing
applets or applications. So it's logical to see why most posts which
ask the same question, often go
, script, or
application) a lot easier if I keep certain things in mind? Are there any
best practices I should keep in mind if I intend to distribute my work?
Are there changes that can be made to python that can make things easier
for various combinations of the above?
Regards,
Ron Adam
for that reason. My apologies for
any confusion.
Regards,
Ron
Ron Adam wrote:
Can I make my efforts in developing a (module, package, script, or
application) a lot easier if I keep certain things in mind? Are there
any best practices I should keep in mind if I intend to distribute my
work
Guido van Rossum wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
How about something on the differences and obstacles of using Python for
developing full distributable applications vs small local scripts.
I'd like to see Python 3+ be more
Jeremy Hylton wrote:
A question came up at work about docstring formatting. It relates to
the description of the summary line in PEP 257.
http://www.python.org/dev/peps/pep-0257/
Multi-line docstrings consist of a summary line just like a
one-line docstring, followed by a blank line,
P.J. Eby wrote:
Sure. But right now, the return value of a generator function *is the
generator*. And you're free to ignore that, sure.
But this is a second return value that only goes to a special place
with special syntax -- without that syntax, you can't access it.
But in the use
Ron Adam wrote:
P.J. Eby wrote:
Sure. But right now, the return value of a generator function *is the
generator*. And you're free to ignore that, sure.
But this is a second return value that only goes to a special place
with special syntax -- without that syntax, you can't access
Tennessee Leeuwenburg wrote:
Hi all,
I'm continuing to (slowly) work through issues. I have been looking
particularly at a lot of the open issues regarding strftime.
It would be great to put in some of those extra status options that were
discussed recently...
Open/New
Needs help
Nick Coghlan wrote:
Taking an existing function such as assertRaises and going hey, we
aren't using the return value from this, wouldn't it be really
convenient if it told us the exact exception it actually caught?
doesn't cause any problems for existing code, and makes it much easier
to
Raymond Hettinger wrote:
From: Ben Finney [EMAIL PROTECTED]
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using
Ben Finney wrote:
Ron Adam [EMAIL PROTECTED] writes:
+1 for a simpler testing module.
I've no objection.
Just letting you know there is interest in a lighter weight testing
suite.
'doctest' is a very simple testing module, that is a very useful tool.
Looking at the unittest
Antoine Pitrou wrote:
Ben Finney bignose+hates-spam at benfinney.id.au writes:
That would better be written (preferring PEP 8 names)
fail_unless_equal.
Which is still a double negative (fail and unless are both negative words).
That's another reason to avoid assert in the name: these
Martin v. Löwis wrote:
How does 1 directory scale when one day you have possibly thousands of
tests?
I find this a theoretical question. It took 18 years to arrive at 500
test files. Assuming a linear growth, we get 1000 tests in 2025, and
2000 tests in 2060. People can worry about
Michael Foord wrote:
Guido van Rossum wrote:
I'm worried that a mass renaming would do anything but inconvenience
users during the already stressful 2-3 transition.
I'm more in favor of the original proposal of reducing the redundancy
post-3.0.
So nix the PEP-8'ifying until after
Nick Coghlan wrote:
Martin v. Löwis wrote:
One issue to consider is also politeness. People sometimes complain that
they feel treated unfair if their report is declared invalid - they
surely believed it was a valid report, at the time they made it.
I agree with Martin for both of these -
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
Barry Warsaw wrote:
Why should docstrings and comments be limited to 72 characters when
code is limited to 79 characters? I ask because there is an ongoing
debate at my
Barry Warsaw wrote:
Why should docstrings and comments be limited to 72 characters when
code is limited to 79 characters? I ask because there is an ongoing
debate at my company about this.
I'm not sure if this is the main reason, but when using pydoc to view
docstrings, the 72
Raymond Hettinger wrote:
Please ignore my last email. The idea for combining trunc, ceil,
floor, etc was probably just a distractor.
I was going to suggest the same round(n, mode=round_method_of choice) to
both round and int(), where int is more forgiving for input. But wasn't
convinced.
Raymond Hettinger wrote:
The standard library, my personal code, third-party packages, and my
employer's code base are filled with examples of the following pattern:
try:
import threading
except ImportError:
import dummy_threading as threading
try:
import
* This didn't show up when I sent it the other day, so I'm resending it.
Facundo Batista wrote:
2007/12/10, Ron Adam [EMAIL PROTECTED]:
This is from the search page of the tracker.
select name=resolution id=resolution
option value=don't care/option
option value= disabled
Facundo Batista wrote:
2007/12/8, Ron Adam [EMAIL PROTECTED]:
Looks much improved! :-)
Thanks!
Maybe components and keywords could be combined together and use check
boxes so more than one item at a time can be selected?
Regarding the combination, I don't think so: I'm
Facundo Batista wrote:
2007/12/10, Ron Adam [EMAIL PROTECTED]:
This is from the search page of the tracker.
select name=resolution id=resolution
option value=don't care/option
option value= disabled=disabled/option
option value=1accepted/option
Facundo Batista wrote:
2007/11/1, Facundo Batista [EMAIL PROTECTED]:
I think the keyword and keywords interface can be improved. Do you have
any plans in that direction?
Surely!
But, no, I have no plans to do it, as I can not make cgi scripts in my
hosting, so these pages are statics,
Christian Heimes wrote:
I'm sending this mail to Python-dev in the hope to reach more developers.
GvR likes to rename the __builtin__ to reduce confusing between
__builtin__ and __builtins__. He wanted to start a poll on the new name
but apparently he forgot.
From
Fred Drake wrote:
On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote:
+1 for either __root_namespace__ or __root__.
What is it with nutrient extractors for plants that makes sense here?
Root is a word that takes on a specific meaning depending on the context.
Root as in tooth root,
Facundo Batista wrote:
2007/10/24, Ron Adam [EMAIL PROTECTED]:
Note that these items are *all* open.
I think the page title should reflect this. Possible changing it from
Python tickets
to
Python Open Tickets
Good point! It's fixed now.
Thank you!
Clicking on one
Facundo Batista wrote:
2007/9/19, Ron Adam [EMAIL PROTECTED]:
I noticed that there is a background of light blue between marks. That is
hard to see on my computer because it is so close to the grey tone.
Made it a little darker, now it's easier to look.
Also shouldn't the light
The value of a unittest test is not in how well they pass, but in how well
they fail.
While looking at possibly helping with the str_uni branch when that was
going on I found that in some cases unittest failure results can take a
little bit (or a lot) of work to figure out just what was
Facundo Batista wrote:
2007/9/10, Facundo Batista [EMAIL PROTECTED]:
I modified my tool, whichs makes a summary of all the Python tickets
(I moved the source where the info is taken from SF to our Roundup).
Based on an idea from Dennis Benzinger, now the temporal bars show the
moments
Georg Brandl wrote:
Sure, you could use ``iter(())`` or ``iter([])``, but for consistency's sake
wouldn't it make sense for ``iter()`` to return an empty iterator, as
``str()``
returns an empty string etc.?
Georg
There is a difference.
type(iter)
type 'builtin_function_or_method'
Georg Brandl wrote:
Hi,
We managed to get an up to date version of the web version of the docs running
on the server. The address is still the same (http://pydoc.gbrandl.de:3000)
and
it's also still running on top of wsgiref.
Changes so far:
* comments: each page that is generated
Nick Craig-Wood wrote:
On Wed, May 23, 2007 at 12:46:50PM -0500, Ron Adam wrote:
Nick Craig-Wood wrote:
So I'll be able to read the main docs for a module in a terminal
without reaching for the web browser (or info)? That would be great!
How would pydoc decide which bit of docs
with Ron Adam to make the pydoc -
documentation integration as seamless as possible.
So I'll be able to read the main docs for a module in a terminal
without reaching for the web browser (or info)? That would be great!
How would pydoc decide which bit of docs it is going to show?
Pydoc
too?
It is my intention to work together with Ron Adam to make the pydoc -
documentation integration as seamless as possible.
So I'll be able to read the main docs for a module in a terminal
without reaching for the web browser (or info)? That would be great!
One option is to use a text-mode
Georg Brandl wrote:
Hi,
over the last few weeks I've hacked on a new approach to Python's
documentation.
As Python already has an excellent documentation framework, the docutils,
with a
readable yet extendable markup format, reST, I thought that it should be
possible to use those
Talin wrote:
Josiah Carlson wrote:
Captchas like this are easily broken using computational methods, or
even the porn site trick that was already mentioned. Never mind
Stephen's stated belief, that you quoted, that he believes that even the
hard captchas are going to be beaten by
Martin v. Löwis wrote:
This is what prompted my question, actually: in Py3k, in the
str/unicode unification branch, r\u1234 changes meaning: before the
unification, this was an 8-bit string, where the \u was not special,
but now it is a unicode string, where \u *is* special.
That is true
Georg Brandl wrote:
FWIW, I'm -1 on both proposals too. I like implicit string literal
concatenation
and I really can't see what we gain from backslash continuation removal.
Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end with
Benji York wrote:
Ron Adam wrote:
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
print rhello world\
File stdin, line 1
print rhello world\
^
SyntaxError: EOL while scanning single-quoted
Delaney, Timothy (Tim) wrote:
What I'm proposing is that the `super = super_factory()` line be
implicit in this case, resulting in the following code behaving
identically:
class A(object):
def f(self):
def inner():
return 'A' + super.f()
be submitted and a final discussion can take place on the
python-dev list at a later date.
Thanks and Regards,
Ron Adam
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Johann C. Rocholl wrote:
Brilliant!
On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote:
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK
CAPITAL C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
This is still easy to read and makes the full power of
Martin v. Löwis wrote:
Ron Adam schrieb:
But the tracker needs to be able to actually track the status of
individual items for this to work. Currently there's this huge list
and you have to either wade though it to find out the status of each
item, or depend on someone bring it to your
Neal Norwitz wrote:
I recognize there is a big problem here. Each of us as individuals
don't scale. So in order to get stuff done we need to be more
distributed. This means distributing the workload (partially so we
don't burn out). In order to do that we need to distribute the
Neal Norwitz wrote:
On 3/6/07, Ron Adam [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I'm looking forward to a new tracker and hope it manages single
projects...
(patches and bugs) better. It would be great if we could search for
items
based on possibly the following conditions
Larry Hastings wrote:
Neal Becker wrote:
Instead, bool fails in _the worst possible way_: it silently gives a
_wrong result_.
I disagree with the word fail there; Python is working correctly. The
behavior of converting expressions to a boolean is well-defined:
Georg Brandl wrote:
Martin v. Löwis schrieb:
Anthony Baxter schrieb:
and the wrapper class idea of Nick Coghlan:
attrview(obj)[foo]
This also appeals - partly because it's not magic syntax wink
I also like this. I would like to spell it attrs, and
I think its specification is
class
Martin v. Löwis wrote:
Ron Adam schrieb:
Would it be possible for attrview to be a property?
Sure. It might conflict with a proper name of an attribute, of course.
Something like... (Probably needs more than this to handle all cases.)
class obj(object):
def _attrview(self
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to
Raymond Hettinger wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why would I switch to a bytes type
Laurent Gautier wrote:
2007/1/7, Ron Adam [EMAIL PROTECTED]:
Laurent Gautier wrote:
2007/1/6, Ron Adam [EMAIL PROTECTED]:
[...]
I'd like to know more about using the sandbox, I know it would be easy
for
people to read the source there, but who all can have write access to
it without
Neal Becker wrote:
No time to review this now, but I'd just like to say that the 1 thing I'd
like to see is support for decent mathematical markup. I think at this
point that support for latex markup is the way to achieve this.
There are two separate issues related to this I'd like to point
Laurent Gautier wrote:
2007/1/6, Ron Adam [EMAIL PROTECTED]:
Laurent Gautier wrote:
[...]
I read your comment about having not too many things changed for 2.6.
(or that will be bumped to 3000).
A suggestion I would have would be to create an html/htmlrender module
in the pydoc-package
Laurent Gautier wrote:
Ron,
Thanks for your detailed answer.
I inserted comments below.
You welcome.
I think any API issues could be worked out. Are there any programs
you know of,
(yours?), that import pydoc besides the python console?
What I did barely qualifies as a hack
Laurent Gautier wrote:
Ron,
I agree that pydoc could benefit a bit from some cleanup.
As you point it out, the ability to write quick viewers would be
very helpful. I came across that when wanting to develop script
on a remote web server for which I only had FTP access: I ended
up having
Ka-Ping Yee wrote:
Hi Ron and Laurent,
I welcome attempts to improve pydoc (especially since I don't have
much time to work on improving it myself). I definitely agree that
moving to CSS is long overdue, though I would like some input on
the style of the produced pages.
Additional input
Larry Hastings wrote:
Just asking--are you going in a PEP-287-ly way as you work? If not,
would your work make PEP 287 easier to implement?
Pydoc does no reformatting or changes to doc strings. They are displayed as
is in plain text. About the only formatting that is done is to wrap long
.
The still very rough source files can be downloaded from:
http://ronadam.com/dl/_pydoc.zip
There is still much to do, but I think having some experienced feed back on
where it should go is important.
Cheers,
Ron Adam
ps.. Please disregard the website for now, it's purpose was to share
The only benefit I imagine would be for an extension module library
writer and for users of the struct and array modules. But, other than
that, I don't know. It actually doesn't have to be exposed to Python.
I used Python notation in the PEP to explain what is basically a
C-structure.
Gregory P. Smith wrote:
I've never liked the .join([]) idiom for string concatenation; in my
opinion it violates the principles Beautiful is better than ugly. and
There should be one-- and preferably only one --obvious way to do it..
(And perhaps several others.) To that end I've submitted
Josiah Carlson wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote:
Ron Adam wrote:
I think what may be missing is a larger set of higher level string
functions
that will work with lists of strings directly. Then lists of strings can
be
thought of as a mutable string type by its use
Nicko van Someren wrote:
On 6 Oct 2006, at 12:37, Ron Adam wrote:
I've never liked the .join([]) idiom for string concatenation; in my
opinion it violates the principles Beautiful is better than ugly. and
There should be one-- and preferably only one --obvious way to do
it..
...
Well I
Nick Coghlan wrote:
Fuzzyman wrote:
Nick Coghlan wrote:
In my example, the 3 sections (setup code, loop body and loop
completion
code are all optional. A basic do-while loop would look like this:
do:
setup code
while condition
(That is, setup code is still
Nick Coghlan wrote:
Hans Polak wrote:
Hi,
Just an opinion, but many uses of the ‘while true loop’ are instances of
a ‘do loop’. I appreciate the language layout question, so I’ll give you
an alternative:
do:
body
setup code
while
Michael Urman wrote:
On 10/1/06, Ron Adam [EMAIL PROTECTED] wrote:
(I don't think this has been suggested yet.)
while enter_condition, exit_condition:
body
[snip]
Putting both the entry and exit conditions at the top is easier to read.
I agree in principle, but I thought
Josiah Carlson wrote:
BJörn Lindqvist [EMAIL PROTECTED] wrote:
If there are rampant criticisms of the Python docs, then those that
are complaining should take specific examples of their complaints to the
sourceforge bug tracker and submit documentation patches for the
relevant sections. And
Michael Chermside wrote:
Jim Jewett writes:
This change [in docs] looks wrong:
PyDoc_STRVAR(rpartition__doc__,
-S.rpartition(sep) - (head, sep, tail)\n\
+S.rpartition(sep) - (tail, sep, head)\n\
Raymond Hettinger replies:
It is correct. There may be some confusion in terminology. Head
Ron Adam wrote:
Correcting myself...
I hope this discussion is only about the words used and the
documentation and not about the actual order of what is received. I
would expect both the following should be true, and it is the current
behavior.
''.join(s.partition(sep)) - s
Raymond Hettinger wrote:
Another thought is that strings don't really have a left and right.
They have a beginning and end. The left/right or top/bottom distinction
is culture specific.
Well, it should have been epartition() and not rpartition() in that case. ;-)
Is python ever edited
M.-A. Lemburg wrote:
Michael Chermside wrote:
How about we change unicode-vs-str __eq__ to
issue a warning (and return False) instead of raising
UnicodeException?
[... Marc-Andre Lemburg agrees ...]
Great! Now we need someone to volunteer to write a patch (which should
include doc and
M.-A. Lemburg wrote:
Terry Reedy wrote:
Michael Hudson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Michael Chermside [EMAIL PROTECTED] writes:
I'm changing the subject line because I want to convince everyone that
the problem being discussed in the unicode hell thread has
Greg Ewing wrote:
Raymond Hettinger wrote:
-1 on an extra built-in just to save the time for function call
The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has put forward an argument to
Nick Coghlan wrote:
Ron Adam wrote:
Consider an example where you are combining data that had different
number of significant digits. Keeping all the digits of your answer
gives a false since of accuracy. The extra digits are meaningless
because the margin of error is greater than any
Nick Maclaren wrote:
M.-A. Lemburg [EMAIL PROTECTED] wrote:
You often have a need for controlled rounding when doing
financial calculations or in situations where you want to
compare two floats with a given accuracy, e.g. to work
around rounding problems ;-)
The latter is a crude hack, and
the pydoc output (or selected parts of it) along with the longer
explanation and discussion. Having pydoc produce xml as an intermediate
format makes these types of things easier to do.
Cheers,
Ron Adam
___
Python-Dev mailing list
Python-Dev
Christos Georgiou wrote:
I haven't followed the complete discussion about once, but I would assume it
would be used as such:
once name = expression
that is, always an assignment, with the value stored as a cellvar, perhaps,
on first execution 0f the code.
Typically I would use it as:
I believe at least one poster has pointed out that 'once' (if defined
suitably) could be used as a better way to do this:
def index_functions(n):
return [(lambda: once i) for i in range(n)]
But delaying the evaluation of the once argument until the function is
called would break
Given that variant, my reasons for preferring Option 2 over Option 3 are:
- the semantics are the same at module, class and function level
- the order of execution roughly matches the order of the source code
- it does not cause any surprises when switches are inside conditional logic
Guido van Rossum wrote:
On 6/27/06, Ron Adam [EMAIL PROTECTED] wrote:
I use dict base dispatching in a number of my programs and like it with
the exception I need to first define all the code in functions (or use
lambda) even if they are only one line. So it results in a three step
process
Guido van Rossum wrote:
What was intended probably would be more closely related to constructing
a switch with BASICS gosub command.
I understand now.
But I have a question: if I write
for i in range(10):
switch S:
case i: print 42
(i.e. the switch is *inside* the for
Ron Adam wrote:
In this instance the switch would be redefined 10 times. The ending
switch would be:
switch S:
case 10: print 42
Silly mistake correction... :)
switch S:
case 9: print 42
___
Python-Dev mailing
Fredrik Lundh wrote:
Guido van Rossum wrote:
just map
switch EXPR:
case E1:
...
case in E2:
...
else:
...
to
VAR = EXPR
if VAR == E1:
...
elif VAR in E2:
...
else:
...
where VAR
Raymond Hettinger wrote:
From what I can see, almost everyone wants a switch statement, though perhaps
for different reasons.
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a
[EMAIL PROTECTED] wrote:
Skip There seem to be other places where Python is beginning to require
Skip parens even though they aren't strictly necessary to resolve
Skip syntactic ambiguity.
Guido In the style guide only, I hope.
Alex Technically, I believe the first
Greg Ewing wrote:
Ron Adam wrote:
This uses syntax to determine the direction of encoding. It would be
easier and clearer to just require two arguments or a tuple.
u = unicode(b, 'encode', 'base64')
b = bytes(u, 'decode', 'base64')
The point of the exercise was to avoid
Greg Ewing wrote:
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return
Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
u = unicode(b)
u = unicode(b, 'utf8')
b = bytes['utf8'](u)
u = unicode['base64'](b) # encoding
b = bytes(u, 'base64') # decoding
u2 = unicode['piglatin'](u1) # encoding
u1 = unicode(u2, 'piglatin') #
Nick Coghlan wrote:
All the unicode codecs, on the other hand, use encode to get from characters
to bytes and decode to get from bytes to characters.
So if bytes objects *did* have an encode method, it should still result in a
unicode object, just the same as a decode method does (because
Greg Ewing wrote:
Ron Adam wrote:
While playing around with the example bytes class I noticed code reads
much better when I use methods called tounicode and tostring.
b64ustring = b.tounicode('base64')
b = bytes(b64ustring, 'base64')
I don't like that, because it creates
logical analysis, it might be of some interest even if
it's reviewing the obvious to those who already know.
(And hopefully I didn't make any really obvious errors myself.)
Stephen J. Turnbull wrote:
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron We could call it transform or translate
Neil Schemenauer wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Why was it decided that the unicode encoding argument should be ignored
if the first argument is a string? Wouldn't an exception be better
rather than give the impression it does something when it doesn't?
From the PEP
Terry Reedy wrote:
Greg Ewing [EMAIL PROTECTED] wrote in message
Which is why I think that only *unicode* codings should be
available through the .encode and .decode interface. Or
alternatively there should be something more explicit like
.unicode_encode and .unicode_decode that is thus
Jeremy Hylton wrote:
On 2/21/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
I had to lookup top-post :-).
On 2/21/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Tue, 21 Feb 2006 08:02:08 -0500, Jeremy Hylton [EMAIL PROTECTED]
wrote:
Jeremy
Hey, only Guido is allowed to top-post. He said so ;-)
Greg Ewing wrote:
Ron Adam wrote:
Storing byte information as 16 or 32 bits ints could take up a rather
lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than
Bengt Richter wrote:
On Sat, 18 Feb 2006 09:59:38 +0100,
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
Thinking about bytes recently, it occurs to me that bytes are really not
intrinsically
numeric in nature. They don't necessarily represent uint8's. E.g., a binary
Josiah Carlson wrote:
Bob Ippolito [EMAIL PROTECTED] wrote:
On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
Stephen J. Turnbull wrote:
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido - b = bytes(t, enc); t = text(b, enc)
+1 The coding
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Bengt Richter had a good idea with bytes.recode() for strictly bytes
transformations (and the equivalent for text), though it is ambiguous as
to the direction; are we encoding or decoding with bytes.recode
Aahz wrote:
On Sat, Feb 18, 2006, Ron Adam wrote:
I like the bytes.recode() idea a lot. +1
It seems to me it's a far more useful idea than encoding and decoding by
overloading and could do both and more. It has a lot of potential to be
an intermediate step for encoding as well as being
101 - 200 of 247 matches
Mail list logo
