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 l
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 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
On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman 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 just a "wire" w
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
https://mail.python.org/mailman/listinfo/py
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
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 copy&paste error or a typo in the code ^ ?
It's
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
>
>py
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 mo
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
-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.
Y
-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 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 pa
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 he
* 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,
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 w
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
>
>[
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 [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 th
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 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 nat
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 machine
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 t
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 pa
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
>> h
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"
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
>.../foo-1.0.eg
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 res
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'
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 th
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 differe
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"
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 th
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 provid
On 20-apr-2006, at 23:08, Martin v. Löwis wrote:
> 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-reada
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
> > w
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" s
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
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,
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
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
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 "zer
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 "resour
Guido van Rossum wrote:
> Anyway, perhaps it's a matter of choice. It's clear to me that many
> developers prefer to do it this way. You don't. This is an area that
> has enough external constraints that I'm uncomfortable telling
> developers they can't do it that way.
Hence my -0. I see the pract
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. Odd
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
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 migh
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 plat
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 l
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 wor
"Guido van Rossum wrote:
> > - I still fear that the code of setuptools will turn out to be
> > a maintenance nightmare.
>
> AFAICT Phillip has explicitly promised he will maintain it (or if he
> doesn't, I expect that he would gladly do so if you asked). This has
> always been sufficient as a "
Guido van Rossum 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"
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
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
>> 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 actual
54 matches
Mail list logo
