t_data(variable)
So yes, all his date is comprised of 8-bit bytes, and yes, he doesn't
need the struct module. Hence I'm puzzled why people suggest that
he uses the struct module.
I think the key answer is "use the string type, it is appropriate
to represent byte oriented data in python" (also see the subject
of this thread)
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
te the format string. IMO,
it is *much* better not to use the struct module for this
kind of problem, and instead rely on regular string
concatenation.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
u merely want to see *something* (and not actually the glyph
for the character (*)):
py> print(ascii('\u20ac'))
'\u20ac'
should work fine.
Regards,
Martin
(*) Windows doesn't support displaying *all* unicode characters even
in code page 65001, nor is it reasonable to
> IOW, the bridge might think it's in cp1252 mode, but nobody told the
> engine room, which is still churning out cp850.
I think you must use a different font in the console, too, such as
Lucida Sans Unicode.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
you add it to encoding/aliases.py?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ints < A-circumflex Euro >, as expected.
> After CHCP 65001, it prints < hollow-square >.
This is not surprising: this character is U+0080, which is a control
character. Try \xe2\x82\xac instead.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Next step?
You need to use the Visual Studio debugger to find out where
precisely the IOError comes from.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Professional, not sure about Standard), or
Visual C++ 2008 (which is free). You need to build Python from source in
debug mode; the released version is in release mode, and with no debug
information.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
al quote, in particular because "reproducible" is misspelled.
In any case, I can't find anything like that in the 3.0 changes
document, and, given that the comparison *does* give an exception,
any statement that the result is undetermined would be false.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Do I now have to get the Helpdesk to install Python for me?
No, you should wait for Python 2.6.2; this should fix this problem.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
indices precisely are created, and what
precisely they contain. Try
http://www.python.org/doc/2.5/lib/genindex.html
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ulated system is much faster. Is it the
> x64 working faster at its design sizes or perhaps the compiler or could
> it be the vmware system caching all writes etc etc?
I follow David's guess that Linux does better IO than Windows (not
knowing anything about the benchmark, of
tem time and user time, how do
the 30s split up?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
32-bit Windows; long operations are much
slower than int operations.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
same questions. Perhaps you have some virus scanner installed that
filters all write operations? Maybe Windows sucks?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
2.5.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
find the raw numbers fairly useless. What matters more to
me is what specific code duplications have been added. Furthermore,
your Dup30 classification is not important to me, but I'm rather
after the nearly 2000 new chunks of code that has more than 60
subsequent tokens duplicated.
Regards,
I would like to see de-duplicated (unless, of course, they are
in generated code, in which case I couldn't care less).
Unfortunately, none of the examples you have posted so far are
- large chunks, and
- new in 3.0.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
rdmur...@bitdance.com wrote:
> I've googled and looked through os.path, but I don't see a method for
> determining if a path points to a FIFO. Anyone know of a simple way to
> do so?
def isfifo(fn):
return stat.S_ISFIFO(os.stat(fn).st_mode)
HTH,
Martin
--
http://mail
> This is probably preferable to five different developers solving the
> same problem five different ways and introducing three *different* bugs, no?
With the examples presented, I'm not convinced that there is actually
significant code duplication going on in the first place.
Rega
uestion whether it is useful as-is,
as it doesn't tell me *what* code got duplicated (and it seems it is
also incorrect, since it includes analysis of generated code). While I
can welcome the information, I cannot welcome the conclusion that the
OP apparently draws from them.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ny solution in 3.0? or anything that has already been
> upgraded to 3.0? Thanks.
You need to use the key= argument to sort.
Martin
--
http://mail.python.org/mailman/listinfo/python-list
actually
exists in the root directory of c:
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
(*not* c:\MySQL_python-1.2.2-py2.4-win32.egg, unless you download
to c:\)
2. ask easy_install to download first, with
easy_install MySQL-python
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Is there a way of extracting them so they are importable in a python shell?
Try imp.get_frozen_object.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
n-dev; I can't guess the
rationale for deprecating it.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
loial wrote:
Can anyone be a little more helpful than Tino?
I'll do some freebie hints :-)
What I would do is try first whether key authentication works at all,
for example following a tutorial like
http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter8.html
And if that works translate
would also support COM/ActiveX plugins, then those
could directly be written in Python (assuming the COM interfaces
supported automation).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ike this "ð".
>
> Please help!
Well, your terminal just cannot display this character by default; you
need to use a different terminal program, or reconfigure your terminal.
For example, do
chcp 1252
and select Lucida Console as the terminal font, then try again.
Of course, th
sses into memory, and then unmarshals from there (
compressed block for compressed block)
> If there is a link that covers this info, that'd be great too.
See the description of the marshal module.
HTH,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ncoding that supports all of Unicode, and you
don't care whether the output is legible, use UTF-8.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Any chance of getting a Mac installer for this one?
Chances are non-zero, yes.
Martin
--
http://mail.python.org/mailman/listinfo/python-list
in reason for
the encoding declaration (besides sanity for text editors also) is
Unicode literals (in 3.x, also relevant for identifiers)
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ame, value)
person_rows = "first last age".split()
def get_person(conn, id):
conn.execute("select first, last, age from person where id=%d"
% (id,))
return NamedTuple(person_rows, conn.fetchone())
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
el(sys.argv[1], sys.argv[2])
>
> def absToRel(dir, root):
> for filename in os.listdir(dir):
> if os.path.isdir(filename):
Perhaps you have a symlink somewhere that makes the tree appear to
have infinite depth?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
MRAB wrote:
Dennis Lee Bieber wrote:
On Wed, 18 Feb 2009 21:22:45 +0100, Peter Otten <__pete...@web.de>
declaimed the following in comp.lang.python:
Steve Holden wrote:
Jervis Whitley wrote:
What happens when you have hundreds of megabytes, I don't know.
I hope I never have to test a wor
t the OP's original message did not have a Content-type header,
and that it was thus impossible to tell what the byte in front of
"Wiki" meant. To properly post either MICRO SIGN or GREEK SMALL LETTER
MU in a usenet or email message, you really must use MIME. (As both
your article a
Ron Garret wrote:
> In article <499f0cf0.8070...@v.loewis.de>,
> "Martin v. Löwis" wrote:
>
>
> I'm the OP. I'm using MT-Newswatcher 3.5.1. I thought I had it
> configured properly, but I guess I didn't.
Probably you did. However, it
So where is the Python parser getting its
> encoding from? Why does parsing "u'\xb5'" not produce the same error as
> calling unicode('\xb5')?
Because \xb5 *directly* refers to character U+00b5, with no
byte-oriented encoding in-between.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
all
supported source encodings (as source encodings must be ASCII
supersets).
The Unicode literal shown here does not get its interpretation
from Latin-1. Instead, it directly gets its interpretation from
the Unicode coded character set. The string is a short-hand
for
u'\u00b5'
and this denotes character U+00B5 (just as u'\u20ac" denotes
U+20AC; the same holds for any other u'\u').
HTH,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
tem.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t; countless threads about the distinction between UTF and UCS?
You are not misremembering. I personally never found them conclusive,
and, with PEP 261, I think, calling the 2-byte version "UCS-2" is
incorrect.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
; the latter can only encode those in the BMP.
Indeed. As Python *can* encode all characters even in 2-byte mode
(since PEP 261), it seems clear that Python's Unicode representation
is *not* strictly UCS-2 anymore.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ing; UTF-16 essentially for the same reason (plus there was
no point to UTF-16, since there were no assigned characters outside
the BMP).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
s UTF-8. To do that, it must have converted the
original message from Latin-1 to UTF-8, which must have required
interpreting it as Latin-1 in the first place.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
atch file or
> python script through py2exe.
What's wrong with running the MSI from a batch file?
msiexec /i pythonxy.msi
If you want installation to be silent, add more command line options
to msiexec.
HTH,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
e seems to be no reason not to make it identical
> to 3.0
Sure there is. Making the bytes type and the str type identical
in 2.x gives the easiest way of porting. Adding bytes as a separate
type would have complicated a lot of things.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ed out, Python's or Windows' memory management
might have led to fragmentation, so that no contiguous piece of
memory to hold the resized dictionary can be found.
One solution to that problem would be to use a 64-bit system.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
d to the tarball. I tried
> again several times, but nothing happened. Can anyone explain what I
> have to do to get Distutils to include the module?
You need to delete the MANIFEST, or rerun with --force-manifest.
Otherwise, the manifest will only get regenerated when setup.py change
> Does anyone has a better solution ?
If you have pythonwin, you can use win32file.FindFilesW, passing
the lower-cased file name.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> No criticism was intended. It was merely an RFI.
Not sure whether you got the answer you wanted - when I said
"it is too much effort to build (and too few users)", I really
meant "it is non-zero effort, which is too much".
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
x27;s now os.path.extsep.
That doesn't really explain it. It always was os.path.extsep,
but it *also* was os.extsep.
I don't know the rationale for this change myself, either.
I doubt it is documented anywhere, nor do I think it should;
there won't be ever a complete list of changes between 2.x
and 3.x.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ther the increase in IO time is acceptable, and
b) if it is, just go with 3.0, as the increase in sorting time
is much smaller than the increase in IO time.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
that ctypes supports ia64, so I may be able to
> make some progress on this front.
Good luck!
Martin
--
http://mail.python.org/mailman/listinfo/python-list
always os.path.extsep.
Perhaps this gives the rationale for the change - migration into the
platform modules is now complete.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ing systems.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Martin> Not that I regret it's gone - it was a useless constant, anyway,
> Martin> as the extension separator is '.' on all interesting systems.
>
> Except if you diff r57096 and r57097 I suspect you'll find that it was
> different in RISCOS.
I
[EMAIL PROTECTED] wrote:
> Martin> In any case - if the intention was that extsep is now not
> Martin> supported anymore, it should have been removed from the other
> Martin> *path modules as well (along with removing it from the
> Martin> documentation).
be
very bad programming, and the authors should never had added IPv6
support to that application in the first place (applications that
predate IPv6 only use gethostbyname, only find IPv4 addresses, and
never even try IPv6).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Huh? I thought it was settled. Read Terry Ready's latest message. Read
> the bug report it points to (http://bugs.python.org/issue1693050),
> especially the contribution from MvL. To paraphrase a remark by the
> timbot, Martin reads Unicode tech reports so that we don't hav
> But no PYTHONPATH variable shows up in my environment settings.
To answer a long question with a single sentence: just add the variable,
and be done with it.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
in many more cases (e.g. when reading from a file opened in text mode).
In 3.0, *all* these strings become Unicode strings.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
John Machin wrote:
> On Nov 30, 4:33 am, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Martin v. Löwis wrote:
>>> To be fair to Python (and SRE),
>
> I was being unfair?
No - sorry if I gave that impression.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Aaron Watters wrote:
On Nov 30, 11:55 am, "Filip Gruszczyński" <[EMAIL PROTECTED]> wrote:
http://jcalderone.livejournal.com/39794.html
That's exactly what I have read before posting here ;-)
--
Filip Gruszczyński
I too would like to see a meatier discussion of best practices
for python packa
>> How to chmod a file to: o-rwx ? (to change only the others mode)
> I have tried:
>
> mode = os.stat(fname).st_mode
> os.chmod(fname, mode | stat.S_IRWXO) => Changes to o+rwx
Close. Try
os.chmod(fname, mode & ~stat.S_IRWXO)
Regards,
Martin
--
http://mail.python.or
e trouble with it when I attempt edit a python file
> from the Windows Explorer.
It would be good to be more specific with such statements: what troubles
specifically? If I play dumb, I'd say "of course - windows explorer
doesn't support editing Python files; you need a text editor".
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ple relying on this being Python.File),
but I can't see any problems off-hand.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Conditional removal
of the associations will be tricky; I'll look into it.
I also wonder whether assoc only changes the settings for the current
user. In that case, uninstalling a Python version that was per-machine
would not affect the user's association, anyway.
Regards,
Martin
--
htt
gt; and must be killed, using the Task Manager.
I think you need to report that to the PyScripter authors as a bug.
I can't imagine how the "currently active version" can affect what
PyScripter does.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
n the
sense in why you use the word, there might just not be a "default"
version of Python on Windows. Somebody who knows SciTe better may
correct me.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
till work correctly when run
in 2.x.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t separately.
Doing so is fairly easy. You just run "setup.py install" multiple
times (or download and install prebuilt binaries if available).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> I've tried using automake, however I'm worried about libtool not getting
> the options right while building my module.
You should use python-config(1) to obtain the command line options
necessary to build and link extension modules.
HTH,
Martin
--
http://mail.python.org/
Warren DeLano wrote:
A bottom line / pragmatic question... hopefully not a FAQ.
Why was it necessary to make "as" a reserved keyword?
Because it can be used at the import statement to let the imported thing
be known under another name?
Something like:
>>> import xml.etree.ElementTree as E
Martin P. Hellwig wrote:
Warren DeLano wrote:
A bottom line / pragmatic question... hopefully not a FAQ.
Why was it necessary to make "as" a reserved keyword?
Because it can be used at the import statement to let the imported thing
be known under another name?
Some
Steven D'Aprano wrote:
On Wed, 03 Dec 2008 22:02:24 +0000, Martin P. Hellwig wrote:
Warren DeLano wrote:
A bottom line / pragmatic question... hopefully not a FAQ.
Why was it necessary to make "as" a reserved keyword?
Because it can be used at the import statement to let the
> I would like to ask, how long will Python 2 be developed? Just for curiosity.
>
There won't be a 2.10 release of Python. Whether that means that 2.9
will be the last one, or whether development stops earlier, remains to
be seen.
Regards,
Martin
--
http://mail.python.org/mailm
be rejected. In a few years from now, Python 2
will be gone, and we would be stuck with an ugly file extension
(similar to how \windows\system is now an empty directory, and
\windows\system32 actually contains the 64-bit binaries on x64)-
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
lly does, but his
report of success seems to indicate that it choses the interpreter
associated with .py.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
> Martin v. Löwis wrote:
>>> Since the source code is incompatible, I was expecting the Python
>>> executable to have a new name such as 'python3'
>>
>> It does: the executable is called python3.0.
>
> Why do you say that?
> For *NIX machines, will 'python' be placed into /usr/bin?
Not by default, no. Just try it and see for yourself.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
eased, you may find yourself writing
scripts that run only on Python 3.x for x>=1 (i.e. won't run on 3.0,
because you use a new feature in 3.1). In that case, presence of a
python3 executable won't help, either.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
import os, fcntl
oldname = "ham.txt"
newname = "spam.txt"
def lock_destination(name):
fileno = os.open(name, os.O_CREAT | os.O_EXCL)
fcntl.flock(fileno, fcntl.LOCK_EX) # POSIX systems only
return fileno
# Create a test file to be renamed.
f = open(oldname, '
the default installation?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
News123 wrote:
What's more painful is to learn which functianilty is in which library
and which library exists.
Yes and one mistake I still often find myself doing is, when confronted
with a particular problem, that I write some helper code to deal with
it. Of course later on I discover tha
that some package authors only classify with
Programming Language :: Python :: 3
> Are there any special arrangements necessary for PyPI packages which
> have both a Python 2.x version and a Python 3.x version?
So far, no such need has been identified.
Regards,
Martin
--
http://mail.py
e for 3.x (say) if some version has only the 2.x release.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Should specifying the 3.0 tag implicity and automatically specify the
> 3 tag as well?
No. There is really no builtin automatic semantics to any of the
classifiers.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
stom archive
> when building and installing from source. (Which also raises a further
> question: if I do eventually manage to upload both 2.x and 3.x
> versions under the same PyPI entry, will easy_install know which one
> to download?)
See above. Won't this solve these probl
; specifically refers to a rpm/deb package,
though. You might need to layout the sources so that they meet your
needs (e.g. by installing them locally).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
nherit from the build command, extend the user_options
attribute, and pass the new class as "build" class into the commands
dictionary of setup. You might need to extend initialize_options and
finalize_options as well.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
it's nearly certain that the PSF will get approved again,
though).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
python itself.
There isn't a real installation procedure. You just copy the files by
hand into the places where they belong. In the specific case,
overwriting all .exe, .dll, and .pyd files in an installed directory
should be sufficient.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Kevin Walzer wrote:
Hello,
I'm trying to move from os.popen to using subprocess, and I'm having
trouble with the pipe suddenly closing.
My old code looked something like this:
Hi Kevin,
You could try something more like:
>>> import subprocess
>>> cmd = subprocess.Popen([executable_path,
> When I try to use umlauts in idle it will only print out as Unicode
> escape characters. Is it possible to configure idle to print them as
> ordinary characters?
Did you really use the print statement? They print out fine for me.
Regards,
Martin
--
http://mail.python.org/mailman
ype has changed in 3.0, and now uses a different
definition of repr.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Highlights of the previous major Python releases are available
from the Python 2.5 page, at
http://www.python.org/2.4/highlights.html
http://www.python.org/2.5/highlights.html
Enjoy this release,
Martin
Martin v. Loewis
mar...@v.loewis.de
Python Release Manager
(on behalf of the entire
ion of repr.
>
> So was the above-reported non-crash consequence of the change of
> definition of repr intended?
Yes. If you want a display that is guaranteed to work on your terminal,
use the ascii() builtin function.
py> x = '\u9876'
py> ascii(x)
"'\\u9876
> But shouldn't the production of an object's representation via repr be
> a "safe" operation?
It's a trade-off. It should also be legible.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
o
file /usr/lib/libz.so
It might be a 32-bit library, in which case you can check whether
/usr/lib64 has a 64-bit library. I'm puzzled why it only
happens for -lz; perhaps you are better of compiling with a 32-bit
compiler.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
3201 - 3300 of 4331 matches
Mail list logo