On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman et...@stoneleaf.us wrote:
Has anyone actually used __bytes__ yet? What for?
bytes(email.message.Message()) returns the message object serialized to
wire format.
--David
PS: I've always thought of wire format as *including* files...a file is
a
On Tue, Jan 14, 2014 at 10:58:49AM -0500, R. David Murray wrote:
On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman et...@stoneleaf.us wrote:
Has anyone actually used __bytes__ yet? What for?
bytes(email.message.Message()) returns the message object serialized to
wire format.
--David
R. David Murray writes:
a file is a just a wire with an indefinite destination and
transmission time
+1 QOTW
Of course! Store and ... wait for it ... forward architecture
4-ever!
Store and Forward, Inc. Since 1969.
___
Python-Dev mailing list
Has anyone actually used __bytes__ yet? What for?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Mon, Jan 13, 2014, at 05:38 PM, Ethan Furman wrote:
Has anyone actually used __bytes__ yet? What for?
In the stdlib itself:
email.message
wsgiref
pathlib
___
Python-Dev mailing list
Python-Dev@python.org
On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote:
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
2. standardize
On 2008-01-20 19:30, Christian Heimes wrote:
Yet another python executable could solve the issue, named pythons as
python secure.
/*
gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread
-Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o pythons2.6
pythons.c
M.-A. Lemburg wrote:
sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0,
inspect=-2147483647, interactive=-2147483647, optimize=0,
dont_write_bytecode=0, no_user_site=1, no_site=0, ingnore_environment=1,
Is this a copypaste error or a typo in the code ^ ?
It's a typo
-On [20080120 23:36], Oleg Broytmann ([EMAIL PROTECTED]) wrote:
PS. My python doesn't understand -s, so I tested a different options, but
the result is the same. There are Unix variants that understand many
options (I believe FreeBSD allows them) but most allow no more than one
parameter in #!.
-On [20080120 18:38], Oleg Broytmann ([EMAIL PROTECTED]) wrote:
A shell has nothing to do with it as it is the OS (exec system call)
that upon reading the magic of the file sees #! and executes the program
(up to the first space) and pass to the program the first (and the only)
parameter.
Yes,
Jeroen Ruigrok van der Werven wrote:
% ./test.py
Unknown option: -
usage: /usr/local/bin/python [option] ... [-c cmd | -m mod | file | -] [arg]
...
Try `python -h' for more information.
Contracting to -Es works, aside from -s being unknown to my Python.
And also, /usr/bin won't work,
On Mon, Jan 21, 2008 at 12:01:29PM +0100, Christian Heimes wrote:
The arg -Es may work because Python's arg parser doesn't recognize it as
two args -E -s but as the arg -E.
Thank goodness python is better than that:
$ python -Es
Unknown option: -s
usage: python [option] ... [-c cmd | -m mod
On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote:
#!/usr/bin/env python -E -s
On most Unicies #! magic may have only one parameter after the program;
the program here is env, the parameter is python, and that's all. Adding
python options will result in different errors - some
-On [20080120 18:12], Oleg Broytmann ([EMAIL PROTECTED]) wrote:
On most Unicies #! magic may have only one parameter after the program;
the program here is env, the parameter is python, and that's all. Adding
python options will result in different errors - some platforms silently
ignores the
On Sun, Jan 20, 2008 at 06:25:57PM +0100, Jeroen Ruigrok van der Werven wrote:
-On [20080120 18:12], Oleg Broytmann ([EMAIL PROTECTED]) wrote:
On most Unicies #! magic may have only one parameter after the program;
the program here is env, the parameter is python, and that's all. Adding
On Sun, Jan 20, 2008 at 07:30:03PM +0100, Christian Heimes wrote:
Oleg Broytmann wrote:
#! /usr/bin/env python -O
[trying to execute the script on Linux]
/usr/bin/env: python -O: No such file or directory
Oleg.
Oh right. I was sure that I've seen a shebang with options
Oleg Broytmann wrote:
A shell has nothing to do with it as it is the OS (exec system call)
that upon reading the magic of the file sees #! and executes the program
(up to the first space) and pass to the program the first (and the only)
parameter.
#! /usr/bin/env python -O
[trying
* Oleg Broytmann [EMAIL PROTECTED] [2008-01-20 20:12:38 +0300]:
On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote:
#!/usr/bin/env python -E -s
On most Unicies #! magic may have only one parameter after the program;
the program here is env, the parameter is python, and
On Mon, Jan 21, 2008 at 12:17:20AM +0200, Tristan Seligmann wrote:
* Oleg Broytmann [EMAIL PROTECTED] [2008-01-20 20:12:38 +0300]:
On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote:
#!/usr/bin/env python -E -s
On most Unicies #! magic may have only one parameter
Tristan Seligmann schrieb:
* Oleg Broytmann [EMAIL PROTECTED] [2008-01-20 20:12:38 +0300]:
On Sun, Jan 20, 2008 at 06:00:31PM +0100, Christian Heimes wrote:
#!/usr/bin/env python -E -s
On most Unicies #! magic may have only one parameter after the program;
the program here is env, the
On 4/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
On 20-apr-2006, at 23:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most
common
is '.egg' zipfile format, because it's a convenient one for
distributing
projects.'
'.egg files are a zero installation format for a Python
Ronald Oussoren wrote:
On 20-apr-2006, at 23:46, Martin v. Löwis wrote:
So if this attitude (Python Eggs are the preferred binary distribution
format) is wrong, it is the attitude that has to change first. Changes
to the documentation follow from that. If the attitude is right, I'll
have to
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the existing bdist_foo machinery to build
system specific
At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the
Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the existing bdist_foo machinery to
Martin v. Löwis wrote:
Some libraries (not necessarily in Python) have gone the path of
providing a unified API for all kinds of file stream access,
e.g. in KDE, any tool can open files over many protocols, without
the storage being mounted locally.
Maybe a compromise would be to provide an
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
used internally by the
Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh,
I can believe that history. Still, I thought a resource
is something you can exhaust;
Haven't you heard the term renewable resource ?-)
In the
Martin v. Löwis wrote:
I can readily believe that package authors indeed see this as
a simplification, but I also see an increased burden on system
admins in return.
There are two conflicting desires here. Package authors
don't want to have to make M different kinds of package
for M different
Phillip J. Eby wrote:
By now, however, the term is popularly used with GUI toolkits of all
kinds to mean essentially read-only data files that are required by a
program or library to function, but which are not directly part of the
code.
It's just occurred to me that there's another
Ronald Oussoren wrote:
That doesn't require Eggs to be single-file zipfiles; deleting a
directory would work just as will (and I believe it will work with
ez_install, too).
Egg directories (which are basically just the same as packages using
.pth files) also work for this and that's what I
Greg Ewing wrote:
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
At 06:43 PM 4/21/2006 +0200, Martin v. Löwis wrote:
They might need to be available outside Python. Two use cases:
1. The application embeds an sqlite database. Even though it
knows how to get at the data, it can't use it, because the
sqlite3 library won't accept
I don't understand it.
Have you read the manuals?
You mean,
http://peak.telecommunity.com/DevCenter/setuptools
Yes, I did. However, this would only enable me to use it (should I
ever find a need). What I really need to understand is how all this
stuff works inside.
Now, I haven't actually
On Thursday 20 April 2006 17:42, Martin v. Löwis wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
3. package resources. I dislike the term resources (it is not about
natural gas, water, main memory, or processor cycles, right?);
instead, this seems to provide access to embedded data files.
Apparently, there is a need for it, so
Anthony Baxter wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here - it's no better or worse
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
Certainly. However, I get two conclusions out of this:
1. don't load
On 20-apr-2006, at 21:53, Martin v. Löwis wrote:
However, this isn't really my objection to .egg files. I dislike them
because they compete with platform packages: .rpm, .msi, .deb.
As far as I understand the issues they compete up to a point, but should
also make it easier to create
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
will simply be a delivery mechanism for eggs.
That might
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if you just say no to
Ronald Oussoren wrote:
As far as I understand the issues they compete up to a point, but should
also make it easier to create platform packages that contain proper the
proper dependencies because those are part of machine-readable meta-data
instead of being written down in readme files. Oddly
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource fork
contained pieces of data called resources.
I can
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most common
is '.egg' zipfile format, because it's a convenient one for distributing
projects.'
'.egg files are a zero installation format for a Python package;'
single modules are also such a zero installation
At 10:59 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
At 11:26 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I thought a resource
is something you can exhaust; the fork should have been
named data fork or just second fork.
Hmm... I don't think that the English word resource necessarily
implies that it can be exhausted. In US businesses, people are
Guido van Rossum wrote:
On 4/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
1. don't load packages out of .zip files. It's not that bad if
software on the user's disk occupies multiple files, as long as
there is a convenient way to get rid of them at once.
Many problems go away if
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
what-have-you. I am not opposed to doing the classic style
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
51 matches
Mail list logo
